Design QA

Design QA is the review step in which a built screen is checked against the approved design for spacing, type, colour, alignment, states and responsive behaviour, and every mismatch is filed as a defect. It is done by a designer or a design-literate tester on the finished build, usually after functional QA, because a feature can work correctly and still not look like what was signed off.

The longer version

The reviewer opens the design file and the built page side by side and walks the screen state by state: default, hover, focus, empty, loading, error, and each breakpoint the design covers. Every difference is filed against the element it concerns, with the expected value from the design and the actual value from the build. A margin that is sixteen pixels in the mock and twenty in the browser is a design QA defect. So is a button with no focus ring, when the design showed one and the developer never built it.

Design QA is distinct from functional QA and from a design review. Functional QA asks whether the feature does what the acceptance criteria say; design QA assumes it does and asks whether it looks and moves the way the design says. A design review happens before build, on the design itself, and judges whether the design is right. Design QA happens after build and judges whether the build is faithful. The nearest defect category is the visual bug, and most of what design QA produces is a list of them.

The step is usually skipped because it sits at the end, after the deadline has already absorbed the schedule, and because each mismatch feels small on its own. The cost arrives later as a product that is recognisably built from the design and never quite matches it, a kind of design debt no ticket describes. The second failure is a note that names the screen and not the element, so the developer opens the page and cannot tell which of a dozen spacings the designer meant. A note that carries the element, the expected value and the actual one closes in one pass.

Common questions

Who does design QA?

The designer who produced the screens is the best reviewer, because they hold the intent the file cannot express, such as which deviations matter and which were left loose on purpose. On teams without designer time, a tester working from the design file and a written spacing and type scale does it, and escalates the judgement calls to the designer.

When is design QA done?

After functional testing passes and before release, on a staging build that carries the final assets. Doing it earlier wastes the review on layout that will still change; doing it on production turns every fix into a hotfix. Teams that ship continuously run it per feature, on the preview build of the pull request, rather than once per release.

What is the difference between design QA and visual regression testing?

Visual regression testing is automated: a tool screenshots a page and compares it with a previous screenshot, catching anything that changed. Design QA is a person comparing the build with the design, catching what was never right in the first place. The first protects an approved state; the second is how that state gets approved.

What is the difference between design QA and a design review?

A design review happens before anything is built, on the design itself, and asks whether the design is right: whether it solves the problem, fits the system and can be built. Design QA happens after the build and asks whether the build is faithful to the design that passed review. A review can reject a design; design QA can only report where the build departs from it.

What does a design QA checklist cover?

Spacing and alignment against the grid, type sizes and weights, colours and contrast, iconography, every interactive state including hover, focus, disabled, loading, empty and error, responsive behaviour at each breakpoint the design defines, motion and transitions, and copy as written in the design. Each line is checked per screen, and each mismatch is filed against the element with the expected value and the actual one.

Bug reports that arrive ready to triage.

Collect replay, console, network and browser context with the Free plan.

<script src="…/widget.js" data-key="pb_pub_…">