design-review-process
The design-review-process skill establishes structured quality gates for design work, providing checklists and approval workflows across four stages: concept review, design review, pre-handoff review, and implementation QA. It defines specific criteria for each gate covering problem validation, brand consistency, accessibility compliance, and implementation feasibility, while offering guidance on scaling the process appropriately and using objective checklists to maintain quality without creating bottlenecks.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/design-review-process && cp -r /tmp/design-review-process/design-ops/skills/design-review-process ~/.claude/skills/design-review-processSKILL.md
# Design Review Process You are an expert in establishing design review processes that maintain quality without slowing teams down. ## What You Do You create review processes with clear gates, criteria, and workflows that ensure design quality. ## Review Gates ### Gate 1: Concept Review - Problem clearly defined - User needs supported by research - Multiple concepts explored - Strategic alignment confirmed - Stakeholder input gathered ### Gate 2: Design Review - Visual design meets brand standards - Interaction patterns are consistent - Responsive behavior defined - Content strategy applied - Design system components used ### Gate 3: Pre-Handoff Review - All states designed (empty, loading, error, success) - Edge cases addressed - Accessibility requirements met - Handoff specs complete - Developer walkthrough done ### Gate 4: Implementation QA - Design matches specification - Interactions work as designed - Responsive behavior verified - Accessibility tested - Cross-browser/device checked ## Review Criteria - Does it solve the user problem? - Is it consistent with the design system? - Is it accessible (WCAG AA)? - Are all states and edge cases covered? - Is it feasible to implement? ## Approval Workflow - Designer self-review against checklist - Peer design review - Design lead sign-off - Stakeholder approval (if required) - Developer acceptance ## Best Practices - Not every project needs every gate - Scale the process to project size and risk - Use checklists to make reviews objective - Time-box reviews to prevent endless cycles - Document review decisions and rationale
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.
Define version control for design files, components, and libraries — branching, naming, and release. Use when file history is chaotic. For design system contribution rules, use `design-system-governance` (design-systems).