Design QA is the review pass between "the build is done" and "the client sees it". Most teams skip it, not because they think it is useless, but because nobody owns it. The developer believes they built what was designed. The designer assumes the developer will ask if something is unclear. Both are wrong often enough that the client becomes your QA department, which is the most expensive way to find a misaligned button.
This is the checklist we use, ordered by how often each category catches something real.
1. Typography
The most common source of drift, because it fails silently. The site loads, the text is readable, everyone moves on.
- Font weights. Designs often use a weight the web font was never loaded with, and the browser fakes it. Compare a headline side by side and faux bold jumps out.
- Line height and letter spacing on headings. A 1.2 line height in Figma quietly becomes the browser default of 1.5 and every section gets taller.
- Text styles on things nobody restyled: form labels, error messages, cookie banners, 404 pages.
2. Spacing and alignment
Open the design and the live page at the same viewport width and go section by section.
- Vertical rhythm between sections. Padding tends to grow in development because developers add margins defensively.
- Alignment across columns. Cards in a row should share a baseline; their buttons should too, even when one card has two lines of text and the next has three.
- Container widths. A design on a 1440 canvas often ships in a 1280 container, and everything inside compresses a little.
3. Interactive states
Figma shows the resting state. Users spend half their time in the other ones.
- Hover, focus, active, and disabled states on every button and link.
- Form validation: the error state, the success state, and what happens on submit failure.
- Loading states. A button that does nothing for two seconds after a click reads as broken.
4. The content nobody designed for
Designs are made with ideal content. Reality has other plans.
- Long words in short spaces: German compound words, long email addresses, unbroken URLs in user content.
- Empty states. A dashboard with zero items, a search with no results.
- Too much content: a menu with twelve items when the design showed five, a testimonial three paragraphs long.
5. Breakpoints between the breakpoints
Most designs cover mobile and desktop. The bugs live at 900 pixels, where neither layout quite applies. Drag the browser from 320 to full width and watch for the awkward zone: navigation that wraps, hero text that collides with an image, cards that go from three columns to one when two would fit.
6. Images and media
- Compression artifacts on hero images, especially gradients.
- Aspect ratios: CMS content will eventually feed a portrait image into a landscape slot. Check what crops.
- Alt text exists and video does not autoplay with sound.
7. Motion and cross-browser
- Animations respect reduced-motion preferences.
- Safari. Whatever you tested in Chrome, test the same in Safari; backdrop filters, sticky positioning, and form controls are the usual suspects.
How to run the pass without it taking a day
Three rules make this sustainable.
Review on the live site, not screenshots. A screenshot freezes one viewport and hides every state. Annotate the real page, so the note lands on the actual element with its actual context. This is what layernote is built for, so consider the source, but the principle holds with any tool: feedback anchored to the element beats feedback described in an email.
One list, one owner. Every finding goes in a single tracked list with someone responsible for driving it to zero. Findings spread across Slack, email, and a spreadsheet do not get fixed; they get rediscovered.
Let a machine do the diffing. The typography and spacing categories above are mechanical comparisons, and machines are better at them. layernote's design comparison lines up the Figma design against the live page and flags the differences, so your human pass can focus on the categories that need judgment: states, content, and motion.
Run the pass once before the client sees the build and once after the fixes land. The second pass is the one teams skip, and it is the one that catches the fix that broke something else.
If you want to see what your own site looks like next to its design, the trial takes a few minutes to set up. Related: why sites drift from their designs in the first place.