Design QA — design quality assurance — is the practice of checking that what ships matches what was designed. It’s the step most teams skip and then can’t explain why the live product looks a notch worse than the mockups: quality gets designed, and then quietly lost somewhere between the file and the build. Design QA is how you stop that leak.
It’s the last gate in a healthy design operation — the point where the quality you invested in actually reaches users instead of eroding on the way.
What is design QA?
Design QA is a structured review of the built product against the design intent, before it reaches users. A designer (or the design lead) goes through the implementation and flags where it diverges from the spec — spacing, type, colour, states, motion, responsive behaviour, copy. It’s the design equivalent of engineering QA: not a fresh critique of the decisions, but a check that the agreed decisions were faithfully built.
Why design QA matters
Because quality leaks at the handoff. A design can be excellent and still ship wrong — a hover state that was never built, spacing that’s a few pixels off everywhere, a layout that collapses on mobile, an empty state nobody implemented. Individually small; collectively the difference between “polished” and “almost.” Users never see your Figma file; they see the build. Design QA makes the quality you designed the quality they actually get.
What design QA checks
A good pass covers more than “does it look right”:
- Spacing & layout — padding, alignment and grid match the spec
- Type & colour — the right styles and tokens, not approximations
- States — hover, focus, active, loading, empty, error — all built, not just the happy path
- Responsive behaviour — it holds up across breakpoints, not only the design width
- Interactions & motion — transitions and micro-interactions behave as intended
- Content & edge cases — long strings, missing data and real content, not lorem ipsum
- Accessibility — contrast, focus order and keyboard use survive the build
How to run design QA
Keep it structured and part of the workflow, not an afterthought. Review the built feature on a staging environment against the design; log issues in one place with clear priority (blocker, polish, nice-to-have); and route them back through the same tracker engineering already uses, so nothing gets lost. Do it before release, not after, and make it a defined step in the delivery process so it can’t be skipped under deadline pressure.
Design QA vs design critique
They’re easy to confuse and both essential. Design critique improves the design before it’s built — it’s about making the right decisions. Design QA checks the build after — it’s about making sure those decisions survived implementation. Critique protects the design; QA protects the shipped product. Skip critique and you build the wrong thing well; skip QA and you build the right thing badly.
How to prevent QA issues in the first place
Prevention beats inspection. The teams with the fewest QA issues aren’t the ones who check hardest — they’re the ones who’ve removed the ambiguity. A shared design system means engineers build from the same components designers used, so there’s simply less to get wrong. Clear handover — documented states, specs and intent — removes guesswork. And involving engineering early surfaces feasibility issues before they become QA bugs. Good operations turn design QA from firefighting into a quick final check.
Frequently asked questions
What is design QA?
Design QA (design quality assurance) is the practice of checking that what ships matches what was designed — spacing, states, responsive behaviour, interactions, content and accessibility. It’s the final gate that stops quality being designed and then quietly lost in the build.
Why is design QA important?
Because design quality leaks at the handoff. A design can be excellent and still ship wrong — off spacing, missing states, broken responsive layouts — if no one checks the built result against the intent. Design QA is what makes the quality you designed the quality your users actually get.
What’s the difference between design QA and design critique?
Critique improves the design before it’s built; design QA checks the build against the design after. Critique is about making the right decisions; QA is about making sure those decisions survived implementation. You need both — critique protects the design, QA protects the shipped product.
How do you reduce design QA issues?
Prevention beats inspection. A shared design system means engineers build from the same components designers used, so there’s less to get wrong; clear handover with documented states and specs removes ambiguity; and involving engineering early catches feasibility issues before they become QA bugs. Good operations turn QA from firefighting into a quick final check.