Design Review

Use this when you have a design (mockup, prototype, screenshot, or Figma link) and want structured feedback on accessibility, consistency, edge states, and acceptance criteria coverage before engineering begins.

Related skills: Use /state-map for a thorough state audit before review. Use /animation-spec to review motion and transition quality. Use /microinteraction-design for interaction feedback detail.

Process

Step 1: Gather inputs

Ask the user to provide:

1. The design — screenshots, Figma link, prototype URL, or a description of the design. Multiple screens are fine.
2. The story or feature description — what this design is for, including acceptance criteria if available.
3. Design system or brand guidelines — any relevant standards (colors, typography, component library) to check against. Optional.
4. Target users — who will use this? (helps evaluate appropriateness of complexity, language, information density)

Step 2: Review the design

Evaluate across these dimensions:

Acceptance criteria coverage

• Does the design address every acceptance criterion in the story?
• Are there criteria that the design doesn't cover (missing screens or states)?
• Does the design introduce functionality not in the story (scope creep)?

Edge and interaction states

Check that the design handles:

• Empty state — what does the user see when there's no data yet? Is there guidance or a call to action?
• Loading state — what happens while data is being fetched? Spinner, skeleton screen, or progressive loading?
• Error state — what does the user see when something goes wrong? Is recovery clear?
• Partial/degraded state — what if some data loads but not all? What if a service is unavailable?
• Skeleton screens — are placeholder layouts used during load to prevent layout shift?
• Offline/disconnected state — what happens if the user loses connectivity mid-task?
• Overflow — what happens with long text, many items, or extreme values?
• First-time vs. returning user — is onboarding needed?
• Single item vs. many items — does the layout work at both extremes?
• Transition states — are there clear visual transitions between states (loading → loaded, collapsed → expanded)?
• Disabled/inactive elements — do disabled controls explain why they're disabled?

Accessibility (WCAG 2.2 AA baseline)

Evaluate each category. For deeper WCAG compliance analysis, use /accessibility-audit.

Perceivable:

• Color contrast -- do text and interactive elements meet WCAG AA ratios (4.5:1 text, 3:1 large text, 3:1 UI components)?
• Color independence -- is meaning conveyed through shape, text, or icons in addition to color? (e.g., error states use red + icon + text, not red alone)
• Text legibility -- is body text at least 16px? Is line height at least 1.5x? Can text be resized to 200% without content loss?
• Alt text -- do images and icons have text alternatives? Are decorative images marked as decorative?
• Media -- do videos have captions? Do audio elements have transcripts?

Operable:

• Keyboard navigation -- can all interactive elements be reached and activated via keyboard? Is tab order logical?
• Focus indicators -- does every interactive element have a visible focus state? Are custom focus styles at least as visible as browser defaults?
• Focus management -- after modal open, content load, or deletion, where does focus go? Do modals trap focus?
• Touch targets -- are interactive elements large enough (minimum 24x24px per WCAG 2.2, recommended 44x44px)?
• Motion and animation -- do animations respect prefers-reduced-motion? Is there auto-playing content that can be paused?

Understandable:

• Form labels -- do all inputs have visible labels (not just placeholders)? Are labels programmatically associated with inputs?
• Error handling -- are errors identified clearly? Do error messages suggest corrections? Are errors associated with their inputs via aria-describedby?
• Consistent navigation -- do repeated navigation elements appear in the same order across screens?

Robust:

• Screen reader path -- does the visual hierarchy match a logical reading order? Do headings form a correct h1-h6 hierarchy?
• ARIA usage -- are custom components using appropriate ARIA roles and states? Is ARIA used only when semantic HTML is insufficient?
• Dynamic content -- are live updates announced to screen readers via aria-live regions? Are status messages (success, error, progress) announced?

Consistency

• Does the design use components from the design system consistently?
• Are spacing, alignment, and sizing patterns consistent across screens?
• Does the visual language match the rest of the product?
• Are interactive patterns (buttons, links, forms) used consistently?

Usability

• Is the primary action obvious on each screen?
• Is the information hierarchy clear (what's most important)?
• Can the user complete their task without confusion?
• Are labels and copy clear and actionable?

Step 3: Generate the review

Output in this format:

Design Review: (feature name)

Summary

(One sentence: Ready for build / Needs iteration / Major concerns)

Edge state coverage

Accessibility findings

Severity key: Critical = blocks AT users from completing task. Major = significant barrier, workaround exists. Minor = inconvenience or non-conformance with low impact.

Consistency issues

1. (Issue) — (where it deviates)
2. ...

Usability feedback

1. (Observation) — (recommendation)
2. ...

Acceptance criteria alignment

What works well

• (Specific positive callouts)

Step 4: Discuss

Ask the user:

• Any feedback you disagree with or want to discuss?
• Want me to suggest specific design changes for the issues found?
• Are there other screens or flows to review?

Feedback principles

• Review before it's ready. Give feedback on work-in-progress, not polished deliverables. Waiting for "ready" creates waterfall in disguise.
• Give feedback at the right level. Don't give pixel-level notes on a wireframe. Match feedback granularity to the artifact's maturity.
• Review in public. When you give feedback in private, you take that learning from everyone else in the room. Make feedback visible so the team learns from it.

Output location

Present the review as formatted text in the conversation.