Design QA is the checkpoint where someone compares the live (or staging) website against the design files. Does the spacing match? Are the fonts correct? Does it look right on mobile? It's the last line of defense before visual bugs ship to production.
Every web project has a gap between what the designer intended and what the developer built. That's not a failure—it's natural. Different tools, different interpretations, different constraints. Design QA exists to close that gap before users see it.
What design QA catches
- Spacing issues: Margins and padding that don't match the design—the most common finding in any QA round
- Typography drift: Wrong font sizes, weights, or line heights, often off by just 2-4px
- Color mismatches: Hex codes that are close but not exact (the difference between #3B82F6 and #2563EB is subtle but real)
- Responsive breakage: Layouts that break at certain viewport widths or look different from responsive mockups
- Missing states: Hover, focus, active, error, loading, and empty states not implemented
- Asset quality: Images that are blurry, cropped wrong, wrong aspect ratio, or missing entirely
- Alignment issues: Elements that are visually off-center or inconsistently aligned
Who does design QA
Different roles bring different perspectives:
- Designers: Comparing their work to the build—they catch the subtle issues because they know the design intimately
- Dedicated QA: Systematic checks against acceptance criteria, thorough and consistent
- Project managers: Final review before client handoff, focusing on the big picture
- Clients: Approving that the build matches expectations—they often catch things internal teams overlook with fresh eyes
A design QA checklist
Work through these systematically for each page:
- Typography: Font family, size, weight, line-height, letter-spacing, text color
- Spacing: Margins between sections, padding inside containers, gap between elements
- Colors: Background colors, text colors, border colors, button colors in all states
- Images: Correct assets, right dimensions, proper cropping, loading behavior
- Layout: Grid alignment, container max-widths, responsive behavior at each breakpoint
- Interactive states: Hover, focus, active, disabled states for all interactive elements
- Forms: Input styling, placeholder text, validation states, error messages
- Animations: Transitions, hover effects, scroll animations match spec
The design QA workflow
- Prepare the checklist: Key pages, breakpoints, and states to review
- Compare systematically: Design file on one side, live site on the other
- Log issues visually: Pin feedback directly on the elements that need fixing, with specific CSS values
- Prioritize: Separate blockers (broken layout, wrong brand colors) from nice-to-haves (2px spacing difference)
- Verify fixes: Check each item after the developer addresses it—don't assume it's fixed without looking
Common mistakes
- Reviewing only at one breakpoint: A page can look perfect at 1440px and broken at 768px. Check every breakpoint in the design file.
- Not checking interactive states: The default state looks great, but what about hover? Focus? Error? Disabled? These are frequently missed.
- Vague issue descriptions: "Spacing is off" doesn't help. "Section padding is 48px, should be 64px per the design" does.
- QA-ing before dev is done: Reviewing an incomplete build wastes everyone's time. Wait until the developer marks it ready.
- Skipping dark mode or theme variants: If the design includes alternate themes, QA them all.
For a practical guide to using CSS inspection during QA, see how to inspect CSS for faster website QA.
Best practices
- Use the design file as your source of truth, not your memory of what it should look like
- Check CSS values directly instead of eyeballing—inspect mode makes this fast
- Review at real content lengths, not just placeholder text from the design
- Log issues with exact values: "font-size: 14px, design spec is 16px" is actionable; "text looks small" isn't
- Group issues by severity so developers fix blockers first
Design QA with Huddlekit
Huddlekit's inspect mode shows CSS properties—font sizes, colors, spacing—without opening DevTools. Pin a comment, note the discrepancy, and the developer sees exactly what needs to change. Compare breakpoints side by side to catch responsive issues before they reach production.
