frontend-ui-design（前端用户界面设计）

Frontend UI Design

Overview

Guide the design and implementation of frontend user interfaces with consistent architecture, accessibility, responsive behavior, and performance. This skill covers component patterns, design system integration, state management selection, and WCAG compliance — producing components that are testable, accessible, and performant.

Announce at start: "I'm using the frontend-ui-design skill to design the UI."

Phase 1: Discovery

Ask these questions to understand the UI requirements:

STOP after discovery — present a summary of constraints and approach before designing.

Phase 2: Component Architecture Selection

Architecture Pattern Decision Table

Atomic Design Levels

Compound Components Example

<Select value={selected} onChange={setSelected}>
  <Select.Trigger />
  <Select.Options>
    <Select.Option value="a">Option A</Select.Option>
    <Select.Option value="b">Option B</Select.Option>
  </Select.Options>
</Select>

Use when: a component has multiple sub-parts that must coordinate but consumers need layout flexibility.

Hooks Pattern Example

function useDialog() {
  const [isOpen, setIsOpen] = useState(false);
  const open = () => setIsOpen(true);
  const close = () => setIsOpen(false);
  return { isOpen, open, close };
}

Use when: the same logic is needed across multiple components with different UI.

STOP after architecture selection — confirm the pattern choice before proceeding.

Phase 3: Responsive Design

Mobile-First Breakpoints

Responsive Strategy Decision Table

Fluid Typography

font-size: clamp(1rem, 0.5rem + 1.5vw, 1.5rem);

Phase 4: Accessibility (WCAG 2.1 AA)

Semantic HTML Decision Table

ARIA Usage Rules

Keyboard Navigation Requirements

• All interactive elements focusable (naturally or tabindex="0")
• Operable via keyboard (Enter, Space, Escape, Arrow keys)
• Visible focus indicator (never outline: none without replacement)
• Logical tab order matching visual order
• Focus traps for modals and dialogs

Color Contrast Requirements

Screen Reader Testing

Test with at least one screen reader:

• macOS: VoiceOver (built-in)
• Windows: NVDA (free) or JAWS
• Verify: content announced in logical order, form errors associated with inputs, dynamic updates announced

Phase 5: State Management & Performance

State Management Decision Table

Selection Heuristic

1. Start with useState — only escalate when you hit a real limitation
2. If prop drilling exceeds 2 levels, consider Context or state library
3. If caching API responses, use a server state library (not Redux for server state)
4. For forms with >3 fields and validation, use a form library

Performance Optimization Checklist

Design System Integration

Design Tokens — define foundational values, not hard-coded:

const tokens = {
  color: { primary: '#2563eb', secondary: '#64748b', error: '#dc2626' },
  spacing: { xs: '0.25rem', sm: '0.5rem', md: '1rem', lg: '1.5rem', xl: '2rem' },
  typography: { fontFamily: { sans: 'Inter, system-ui, sans-serif' } },
};

Component Variants — consistent variant API:

<Button variant="primary" size="md">Save</Button>
<Button variant="outline" size="sm">Cancel</Button>

Theme Support:

• CSS custom properties for runtime theme switching
• Support light + dark themes at minimum
• Respect prefers-color-scheme as default
• Allow user override stored in localStorage

STOP after design — present the full component specification for review.

Anti-Patterns / Common Mistakes

Anti-Rationalization Guards

• Do NOT skip accessibility — WCAG 2.1 AA is the minimum, not optional
• Do NOT use <div> with onClick instead of semantic elements
• Do NOT skip keyboard navigation testing
• Do NOT choose state management before understanding the actual need
• Do NOT skip the discovery phase — understand constraints first
• Do NOT optimize performance without measuring first

Integration Points

Verification Gate

Before claiming the UI design is complete:

1. VERIFY component architecture pattern is explicitly chosen with rationale
2. VERIFY responsive behavior is defined for all target breakpoints
3. VERIFY accessibility requirements are specified (WCAG level, keyboard, color contrast)
4. VERIFY state management approach is selected based on actual needs
5. VERIFY loading, error, and empty states are designed
6. VERIFY the user has approved the component specification

Skill Type

Flexible — Adapt component patterns, responsive strategy, and state management to project framework and constraints while preserving accessibility requirements and the discovery-first approach.