Design QA

What is Design QA, and how specifically does it differ from "visual regression testing"?

Design QA compares "what's actually live in production" against "the original design spec" — checking whether a button's spacing genuinely matches the value annotated in Figma, whether a color's hex code matches the Token defined in the Design System, whether copy has been altered. The question this answers is "was this built correctly," and the baseline it's measured against is the designer's original intent.

Visual regression testing is a completely different question: it compares "this build" against "the last build that passed testing" to check for unintended changes, aiming to catch "something accidentally got broken." The baseline is a screenshot captured at some past point in time — not the design spec itself. This means visual regression testing might catch a genuine difference between this build and the last one, with no way of knowing whether that difference actually matches what the designer intended. Conversely, a screen can pass visual regression testing (matching the baseline screenshot) and still not genuinely match the design spec — if the baseline screenshot itself was wrong to begin with, regression testing just ensures that mistake gets reliably replicated.

Why do you need two different checking mechanisms — can't just one of them be enough?

Because the problems each one catches don't overlap at all — each has a blind spot the other can't substitute for. Visual regression testing is good at scanning across an entire interface broadly and frequently, quickly catching "where something unexpectedly changed," which suits protecting a set of screens already confirmed correct from accidentally getting broken during subsequent development. But it has no ability to judge whether a change actually matches design intent, because it's measured against an old screenshot, not the design spec.

Design QA is good at judging whether "what was newly built genuinely matches what the designer wanted," suited to evaluating whether a new implementation choice fits a product's existing visual and interaction conventions — but this kind of check usually requires human effort to verify item by item, and can't be automated at the same scale and frequency as visual regression testing. In practice, the more reliable approach pairs both: use visual regression testing to protect already-confirmed-correct parts from getting accidentally broken, and use design QA specifically on newly added or modified parts to confirm they were actually built right. Running only visual regression testing effectively ensures a baseline that might already be wrong gets reliably replicated; running only design QA misses non-target areas that shifted unintentionally, not through a deliberate change.

How is Design QA actually carried out in practice, and what role do AI tools play in this process?

Traditionally, design QA is entirely manual: a QA person or the designer themselves holds the design file next to the actual live build and compares every component's spacing, color, copy, and interaction detail one by one — a process that's time-consuming, labor-intensive, and prone to human oversight. AI-assisted design QA tools that have emerged in recent years work by having the AI directly compare a live, running build against a Figma design spec, automatically flagging discrepancies between the two and drafting an initial issue description — automating the two highly repetitive steps of "finding a difference" and "drafting an initial description of the issue."

Worth noting: an AI-assisted design QA tool only replaces the repetitive, mechanical parts of the process (screenshot comparison, initial issue flagging) — it doesn't replace human judgment about design intent and user experience quality. An AI can flag that "this button's spacing is off from spec by 4 pixels," but it can't judge whether that discrepancy actually matters visually, or whether it's worth prioritizing a fix. That kind of judgment, which requires context, still needs a human to make the final call.

If I generate a prototype with an AI design tool (Claude Design, say) that's later handed off to an engineering team to implement, what practical significance does this Design QA step have for me?

This step matters especially because interfaces produced by AI app generation tools (whether design prototyping tools or code generation tools) often carry noticeable "visual debt" — inconsistent spacing, colors not mapped to the Design System, the same interaction pattern implemented differently across different screens. These problems often aren't immediately obvious at generation time, because each screen looks reasonably fine on its own — the inconsistency only shows up once they're compared side by side. This is exactly the concrete manifestation, at the implementation stage, of the "prototype debt" discussed in an earlier piece — design QA is the mechanism that proactively catches these gaps at this stage.

In practice, if your prototype is genuinely headed for engineering implementation, it's worth running a design QA pass during the generation stage itself, checking what was generated against your original design intent (or an imported design system spec) item by item, catching real gaps that need fixing — rather than only discovering "this doesn't match the design file" after the engineering team has already built and shipped it, at which point the cost of fixing it is far higher than handling it at the prototype stage.