Design QA

Handing work over went fine; checking what came out of it did not happen at all. The designer let go of a screen the moment the mockup shipped and moved to the next one, the engineer believed they had built what they received, and the release went out as it was.

The trouble is that the gaps are small. A 24-pixel margin comes back as 20, a 14-pixel type size as 13, one gray a shade lighter than specified. On a single screen nobody notices. Stack twenty such screens and the whole product sits slightly off its own design, and by then tracing where the drift started is hard.

Pagedeck went through this. Noa opened the shipped document-sharing screen and said it wasn't what she had handed over; Theo said he had built exactly the mockup. Neither was lying. Noa was looking at margins and type sizes, Theo had matched layout and behavior. Nobody had ever agreed on what counted as matching.

The delivery stage of design deliverables splits into three: write the values down, hand them over, then check the result. Design QA is that last slot, and however well the first two go, leaving this one empty ships margins that are off by four.

The whole activity is opening the mockup and the live screen side by side and reading down. What makes the second round faster is having a fixed order to read in and a fixed way to write findings down.

1. Fix the scope and the environment. Which batch of screens, which browser and screen width, whether dark mode is included. Skip this and Noa reviews on a laptop while Theo checks on an external monitor, and they end up discussing different things.
2. Read in a set order: layout first, then spacing and sizes, then color and type, then states. States means the screen when the list is empty, when a title runs very long, while something is loading, and when a request fails. This is where most findings come from, because normal screens have mockups and those four often don't.
3. Write each gap down as an entry. Not "the button looks off" but "document list screen, margin above the save button should be 24, it's 20," with the location, both values, and a screenshot. Tools like Figma read the specified values straight off the mockup, so nobody has to memorize them.
4. Sort by severity. Three buckets are enough: fix before release, fix this week, look at later. Throw everything in at the same weight and engineering ends up starting with whatever is easiest. A long title cut off mid-word belongs in the first bucket; a one-pixel difference belongs in the last.
5. Re-check after the fix. The person who closes an entry is the person who opened it, not the person who fixed it. Without that rule, entries marked fixed get closed while they are half fixed.

Whatever is left goes into the issue tracker engineering already uses. When the same entry returns round after round, it isn't an individual's mistake — it means the value doesn't exist in the design system, so the thing to fix is the system rather than the screen.

Two people are the baseline: the designer who drew the screen and the engineer who built it, in the same session. The designer rules on what counts as a gap; the engineer answers whether it can be changed and why the value came out that way. Some teams add an accessibility pass as a third lane — whether text and background contrast enough, and whether every button can be reached with the keyboard alone.

Mia joins when the two disagree. The designer wants it fixed, the engineer says it won't fit this release, and the tiebreaker is how visible the item is to users. Left to two people, this call usually goes to whoever argues harder.

Timing is after the feature is complete and running in the development environment, roughly two days before release. Go earlier and you file gaps against parts nobody has built yet; go later and there's no time to fix anything, so the list is all that remains. When there are many screens, review each batch as it completes rather than saving them all. Twenty screens at once produce eighty entries, and a list that long usually never gets opened.

"Let's book design QA before this week's release — just the list screen and the share modal."

A proposal to hold the review session with a deliberately narrow scope.

"Design QA list is up. Only the top three for this release, the rest can wait until next week."

Severity has already been sorted, so not everything needs fixing today.

"That's not a design QA item, that's a new request."

The screen doesn't diverge from the mockup — the ask is to change the mockup itself, which belongs somewhere else.

At Pagedeck, Noa and Theo book 30 minutes the afternoon before a release. One has the mockup open, the other the development environment, and they walk down in the same order. Last quarter those 30 minutes produced twelve entries on average, four of which were fixed before release.

The more visible change is that repeat entries dropped. For the first two months, margin values came up every single round; once those values went into the design system, the same entry all but disappeared. The job of this review is not only to fix the current release but to stop the same gap from forming next time.

The most common reading is that design QA is a designer nitpicking. It looks like a session convened to argue about one pixel, and there's a reason it looks that way: a list containing nothing but value differences reads exactly like that. But most of what actually surfaces here isn't values — it's empty lists, long titles, and error screens, states that never had a mockup. Those aren't matters of taste; they are screens nobody has designed yet. Dismiss the session as nitpicking and users find those screens instead.

The other mistake is treating the session as a place to improve the design. Staring at a screen for half an hour naturally produces ideas, but finding what diverges from the mockup and changing the mockup are different jobs. Revise the design mid-review and engineering no longer knows what is settled, and new work arrives the night before release. Write the idea down and bring it to the next design review.