The handoff doesn't end when the developer picks it up

Design QA (quality assurance) is the practice of comparing built UI against design specifications after development and before a feature ships. Someone with design judgment — typically the designer who worked on the feature — reviews the live or staging build and flags discrepancies.

Those discrepancies are usually small individually: a font size off by 2px, a colour that reads slightly warm when it should be neutral, a disabled state that was never implemented, a mobile layout that breaks at 375px. None feel urgent. But they compound. A product that ships without design QA accumulates visual and behavioural drift over time until the Design System becomes documentation for a product that no longer resembles it.

This isn't about pixel perfection for its own sake. Users notice inconsistency even when they can't name it. Coherence builds trust; inconsistency quietly undermines it.

The reason is almost always timing. By the time development is done, the team is under pressure to ship. Design QA feels like it will delay the release. And because design discrepancies don't cause outright bugs, they don't trigger engineering review either — they just go out.

The cost is real but slow-moving, which makes it easy to ignore quarter after quarter. UX Debt accumulates the same way technical debt does: one compromised component at a time, until realigning the product with its design system is a multi-sprint effort.

There's also a subtler cost. When developers know their implementation won't be reviewed against the spec, "close enough" becomes the implicit standard. Design QA creates accountability on both sides — it tells developers their work will be assessed, which consistently raises implementation quality before the review even happens.

The scope of a design QA session should scale with the complexity of the feature. For a new screen or component, check:

• Typography: font size, weight, line height, and colour for every text style on the page
• Spacing: padding and margin against the Design Tokens and grid system
• Colour: backgrounds, text, borders, and fills against token values — not just visual approximation at 1x zoom
• Interactive states: default, hover, focus, active, disabled, loading, and error for every actionable element
• Responsive behaviour: at every breakpoint specified in the design
• Edge cases: long text, missing data, Empty States, and maximum content volume
• Motion: transition duration and easing curves if animation was specified

Use design system documentation as the reference, not the Figma file alone. If the system is the source of truth, QA verifies that source is applied correctly — not just that it looks passable on first glance.

There's no single right answer, but the practical options are:

• Designer reviews developer's implementation: Most common and most reliable. The designer knows the intent and catches deviations that look visually similar but are behaviourally wrong — a focus state that's styled but doesn't actually receive keyboard focus, for instance.
• Developer self-reviews against spec: Faster. Less reliable. Developers catch missing states; they're less consistent at catching subtle visual drift or intent-level mismatches.
• Dedicated QA engineer with design specs: Works well in larger teams where a QA function already exists. Requires the QA engineer to have real design literacy — checking against intent, not just testing for functional breakage.

The minimum viable version: one person with design judgment looks at every feature before it reaches production. Who that person is matters less than that it actually happens.

The most common failure mode is treating QA as a phase after the sprint rather than a step within it. By the time the sprint closes, the developer has context-switched, and reopening a ticket for design fixes feels like going backwards.

A better pattern: design QA happens in a defined slot inside the sprint, before anything moves to "ready for release." Frame it as the final step of the Design Handoff process — the handoff isn't complete until QA is signed off.

For teams shipping to a staging environment, weekly QA sweeps work well: one hour per week where a designer walks through everything that reached staging since the last review. Catching issues in staging is far cheaper than catching them after users file reports.

The teams that skip design QA most consistently are the ones that haven't calculated how much time they spend cleaning up visual debt. Run that number once — it usually changes the conversation.