Design QA: Checking the Build Against the Design
By CodexierPublished 5 min read
Between an approved design and a released product there is always drift: spacing that is slightly off, a hover state nobody built, an error message that breaks the layout on a small phone. None of it is dramatic on its own, but together it makes a product feel unfinished. Design QA is the review step that catches this before release. This guide gives you a routine you can run on any project, with or without a designer on the team.
When to run design QA
Design QA works best as a small, repeated step rather than one big review at the end. When a feature reaches the test environment, the designer or a trained reviewer checks it before it is approved. Issues are cheap to fix at that point because the developer still has the code fresh. A single review the week before launch finds the same issues, but all at once, when there is no time to fix them properly.
Comparing build and design
Open the design and the build side by side at the same width. Do not measure every pixel; look for differences a user would notice. The design system is the reference for anything the design file does not specify: if a button in the build differs from the button component, that is a finding even if the page mock-up is silent.
- Spacing and alignment: consistent gaps, edges that line up
- Typography: sizes, weights, line lengths, no orphaned words in headings
- Colours: tokens used, not hard-coded near-matches
- Components: the right variant of button, input and card
- Content: real text and images, not placeholder copy
- Icons and images: sharp, correctly sized, with alt text where needed
Responsive and device checks
Designs are usually drawn at two or three widths; users arrive at every width in between. Drag the browser from the smallest to the largest size and watch for the breakpoints where things wrap badly. Then test on real devices: at least one small Android phone, one iPhone and a tablet. Browser emulation misses keyboard behaviour, safe areas and real touch targets.
| Check | What to look for |
|---|---|
| Narrow phone | Text overflow, buttons stacking, horizontal scrolling |
| Large phone and tablet | Awkward in-between layouts, stretched images |
| Desktop wide screen | Line lengths too long, content floating in space |
| On-screen keyboard | Inputs hidden behind the keyboard, sticky bars covering fields |
| Zoom to 200 percent | Nothing cut off, no overlapping text |
States and edge cases
Most design drift hides in states the mock-up never showed. A design shows the happy path with perfect data; the build must handle empty lists, long names, slow networks and errors. Walk through each screen and force the states: clear the data, paste a very long company name, turn off the network, submit an invalid form.
Interaction states
Hover, focus, active, disabled and loading for every interactive element. Focus must be visible for keyboard users.
Content states
Empty, one item, many items, very long text, missing image.
System states
Loading, error, offline, success. Each needs a message a person understands.
Accessibility belongs in the same pass: contrast, focus order, labels on form fields, and error messages that say what went wrong and how to fix it. Our guide to designing for WCAG 2.2 lists the criteria that most often fail.
Logging and prioritising issues
A design QA finding needs three things: a screenshot of the build, the expected result (a link to the design frame or component) and a severity. Put findings in the same tracker as bugs so they are prioritised together, not in a separate document nobody opens.
- Blocker: users cannot complete a task, or an accessibility failure
- Major: clearly wrong and visible on a key page
- Minor: noticeable to a careful eye, does not affect use
- Polish: batch these and fix them in a scheduled clean-up
Repeated findings point to a root cause. If the same spacing or button issue appears on every page, the fix is in the component library, not in each page. That is the argument for a design system and UI kit: it makes the right thing the default. When you do not need one: a small marketing site built by one person rarely justifies a full design system — a short style guide and a checklist like this one are enough. Read whether your company needs a design system before investing.
Next step
Take this checklist into your next release and run it on one feature. Count the findings and note which ones repeat. If the repeats point to missing components or unclear handover, a short call can tell you whether the fix is process, a design system or better handover from Figma.
Frequently asked questions
Who should do design QA?
Ideally the designer who made the design, because they know the intent. Without a designer, a developer or product owner can run the checklist, using the design system as reference.
Is design QA the same as testing?
No. Functional testing checks that things work; design QA checks that they look and behave as designed, in every state and size. They overlap on accessibility and error handling.
How long does design QA take?
For a single feature, usually well under an hour when done continuously. A big review at the end takes far longer and finds issues too late to fix properly.
Do we need special tools?
Not really. The design file, the test environment, a few real devices and your bug tracker are enough. Browser extensions for overlaying designs can help but are optional.
Does your build keep drifting from the design?
Fifteen minutes: show us a recent release and we will tell you whether the fix is a routine, a component library or better handover.
Book a free 15-minute call