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 | | Google | [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