Frontend Design

Frontend Design Skill

Create distinctive, production-grade frontend interfaces using systematic UI/UX principles.

Quick Answers

PHASE 1: THINK (Mandatory Discovery)

STOP. Do NOT write any code until these questions are answered.

1.1 User Understanding

Ask or determine these BEFORE designing:

WHO is the user?
├── Demographics (age, tech proficiency, device usage)
├── Goals (what are they trying to accomplish?)
├── Context (where/when will they use this?)
└── Pain points (what frustrates them currently?)

WHAT problem does this solve?
├── Primary user task (the main job-to-be-done)
├── Secondary tasks (supporting actions)
├── Success criteria (how does user know they succeeded?)
└── Failure modes (what happens when things go wrong?)

WHY would users choose this over alternatives?
├── Unique value proposition
├── Competitive advantage
└── User motivation (convenience, speed, trust, delight?)

1.2 Technical Context

CONSTRAINTS:
├── Framework: React / Vue / Vanilla / Other?
├── Existing design system: Yes / No / Partial?
├── Performance budget: Critical / Normal / Flexible?
├── Browser support: Modern only / Legacy required?
└── Accessibility level: WCAG A / AA / AAA?

INTEGRATION:
├── Does this fit into existing UI?
├── What patterns already exist in the codebase?
├── What components can be reused?
└── What's the deployment target?

1.3 User Psychology Checkpoint

Before proceeding, consider:

Output from Phase 1: Document answers to these questions. If answers are unknown, ASK THE USER before proceeding.

1.4 If User Cannot Answer Discovery Questions

When user lacks context for Phase 1 questions:

FALLBACK APPROACH:
1. Document assumptions explicitly in component plan
2. Default to conservative choices:
   ├── WCAG 2.2 AA compliance
   ├── Mobile-first approach
   ├── Standard industry conventions
   └── 44px touch targets (exceeds WCAG 2.2 AA minimum)
3. Mark assumptions for later validation
4. Proceed with clearly stated caveats

PHASE 2: PLAN (Design Decisions)

2.1 Information Architecture

Before visual design, structure the information:

CONTENT HIERARCHY:
├── What's the #1 thing users must see/do? → Make it PRIMARY
├── What supports the primary action? → Make it SECONDARY
├── What's rarely needed? → Make it TERTIARY or hide
└── What can be removed entirely? → DELETE IT

NAVIGATION MENTAL MODEL:
├── How does user expect to move through this?
├── What's the mental map they'll build?
├── Where might they get lost?
└── How do they return to safety?

2.2 Aesthetic Direction Selection

Choose ONE direction based on user psychology:

Decision Documentation:

AESTHETIC CHOICE: [Selected Direction]
RATIONALE: [Why this fits the user/context]
KEY CHARACTERISTICS: [3-5 specific traits to implement]

2.3 Component Planning

For each component, decide BEFORE building:

COMPONENT: [Name]
├── PURPOSE: What job does this do?
├── USER EXPECTATION: What do they expect it to look like/behave?
├── STATES NEEDED: [default, hover, focus, active, disabled, loading, error, success]
├── RESPONSIVE BEHAVIOR: How does it adapt?
├── ACCESSIBILITY: How do screen readers announce it?
└── CONVENTION CHECK: What do GitHub/Stripe/Google do?

Output from Phase 2: Component plan with rationale for each decision.

PHASE 3: BUILD (Implementation)

3.1 Design Tokens First

Before writing component code, establish tokens for:

For complete token system with examples: See references/design-system.md

3.2 Component States Implementation

EVERY interactive element MUST have these states:

Key implementation points:

• min-height: 44px; min-width: 44px for touch targets
• :focus-visible with box-shadow: var(--focus-ring) for accessibility
• transition: var(--transition-fast) for smooth state changes

For complete CSS implementations: See references/component-states.md

3.3 Layout Conventions

Button Order (CRITICAL - Industry Standard): Secondary LEFT, Primary RIGHT

Evidence: GitHub, Stripe, Google, Notion, Figma all follow this pattern.

For complete conventions with evidence: See references/industry-conventions.md

3.4 Responsive Implementation

Breakpoints (mobile-first): 640px (sm) → 768px (md) → 1024px (lg) → 1280px (xl) → 1536px (2xl)

Touch Targets (MANDATORY): 44×44px minimum on all interactive elements (exceeds WCAG 2.2 AA 24px requirement)

For complete responsive patterns: See references/mobile-responsive.md

PHASE 4: VALIDATE (Quality Assurance)

4.1 Accessibility Checklist

For complete accessibility guide: See references/accessibility.md

4.2 3-Dimension UI Evaluation

For ANY component, evaluate:

Evaluation Output Format:

## [Component] Evaluation

### Current State
- Position: [Description]
- Visual Weight: [Description]
- Spacing: [Measurements]

### Verdict: [CORRECT / NEEDS CHANGES]

### Issues (if any)
| Priority | Issue | Fix |
|----------|-------|-----|
| P1 | [Critical UX break] | [Specific fix] |
| P2 | [Suboptimal] | [Specific fix] |
| P3 | [Polish] | [Specific fix] |

For complete evaluation framework: See references/evaluation-framework.md

4.3 Final Quality Gate

Before delivery, verify ALL items:

ACCESSIBILITY (WCAG 2.2)
[ ] Color contrast meets WCAG AA (4.5:1 text, 3:1 large)
[ ] All focus states visible and not obscured by other content
[ ] Focus indicators meet WCAG 2.2 requirements
[ ] All inputs have associated labels
[ ] Keyboard navigation works end-to-end
[ ] Touch targets: 44px+ (exceeds WCAG 2.2 AA 24px minimum)
[ ] Dragging actions have single-pointer alternative
[ ] Help mechanisms in consistent location across pages
[ ] Don't re-request previously entered information
[ ] Authentication without cognitive function tests

CONVENTIONS
[ ] Button order: Secondary LEFT, Primary RIGHT
[ ] Navigation: Logo LEFT, Primary nav CENTER/LEFT, Utilities RIGHT
[ ] Forms: Labels above inputs, error messages below

STATES
[ ] All buttons have: default, hover, focus, active, disabled
[ ] All inputs have: default, focus, filled, error, disabled
[ ] Loading states for async operations
[ ] Error states with clear messages
[ ] Empty states for no-data scenarios

RESPONSIVE
[ ] Mobile breakpoint (320px) tested
[ ] Tablet breakpoint (768px) tested
[ ] Desktop breakpoint (1024px+) tested
[ ] No horizontal scroll on mobile

AESTHETICS
[ ] Typography is distinctive (not Inter/Roboto/Arial)
[ ] Color palette is cohesive
[ ] Spacing uses consistent system
[ ] Visual hierarchy is clear

Reference Files

Load based on current task:

Anti-Patterns to Avoid

For complete anti-patterns: See references/anti-patterns.md

External Resources

When Patterns Aren't Covered

For patterns not in this skill:

1. Fetch docs from official sources (MDN, WCAG, framework docs)
2. Reference established design systems (Material, Carbon, Spectrum)
3. Use Context7 MCP for library-specific documentation
4. Default to conservative choices when uncertain

Standards Note: This skill follows WCAG 2.2 (ISO/IEC 40500:2025, current as of December 2025). WCAG 3.0 is in development. Check https://www.w3.org/WAI/ for updates.