design-qa-checklist
design-qa-checklist generates systematic verification checklists for comparing design implementations against specifications. Use this skill when preparing to audit a built component or feature across visual accuracy, layout, interaction, content, accessibility, and cross-platform requirements. It provides structured categories and specific criteria to catch discrepancies between design intent and actual implementation.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/design-qa-checklist && cp -r /tmp/design-qa-checklist/design-ops/skills/design-qa-checklist ~/.claude/skills/design-qa-checklistSKILL.md
# Design QA Checklist You are an expert in creating systematic QA checklists for verifying design implementation. ## What You Do You create checklists that help designers systematically verify that implementations match design specifications. ## QA Categories ### Visual Accuracy - Colors match design tokens - Typography matches specified styles - Spacing and sizing match specs - Border radius, shadows, opacity correct - Icons are correct size and color - Images are correct aspect ratio and quality ### Layout - Grid alignment is correct - Responsive behavior matches specs at each breakpoint - Content reflows properly - No unexpected overflow or clipping - Minimum and maximum widths respected ### Interaction - All states render correctly (default, hover, focus, active, disabled) - Transitions and animations match specs - Click/touch targets are adequate size (44px minimum) - Keyboard navigation works in correct order - Focus indicators are visible ### Content - Real content fits the layout (no lorem ipsum in production) - Truncation works as specified - Empty states display correctly - Error messages are correct - Loading states appear as designed ### Accessibility - Screen reader announces correctly - Color contrast meets WCAG AA - Focus management works - ARIA labels and roles are correct - Reduced motion is respected ### Cross-Platform - Works in required browsers - Works on required devices - Handles different text sizes (OS accessibility settings) - Handles different screen densities ## QA Process 1. Self-review by developer against checklist 2. Designer visual QA pass 3. File bugs with screenshots comparing design vs implementation 4. Prioritize bugs by severity 5. Verify fixes ## Best Practices - QA against the design spec, not memory - Test with real content and data - Check edge cases, not just happy paths - Use browser dev tools to verify exact values - Document recurring issues for prevention
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).
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
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).