Design QA: reviewing what was built before launch
Design QA compares what was built with the design before launch. What to review, how to log and prioritize deviations, and what to do with those you keep.
What is it, and why does it go wrong?
A design can be excellent and the published product can look wrong. That happens because of small differences: a font one size too large, a margin that changes on a tablet, a focus state nobody implemented. Hypermatic says this is really a web QA problem: an implementation review catches the details that make a page feel finished.
The difference from handoff is clear. Handoff delivers the design and its specification to the development team. Design QA verifies afterwards that what was built matches that delivery. Without the second step, the first guarantees nothing.
What is reviewed?
Hypermatic mentions alignment, spacing, typographic rhythm, image crops, content order and responsive polish. Design System Problems proposes per-component checklists and gives examples:
- For buttons: default, hover, active, focus and disabled states.
- For forms: designs for validation states and error messages.
That same source also lists animations, focus order, ARIA requirements, text truncation and empty states among what must be specified; those are also what must be checked later.
The list is not fixed. Each product needs its own, but it should include what the team knows tends to break: long text, languages with longer words, error states and the in-between widths nobody tests.
For those cases, review the loading states and the error state patterns, which are often the first things left out.
How is the review organized?
Rubyroid describes a flow that makes sense in practice:
- The design team creates the mock-ups and the client approves them.
- The development team implements using Figma’s developer mode.
- Before launch, the design team reviews the implementation against the mock-ups.
- Issues are documented, sent back for correction, and the cycle continues until everyone is satisfied.
- After corrections, a new review is done, usually by whoever runs QA.
Design System Problems proposes verifying at two moments. Before coding, confirm that the specification is complete: dimensions, colours, spacing, states, responsive behaviour, interactions and accessibility. After implementation, compare the code with the specification, through designer review, automated comparison with design-tool exports or structured QA. Gaps found in the first phase are resolved by designer clarification before development effort is spent.
That is why the redline matters so much: if the specification has gaps, the later review can only find what the team assumed wrongly.
How are deviations prioritized and logged?
Rubyroid categorizes issues by urgency and reports them with screenshots, recordings and a priority note, in whatever tool the team already uses. Hypermatic suggests prioritizing deviations that affect trust, conversion, accessibility or brand quality, and warns: “Not every pixel mismatch matters, but unexplained drift should be visible.”
A useful log has four fields: which screen or component, what should appear, what does appear, and its priority. With those, whoever corrects it does not have to guess what was meant.
What do you do with deviations you keep?
Not every difference is an error. Sometimes development finds a technical constraint, and the real solution differs from the design. What you should not do is leave the difference unrecorded.
Document the decision and update the design file so it reflects what was built. That way the next team will not take the difference for a mistake, and the design remains a source of truth. If the deviation affects a system component, the correction belongs in the component, not in a loose screen.
Example
Illustrative example: a team is launching a payments app. In the pre-launch review, the designer finds that the loading state of the “Pay” button does not exist in the built version, and that on 360-pixel screens the amount gets cut off. Both problems go into the log with screenshots and high priority, because they affect trust in the payment. A third problem, a different margin in the header, is documented as an accepted deviation, because development adjusted it for an operating-system constraint. The design file is updated.
For your next launch: take three screens, compare them with the design at 360 pixels and with system text at its largest size. The differences you find are the QA log of your first round.
When should you NOT run a full review?
- When the change is minimal and was already reviewed in a test environment. Repeating everything consumes time without adding value.
- When the team has nobody responsible for the final review. Hypermatic notes that teams fail when nobody owns the final check.
- When the review is reduced to a general comparison. If states and details are not looked at, it is not a review; it is an impression.
Common mistakes
- Doing QA only on desktop and publishing without testing other widths.
- Not having a checklist and relying on each reviewer’s memory.
- Reporting problems without a screenshot or a description of what was expected.
- Leaving deviations undocumented, so the design file stops being true.
- Reviewing late, when development can no longer change anything without delaying the launch.