Design QA, in one loop.

Design QA is the review of a built user interface against its design intent before the change merges. It covers layout, typography, color and tokens, states, responsive behavior, motion, content and accessibility, and it ends with the differences fixed rather than filed.

QA testing checks whether the feature works against its requirements. Design QA checks whether the built interface matches the design and the design system, and a feature can fail that check while every test passes.

The designer who owns the screen runs the design QA pass, because they hold the intent the build is compared against. The engineer stays the code reviewer and the merge gate.

Design QA happens on the pull request or preview build, before merge. After release, every finding competes with new work for a place in the backlog and rarely wins it.

A design QA checklist groups checks by layout and spacing, typography, color and tokens, states and interaction, responsive behavior, accessibility, content and motion. Each group names what to compare against: the design file, the design system tokens in code, the written states or real data.

Visual regression testing compares screenshots of the current build with an approved baseline from a previous build, so it catches unintended change. Design QA compares the build with the design, so it catches drift that was there from the first build.