Design QA is the review of a built user interface against the design it was meant to implement, done on the pull request before the change merges. It covers layout and spacing, typography, color and tokens, states, responsive behavior, motion, content and accessibility, and it is finished when the differences are fixed, not when they are filed.
This page draws the line between design QA and its neighbors, explains why builds drift, sets out a six-step process and a checklist to run on any pull request, compares the tooling as of September 2026, and describes what changes when the designer fixes the build instead of describing the fix.
Key takeaways
- Design QA compares the build with the design. QA testing checks whether the feature works, and visual regression testing checks whether the build changed since the last approved build.
- Drift is structural: handoff assumptions, hardcoded values, undesigned states, missing breakpoints, unspecified motion and placeholder content produce the findings that recur on pull request after pull request.
- Run the pass on the pull request, before merge, with the designer who owns the screen comparing and the engineer reviewing the code.
- Findings that are not fixed become design debt, because every new screen copies the one that drifted.
What is design QA?
Definition
Design QA is the review of a built user interface against its design intent, covering layout, typography, color and tokens, states, responsive behavior, motion, content and accessibility, run on the pull request before the change merges.
The practice has several names, and they point at slightly different slices of it. Design quality assurance is the formal term. Engineering teams that run the pass inside code review tend to call it design implementation review, or design to development QA when they mean the boundary where a file becomes running code. UI QA usually narrows it to the visual layer. Under every name the reference is the design and the design system, and the subject is the build.
| Dimension | Design QA | QA testing | Visual regression testing |
|---|---|---|---|
| Compares | The build against the design file, design system tokens and written states | The build against functional requirements and acceptance criteria | Screenshots of the build against an approved baseline from a previous build |
| Who runs it | The designer who owns the screen, with the engineer as code reviewer | QA or the engineers who built the feature, largely automated | CI, with a person approving each diff |
| When | On the pull request, before merge | Before release and continuously in CI | On every commit or pull request |
| Catches | Spacing, type, color, state, responsive, motion, content and accessibility drift from the design | Broken logic, failed flows, wrong data, crashes | Unintended change since the last approved build, whether or not that build matched the design |
The last cell matters. A visual regression tool defends a baseline that may have been wrong from the first build, and neither neighbor asks whether the build matches the design.
Why the build drifts from the design
UI drift is structural rather than careless. A design file cannot hold everything the build needs, and whoever is closest to the code fills the gaps. Six sources account for the findings below.
Handoff assumptions. The file says what the screen looks like, and the engineer fills in what it does not say. In Figma's Designer and Developer 2025 Trends report (Figma, 2025), 52% of developers named differences in assumptions as their top challenge in working with designers, and Figma's design statistics page (Figma, 2025) puts the share who say the handoff process could be improved at 91% of developers and 92% of designers. Every added artifact is another place to lose the design, which is the argument of the design handoff post and the reason a Figma developer handoff needs states and breakpoints written down.
Tokens. The design uses spacing.4 and color.text.muted. The build uses a raw pixel value and a hex code that match today and stop matching when the design system changes. Hardcoded values are the hardest finding to see, because the screenshot looks right.
States. Most designs cover the default state and one or two others. Hover, focus, loading, empty, error and disabled are often not in the file, so the engineer invents them or leaves them out.
Responsive. The file has a desktop frame and perhaps a mobile one. The build has to work at every width between them, and the points where columns collapse, navigation changes and type scales down all get decided in code.
Motion. Durations, easing and what animates on enter and exit are rarely specified, so the build uses the framework default or nothing. Both look wrong next to a design that implied motion without documenting it.
Content. Designs use short names and tidy numbers. Production has a company name that fills the row, a currency with extra decimals and a German translation much longer than the English. Truncation, wrapping and localization only show up with real strings.
The design QA process, step by step
The process below fits inside a sprint and assumes a pull request with a preview build.
- Run it on the pull request, before merge. After release, every finding competes with new work for a backlog slot and rarely wins it. Before merge, it blocks the merge.
- The designer who owns the screen runs it. They hold the intent the build is compared against and can tell an acceptable deviation from a wrong one. The engineer who built the change reviews the code, not the design, and stays the merge gate.
- Compare against four things. The design file for layout, type and color. The design system tokens in code, because a value that matches the file and bypasses the token is still a finding. The written states, so a missing hover, focus, loading, empty or error state counts. Real data from a seeded preview or staging account, because placeholder content hides content findings.
- Run each checklist group at each breakpoint. Work through the checklist below one group at a time, then repeat at every breakpoint. Browser dev tools do the measuring: computed styles for spacing and type, the device toolbar for widths, the accessibility pane for contrast and names.
- Log one finding per line. Each line records the location, the expected token or value from the design, the value found in the build, a severity and a screenshot:
/settings/billing PlanCard: expected spacing.4 (16px), found 14px padding-top, P2. A finding without an expected value is an opinion, and opinions do not get fixed. - Fix it by one of two routes. The first is a comment thread or a ticket: the engineer picks it up in the next free slot, and the designer runs a second pass on the new build. The second is the designer fixing it in Modeinspect: they open the pull request as a running build, apply the fix with design controls, and ship a new pull request. Code review still happens on the result. The post on building features faster with AI covers what that loop does to a sprint.
The design QA checklist
Run each group against the pull request preview at every breakpoint, and log every mismatch as a finding with an expected and a found value. A UI QA checklist or visual QA checklist covers the first five groups. This one adds accessibility, content and motion, which drift on the same pull request, and treats the accessibility checks as merge gates.
| Group | What drifts most often | Compare against |
|---|---|---|
| Layout and spacing | Padding and gaps set by eye | Design file, spacing tokens |
| Typography | Sizes that match the file but bypass the type scale | Type scale tokens |
| Color and tokens | Hex values in place of semantic tokens | Color tokens in code |
| States and interaction | Hover, focus, loading, empty and error missing or invented | Written states, component library |
| Responsive | Breakpoints decided in code, overflow at narrow widths | Design system breakpoints |
| Accessibility | Contrast, focus visibility, target size, missing names | WCAG 2.2 |
| Content | Truncation, wrapping and localization with real strings | Real data, copy deck |
| Motion | Framework default durations and easing | Motion tokens or written spec |
Layout and spacing
- Every padding and gap in computed styles maps to a spacing token, not a pixel count that happens to be right.
- Text baselines and icon centers align across every row.
- Container max widths and gutters match the design system grid.
- No margins on children where the parent should carry gap or padding.
- Nested components do not double up padding at their boundaries.
Typography
- Every text style maps to a type scale token by size, weight, line height and letter spacing.
- Heading levels follow the hierarchy in the design.
- The intended font family renders (check computed font-family for a fallback).
- Line length at the widest breakpoint matches the design's measure, and headings wrap acceptably with real content.
Color and tokens
- Every raw hex, rgb or hsl value is replaced with the semantic token the design uses.
- Text, border, surface and icon colors are checked separately, since they drift separately.
- Dark mode or any second theme reads from the same tokens.
- Disabled and muted colors come from their own tokens rather than opacity on the default.
- Shadows and border radii match their tokens.
States and interaction
- Hover, focus, active, disabled, loading, empty and error are triggered on every interactive element and compared to the written state.
- Focus uses the design system focus style, not the browser default.
- Loading states hold layout so content does not jump when data arrives.
- Empty states carry the designed copy and action.
- Tab order, enter and escape behave as designed.
Responsive
- Every group above is run at each breakpoint the design system defines, and at the widths between them where columns and navigation change.
- No horizontal overflow, clipped content or overlapping elements at the narrowest width.
- Touch targets and spacing scale as the design intends on small screens.
- Images keep their aspect ratio and crop as designed.
Accessibility
- Text contrast passes the browser's contrast checker. In the WebAIM Million (WebAIM, February 2026), automated detection alone found low-contrast text on 83.9% of the one million home pages tested, up from 79.1% in 2025.
- Every image has alt text that says what the image is for. The same report found 16.2% of home page images missing alt text.
- Focus is not hidden behind sticky headers or overlays, which WCAG 2.2 (W3C Recommendation, 5 October 2023) added as 2.4.11 Focus Not Obscured (Minimum).
- Pointer targets meet 2.5.8 Target Size (Minimum), also new in WCAG 2.2.
- Form fields have visible labels and error messages tied to the field.
- The same WebAIM run detected WCAG 2 failures on 95.9% of home pages, at an average of 56.1 errors per page, which is the case for treating every line above as a merge gate.
Content
- Placeholder strings are replaced with real data before the pass.
- Truncation and wrapping are checked on the longest real value in each field.
- Number, date and currency formatting match the locale the design assumed.
- Copy matches the approved copy deck, including capitalization, and at least one longer-running language is tested if the product is localized.
Motion
- Every transition duration and easing matches the motion tokens or the written spec.
- Enter and exit animations both exist.
- Reduced-motion preferences are respected.
- No layout shift from animating properties that should be transforms, and loading animations stop when content arrives.
Design QA tooling in 2026
As of September 2026, each tool below covers part of the pass, so the table also names what each one does not do.
| Tool (checked 16 September 2026) | What it does for design QA | What it does not do |
|---|---|---|
| Figma Dev Mode | Marks frames, sections and components Ready for dev, and Compare changes diffs the current design against a previous version. Paid plan and a Full or Dev seat (Figma help). | Does not see the build, only what changed in the design. |
| Chromatic | Visual tests on Storybook stories with review of each diff. Free tier of 5,000 snapshots a month (Chromatic pricing). | Compares with the last accepted snapshot, not the design. Covers only what has a story. |
| Percy by BrowserStack | Screenshots in CI compared with an approved baseline (BrowserStack docs). | The baseline is a previous build. Blind to states never built. |
| Playwright toHaveScreenshot | Writes a baseline on the first run and fails later diffs beyond a configurable maxDiffPixels (Playwright docs). | Approves whatever the first run produced. |
| Browser dev tools | Computed styles, device emulation, contrast checks and the accessibility tree. The main instrument of a manual pass. | Records nothing and fixes nothing. |
| Storybook | Renders components and their states in isolation, so undesigned states show early. Visual tests run through the Chromatic addon (Storybook docs). | Hides findings that appear only on the composed page. |
| Modeinspect | Opens any pull request as a running build, applies fixes with native design controls, reflects each change in code, and ships a new pull request. | Does not replace engineer code review, CI or the release process. |
Chromatic, Percy and Playwright screenshots share one shape: they compare the build with a previous build. They catch an unintended change on a screen nobody meant to touch and miss a screen that was wrong from its first commit. Once a design QA pass has approved a baseline they guard it well, and on teams with a Storybook, visual tests on stories plus design QA on the composed page is a workable split.
With Modeinspect, design QA runs about seven times faster, because the designer fixes the build instead of describing the fix. Its customer story with Prelude records idea to merged pull request in 13 days, from about 31, and five or more handoffs per feature down to one. The same product runs design to code and AI prototyping on the same codebase, so a QA fix and a new screen share components and tokens.
Design debt and UX debt: the cost of skipping design QA
Design debt is the accumulated gap between the product as built and the design system and design intent it was meant to follow, and every unfixed design QA finding adds to it. UX debt is the set of ongoing experience problems caused by launching fast, easy or careless solutions, the experience-side analog of technical debt. That is Anna Kaley's definition for Nielsen Norman Group in UX Debt: How to Identify, Prioritize, and Resolve (NN/g).
The two compound the same way. A drifted screen ships, and the next screen in that area is built by copying it, because copying a screen that exists is faster than reading the design system. The hardcoded value and the improvised hover are now in every copy, and when the design system changes a token, the copies do not follow. That is how design debt grows without anyone deciding to take it on, and in large organizations the same leak is why strategy rarely survives the handoff.
UX debt grows from the same findings, seen from the user's side: the invented error state does not say what to do next, and the truncated name hides which account is which. The difference between UX debt and design debt is mostly who notices first, users or designers, and once users notice, the fix costs a project rather than a pull request.
Design QA for designers who can fix it themselves
When the designer edits the build in the pull request, the review step becomes a fix step. The pass runs the same checklist at the same breakpoints, but instead of a comment and a second implementation in a later sprint, the designer sets the token, checks the state and moves to the next line. The handover happens once, at code review, instead of once per finding.
What stays is everything that protects the codebase: engineer code review, CI and the release process. The designer's pull request gets the same review as anyone else's, which is what makes engineers willing to merge it. The developer experience page covers that side of the loop.
This suits product designers on React or Next.js codebases with a design system in code, where the tokens and components a fix should use already exist. The designer does not write the code. They work with layout, type, color and state controls on the running build, and the code is the output, following the codebase's conventions so the reviewer reads a normal diff. To see it on your own pull request, book a demo.
Frequently asked questions
What is design QA?
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.
How is design QA different from QA testing?
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.
Who is responsible for design QA?
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.
When should design QA happen?
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.
What is in a design QA checklist?
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.
What is the difference between design QA and visual regression testing?
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.