Runs an ordered design QA pass over an implemented UI – layout, type, color, states, motion, content – against the design spec, with concrete tolerances and a filed defect list.
Runs an ordered design QA pass over an implemented UI - layout, type, color, states, motion, content - against the design spec, with concrete tolerances and a filed defect list. Use when someone asks "QA this build against the designs", "does the implementation match Figma", "is this ready for design sign-off", or before releasing a UI change. Do NOT use for critiquing the design itself - use design-critique instead; for a full WCAG conformance audit, use accessibility-audit; for writing the spec the build is checked against, use design-handoff-doc.This is the skill's description: the text your AI reads to decide when the skill applies.
design-qa-checklist/SKILL.md
---
name: Design QA Checklist
description: Runs an ordered design QA pass over an implemented UI - layout, type, color, states, motion, content - against the design spec, with concrete tolerances and a filed defect list. Use when someone asks "QA this build against the designs", "does the implementation match Figma", "is this ready for design sign-off", or before releasing a UI change. Do NOT use for critiquing the design itself - use design-critique instead; for a full WCAG conformance audit, use accessibility-audit; for writing the spec the build is checked against, use design-handoff-doc.
---
# Design QA Checklist
Design QA catches drift between design intent and shipped code before it compounds into a product that looks 90% right everywhere and fully right nowhere. The costly failure is an unordered spot-check: motion gets polished while the grid underneath is wrong, so half the findings are invalidated by the layout fix. Run the pass in order - layout first, because layout errors move everything downstream - and file every deviation with expected vs. actual values, not adjectives.
## Operating procedure
### Step 1: Gather inputs
- The design source of truth (Figma file, spec, or design-handoff-doc output) and the build URL or branch.
- The token set (spacing scale, type scale, color tokens, motion tokens). If none exists, note that and QA against explicit spec values; flag "no token system" as its own finding.
- Supported breakpoints and the narrowest supported viewport (default: 320px).
- Whether dark mode and motion specs exist (default: assume light mode only, no motion spec - label as assumption).
### Step 2: Layout pass
- Every margin, padding, and gap matches its token or explicit spec value (space-4 = 16px, not 15px or 18px). **Tolerance: any deviation greater than 2px is a defect.** Deviations of 2px or less at fractional zoom may be sub-pixel rendering - re-measure at 100% zoom and 1x density before filing.
- Grid columns, gutters, and container max-widths correct at every breakpoint.
- Alignment verified with a grid overlay or devtools ruler, not eyeballing.
- Flag every magic-number hardcoded value that should reference a token.
- Resize from 320px to the widest supported viewport: zero horizontal overflow anywhere.Click to play with sound.