Igor
Design QA is the check that a build matches the design: spacing, type, colour, states, behaviour at different sizes and the basics of accessibility. It works best as a checklist run against the real build, with feedback that names the element, the value found and the value expected. "The spacing looks off" costs a developer a round of questions. "Gap between the card title and the price is 8px; the design says 16px" can be fixed in a minute.
When to run design QA
Run it when a feature is built and before it is released, on a staging site, and again after the fixes. Do it with the design open next to the page, at the same size. Doing it on a laptop at full width and nowhere else misses the phone, where many problems appear. Decide beforehand how exact the match must be. A tolerance of a pixel or two is reasonable; a different font weight is a defect.
The checklist
Layout and spacing
- Margins and padding match the design's spacing scale.
- Elements align to the same grid and to each other.
- Nothing overlaps or is cut off, including with long text.
- Section order and hierarchy match the design.
Typography
- Font family, size, weight and line height match.
- Headings use the heading styles, not larger body text.
- Long words and long names wrap or truncate as designed.
Colour and imagery
- Colours match the design tokens, not close guesses.
- Images are sharp at their displayed size, including on high-density screens.
- Icons are the right icons, at the right size and weight.
- Corner radius and shadows match.
States
- Hover, focus, active and disabled states exist and match.
- Error, empty and loading states are designed and built, not left as defaults.
- Form validation messages appear in the right place with the right wording.
Responsive behaviour
- Check at the design's breakpoints and between them, for example 375, 768, 1024 and 1440 pixels wide.
- Navigation, tables and images behave as designed on a phone.
- Nothing scrolls sideways unless intended.
Interaction and motion
- Clicks, taps and keyboard actions do what the design says.
- Animations match the specified duration and easing, and are not distracting.
Accessibility basics
- Text contrast meets at least WCAG AA: 4.5 to 1 for body text, 3 to 1 for large text.
- Every interactive element can be reached and used with the keyboard, and shows a visible focus.
- Tap targets are large enough to hit comfortably on a phone.
- Images that carry meaning have alt text.
This is a visual and behavioural check, not a full accessibility audit. If accessibility is a requirement, test with a screen reader and a dedicated tool as well.
How to word the feedback
Good design feedback has four parts:
- Where. The page and the element, named as it appears: "the Add to basket button on the product card".
- What you found. The actual value or behaviour, measured if you can.
- What the design says. The expected value, with a link to the frame in the design file.
- The setting. Browser, screen width and device, because many differences appear at one size only.
Avoid adjectives alone ("too tight", "looks heavy"). They tell the developer there is a gap and not what it is. If you do not have a number, attach a screenshot with the design beside it, and mark the difference.
Three examples
| Weak | Actionable |
|---|---|
| The heading looks too small. | Page heading on /pricing is 28px at 375 wide. The design (frame "Pricing / mobile") has 32px. |
| The button is the wrong colour. | Primary button on the checkout page is #1E40AF. The design uses the token "brand-600" (#2745D3). |
| It breaks on tablet. | At 820px wide the three product cards wrap to two plus one, with the last card left-aligned. The design shows a centred row at this width. |
Marking it up on the page
The quickest way to give this feedback is on the page itself. With SnagRelay, a designer or client clicks Report, points at the element that is wrong and writes what they expected. The report records the element by name, the page address, the browser and the window width, so the setting part of the feedback is filled in for you. They can also mark up a screenshot with a pen, arrows and comments. SnagRelay does not compare the build with your design file; you still say what the design intends. The report goes to Jira, Linear, GitHub, GitLab, Trello or Azure DevOps, or waits in the SnagRelay inbox. See marking up a bug on the page.
FAQ
What is design QA?
A review of a built feature against its design, covering layout, type, colour, states, responsive behaviour and accessibility basics, so that differences are fixed before release.
Who should do design QA?
The designer, ideally, since they know what was intended. A product manager or QA can do it with a checklist and the design open. Developers should check their own work against the design before it reaches review.
How exact should the match be?
Agree a tolerance before you start. A pixel or two of difference is usually acceptable, while wrong fonts, colours from outside the design system and broken layouts at common breakpoints are defects.
What is the difference between design QA and QA testing?
QA testing checks that the software works. Design QA checks that it looks and feels as designed. They overlap at states and responsive behaviour, and many teams run both on the same staging site.