UX Evaluator
Overview
Systematically evaluate UI components against established UX principles using a 3-dimension framework. Transform subjective design feedback into actionable, evidence-based recommendations by comparing against industry conventions and authoritative sources.
Core Value: Prevents subjective design debates by grounding decisions in documented best practices.
When to Use This Skill
Triggers:
- •User provides UX feedback on a component
- •User references external design guidelines (Balsamiq, Nielsen, Material Design)
- •User asks to "review", "evaluate", or "check" UI elements
- •User questions button labels, spacing, or visual hierarchy
- •Before implementing UI changes that affect user interaction
Do NOT use for:
- •Pure visual aesthetics (colors, fonts) without UX implications
- •Backend or non-UI changes
- •When user has already made a firm decision and just wants implementation
Evaluation Framework
The 3-Dimension Analysis
For ANY UI component, evaluate these three dimensions:
| Dimension | What to Analyze | Key Questions |
|---|---|---|
| 1. Position | Where is it located relative to other elements? | Does position follow conventions? Is it discoverable? |
| 2. Visual Weight | How prominent is it visually? | Does it compete with primary actions? Is hierarchy clear? |
| 3. Spacing | What's the gap from adjacent elements? | Is there adequate separation? Is spacing consistent? |
Evaluation Workflow
Step 1: GATHER CONTEXT ├── What component is being evaluated? ├── What user feedback or concern triggered this? ├── Is there an external reference (article, guideline)? └── What is the component's purpose (primary CTA, utility, navigation)? Step 2: ANALYZE CURRENT STATE ├── Position: Document exact location in layout ├── Visual Weight: Describe styling (filled, ghost, icon-only, etc.) ├── Spacing: Measure gaps from adjacent elements └── Compare to industry conventions (see references/) Step 3: PRODUCE VERDICT ├── For each dimension: CORRECT / NEEDS CHANGE / ACCEPTABLE ├── If NEEDS CHANGE: Specific recommendation with rationale ├── Reference authoritative source for each recommendation └── Prioritize changes (P1: breaks UX, P2: suboptimal, P3: polish)
Component-Specific Guidelines
Buttons (Action Elements)
Position:
- •Primary action (Sign Up, Submit, Buy) → RIGHT side
- •Secondary action (Cancel, Sign In) → LEFT of primary
- •Utility controls (theme, settings) → FAR RIGHT after primary actions
Visual Weight:
- •Primary: Filled background, brand color, shadow
- •Secondary: Ghost/outline, no fill, subtle border
- •Utility: Icon-only or minimal text, neutral color
Spacing:
- •Between button groups: 1.5rem (24px) minimum
- •Between buttons in same group: 0.5rem-0.75rem (8-12px)
- •Touch targets: 44px minimum height on mobile
Labels:
- •Use conventional labels: "Sign Up" not "Get Started", "Sign In" not "Login"
- •Say exactly what happens: "Delete Account" not "Proceed"
- •Verb-first for actions: "Create Project", "Send Message"
Navigation Elements
Position:
- •Logo → LEFT
- •Primary nav → CENTER or after logo
- •Utility items (search, auth, theme) → RIGHT
Visual Weight:
- •Active state clearly distinguished
- •Current page indicator visible
- •Don't compete with page content
Spacing:
- •Group related items visually
- •Clear separation between nav groups
- •Adequate click/tap targets
Form Elements
Position:
- •Labels above or to the left of inputs
- •Submit button at bottom, right-aligned or full-width
- •Error messages adjacent to field
Visual Weight:
- •Required fields marked clearly
- •Error states prominent (red border/text)
- •Success states confirmatory (green checkmark)
Spacing:
- •Consistent vertical rhythm between fields
- •Label-to-input gap: 0.25-0.5rem
- •Field-to-field gap: 1-1.5rem
Industry Conventions Reference
Button Order (Major Sites)
| Site | Pattern |
|---|---|
| GitHub | [Sign In] [Sign Up] - secondary left, primary right |
| Stripe | [Sign In] [Start now →] - secondary left, primary right |
| [Sign In] [Create account] - same pattern | |
| Notion | [Log in] [Get Notion free] - same pattern |
Verdict: Secondary LEFT, Primary RIGHT is the standard.
Theme Toggle Placement
| Site | Placement |
|---|---|
| GitHub | Far right, after user menu |
| VS Code Docs | Far right |
| Stripe Docs | Far right |
| Discord | In settings, not navbar |
Verdict: Far right (after auth) or in settings dropdown.
Utility Control Visual Weight
| Control | Expected Weight |
|---|---|
| Theme toggle | Icon-only, subtle, doesn't compete with CTAs |
| Search | Icon trigger or compact input, expandable |
| Language selector | Icon or compact dropdown |
Verdict: Utilities should be accessible but subordinate to primary actions.
Output Format
When evaluating a component, produce this structured output:
## [Component Name] Evaluation ### Current State - **Position**: [Description] - **Visual Weight**: [Description] - **Spacing**: [Measurements] ### Analysis | Dimension | Assessment | Rationale | |-----------|------------|-----------| | Position | [OK/CHANGE] | [Why, with reference] | | Visual Weight | [OK/CHANGE] | [Why, with reference] | | Spacing | [OK/CHANGE] | [Why, with reference] | ### Verdict: [CORRECT / NEEDS CHANGES] ### Recommendations (if any) | Priority | Change | Rationale | |----------|--------|-----------| | P1 | [Specific change] | [Reference to principle] | | P2 | [Specific change] | [Reference to principle] |
References
See references/ for detailed UX principles:
- •
balsamiq-button-principles.md- Button design best practices - •
nielsen-heuristics.md- 10 usability heuristics (to be added)
Self-Monitoring
Before finalizing evaluation:
- • All 3 dimensions analyzed (Position, Visual Weight, Spacing)
- • Current state documented with specifics (not vague descriptions)
- • Each recommendation references an authoritative source or convention
- • Compared against industry conventions (GitHub, Stripe, etc.)
- • Priorities assigned (P1/P2/P3) based on UX impact
- • Verdict is clear and actionable