Design QA: who checks the build matches the design, and how

Design QA is the review of built interface against the agreed design before it reaches users. A named reviewer, either the designer who owns the screen or a design engineer who can read the code, opens each ticket's work in a running build and checks it against the design on seven things: layout, tokens, states, interactions, responsive behaviour, accessibility and copy. Every gap goes into a report with one row per issue, a severity and an owner. The product owner signs off.

Run it on every ticket, not once at the end. A ticket is done when the user would see what was designed, not when the code merged. Reviewed per ticket, a gap is a small fix the developer still has in their head. Saved for the end, the same gaps arrive in a pile a week before launch, and each one becomes a negotiation.

This page covers that review step. Keeping the build close to the design while it is written is a separate job, covered in our guide to moving from Figma to React.

What design QA is, and what it is not

Design QA asks one question: does the built screen look and behave the way the agreed design says it should? It compares three things: the design file, the build running in a browser or on a device, and the written rules that sit behind both, such as the design system and the acceptance criteria.

It is not functional QA. Whether the export produces the right file, whether the permissions logic is correct, whether the page loads fast enough: those belong to testers and engineers. The two overlap at the edges. If the reviewer cannot reach an error state because the form never fails, that is a functional question, and it goes to the tester rather than into the design QA report.

It is also not a redesign. A reviewer who starts suggesting new ideas in the report turns a check into a debate. New ideas go into the backlog as design work. The report holds only the gaps between what was agreed and what was built.

What design QA checks: a checklist by category

Work through the build category by category, at each supported width, signed in as each role that sees the screen.

Layout and components

• Spacing, alignment and grid match the design, measured, not judged by eye.
• The build uses the design system component and the right variant, not a local copy that looks similar.
• Long names, empty fields, missing data and large numbers still fit. Check with real content, not the sample text in the design file.

Tokens

• Colour, type, radius, shadow and spacing values come from the agreed tokens, not hard-coded values that happen to match for now. A hard-coded hex passes a visual check and then drifts the next time the palette changes.
• If your tokens are shared between design and code tools, the Design Tokens Community Group's first stable format (2025.10), published on 28 October 2025, gives both sides one vendor-neutral file to check against.

States

• Default, hover, focus, pressed, selected and disabled.
• Loading, empty, error, partial and success, for every component that fetches or saves data.
• What each user role sees, including a role with no permission to act.

Interactions

• What happens on click, submit and cancel matches the flow in the design.
• Validation appears at the agreed moment, in the agreed place.
• Keyboard focus order follows the visual order, and focus lands somewhere sensible after a dialogue closes.
• Motion and transitions match the spec, and nothing moves that was not meant to.

Responsive behaviour

• Each breakpoint in the design, plus the widths between them, where a layout can break without anyone noticing.
• Resized desktop windows, not only phone and desktop presets.
• Content reflows into one column at a width equivalent to 320 CSS pixels without sideways scrolling, which is WCAG 2.2 success criterion 1.4.10, Reflow.

Accessibility, the visual layer

Design QA catches the accessibility failures you can see. These are the WCAG 2.2 Level AA criteria worth checking on every ticket:

This is not a full accessibility audit. Screen-reader testing and a full conformance review need their own pass. But a focus ring removed in the CSS, or a grey that drifted from the token, is a design QA finding, and the cheapest moment to catch it is the ticket that introduced it.

Copy

• Strings match the agreed copy, including error messages, button labels and empty-state text.
• Truncation, wrapping and pluralisation behave as designed.
• Placeholder text from the design file has not shipped.

When to run it: per ticket, not once at the end

Per ticket is the default. The reviewer checks the ticket's work in a preview or staging build before the ticket closes, ideally before the pull request merges. The developer still has the context, the fix sits in one component, and nothing else has been built on top of the mistake yet. Put the design review in the ticket's acceptance criteria, so the ticket cannot close without it.

Per release adds a short pass that per-ticket reviews cannot do: walking whole journeys across screens built by different people. This is where you find two date pickers, three shades of the same grey and an error message written two different ways.

Once at the end is the pattern to retire. Every gap found then competes with a launch date. Small gaps get waved through, the waved-through gaps become the new normal, and the next team builds against what shipped rather than what was designed. That slow drift is the subject of our piece on silent UI regression debt.

Who reviews, and who signs off

Three roles, named per ticket rather than assumed:

• The developer self-checks against the design and the checklist before asking for review. Most spacing and token gaps should never reach the reviewer.
• The reviewer is the designer who owns the screen, or a design engineer who can read the code and say why a gap happened. One named person per ticket. "Design will look at it" means nobody will.
• The product owner signs off. When the reviewer and the developer disagree, or a fix would move the date, the product owner decides: fix now, ship with a logged minor gap, or change the design.

Some gaps are not mistakes. A developer may have found a better way to handle a state the design never covered, or a constraint the designer did not know about. Record those as justified changes and update the design file, so the design stays the record of what was agreed. Otherwise the next review flags the same difference again.

How to write the report: one row per issue

Use one row per issue, in the tool the team already works in: the ticket itself, the issue tracker or a shared table. A long comment thread hides issues; a row can be assigned, fixed and retested.

Each row holds:

1. ID and location: the screen, the component and a link to the build.
2. Screenshot of actual: cropped to the problem, with the viewport, browser and role.
3. Expected: a link to the design frame, and the token or spec value.
4. Actual: what the build does, in one sentence.
5. Steps to reproduce, if it needs a state or a role to see.
6. Type: a defect, a justified change, a missing state or an open question.
7. Severity: from the table below.
8. Owner: a named person.
9. Status: open, fixed, retested.

An illustration of one row, not a real finding: Invoice list, filter bar. At 1024 pixels wide, signed in as a viewer. Expected: the "Clear filters" button uses the secondary variant with the border token. Actual: the button has no border and its label contrast measures below 4.5:1. Type: defect. Severity: major. Owner: the front-end developer on the ticket. Status: open.

The type matters as much as the severity, because each type has a different next step. Engineering fixes defects. Design updates the file for justified changes. Missing states get designed, then built. Open questions go to the product owner. That is also how we structure findings when we run implementation QA for a team, with each fix retested in the build.

Severity levels

Severity ratings for interface problems go back to Jakob Nielsen's 0 to 4 scale for usability problems, published in 1994, which weighs how often a problem occurs, how hard it is to overcome and whether it keeps bothering users. For design QA, four levels are enough, each tied to a decision:

Agree the levels with the product owner before the first review, not during an argument about a specific issue. A shared bar is what makes the review quick.

Where visual regression tests and AI tools help, and where they stop

Visual regression tests protect a screen after it has passed design QA. They do not replace the review.

The reason is what they compare against. Playwright's screenshot comparison generates reference screenshots on the first run and compares later runs against them. Storybook's visual tests, which run through Chromatic, compare the rendered pixels of each story against known baselines, and a person accepts a change as the new baseline. In both, the reference is an earlier build, not the design. If the first build was wrong, the test faithfully protects the wrong version.

So the order is: run design QA, fix, then lock the approved state as the baseline. From then on the test catches unintended change between releases, which is where these tools are strong. Two practical notes from Playwright's own documentation: browser rendering varies with the host operating system, settings, hardware and other factors, so generate baselines in the same environment that runs the tests; and the comparison has a tolerance threshold you set, so decide it deliberately rather than raising it until the build passes.

AI tools can now compare a screenshot with a design frame and draft findings. Treat their output as draft rows that a reviewer confirms or deletes. A model sees differences; it does not know which differences were agreed as justified changes, which states exist outside the frames it was shown, or whether a gap matters to the user. The same holds when AI writes the front-end code itself: the review moves towards judgement, which we cover in accepting AI-generated front-end code.

Making it stick

Design QA holds when it is part of the definition of done rather than a favour asked of the designer. Four things make that true:

• A shared bar, written down: the checklist above, the severity table and the supported widths and roles.
• A named reviewer on each ticket, with time in the sprint for the review.
• A report format everyone uses, one row per issue, with an owner and a retest.
• A sign-off rule: the product owner decides on anything left open, and the decision is recorded.

If the same kinds of gap keep returning across releases, the problem sits upstream of the review: in the handoff, the shared components or the sign-off itself. Tracing a recurring gap back to the step where it started is a different exercise from checking one ticket, and it is what our design-to-code audit does.