Hire Software Developers 7
Back to blogs

Design QA: Who Checks the Build Against the Design?

November 9, 2026
Design mock beside the shipped screen with a missing error state, the kind of gap design QA catches

Design QA: Who Checks the Build Against the Design?

When the shipped screen doesn't match the design, which one changes? In a survey of UX practitioners at US software organisations, published at CHI 2023, 59% of respondents said that once the two diverged, design changes were needed to bring the work closer to the implementation [R1, R4]. Only 10% gave developers feedback to bring the build back in line [R4].

The study's authors read that as the implementation becoming the "source of truth" [R4]. Nobody decided that. It happened because nobody owned design QA: the check that the build matches the design. Without an owner, the build becomes the design by default.

Design QA is an owned check, before release, that a built screen matches the design's intent across its states, breakpoints, modes and copy. HubSpot describes it as "the final, more rigorous check" after design review [R11].

Disclosure: yousource publishes this and sells UX On Demand and QA On Demand.

Key takeaways

  • In a CHI 2023 survey of US UX practitioners, 83% of respondents said builds diverge from the design at least sometimes [R3].
  • When build and design diverged, 59% said the design had to change toward the implementation. Only 10% gave developers feedback [R4].
  • In an ICSE 2018 study, developers asked to spot design violations caught about half of them [R6].
  • Visual regression tools compare a build with an earlier baseline, not with the design. Playwright writes the first baseline from the first run [R13].
  • GitLab makes the check owned: a ~UX label on every merge request with user-facing changes, and a recommended product-designer reviewer [R8].

What is design QA?

Design QA is the final check before release that the built screen matches the design's intent. It isn't design review. At HubSpot, Kizi Arezi writes, design review happens at intervals while the design is being made, and "Design QA is the final, more rigorous check" [R11]. In HubSpot's version, the engineer puts up a staging build and moves the issue to a Design QA board [R11]. The designer then works through an eight-item checklist that covers edge cases, error states, localization, screen sizes, browsers, phone sizes and accessibility [R11]. Eleken, a design agency, draws the line from the other side. QA "ensures the build matches the design," while usability testing checks whether the design works for people [R26].

It is not pixel-policing. The Go Make Things blog argues that "pixel perfect is not the goal", because exact fidelity across today's viewports is out of reach ("Mobile destroyed that.") and developers have a duty to push back on bad designs [R23]. Fair. But look at what actually goes wrong. In an ICSE 2018 study at Huawei, researchers found 82 design violations across 71 mock-up and implementation screen pairs. About 40% were layout, about 36% were resources (missing or extra components, colour, images) and about 24% were text [R5].

That's one mobile dataset from 2018, not an industry average. The shape still matters: the defects are structure and content, the kind a states-and-breakpoints checklist exists to catch.

The build wins by default

Divergence is common. In Feng, Li and Zhang's survey, 57% of practitioners sometimes encountered design-development divergence and 26% encountered it almost all of the time, so 83% see it at least sometimes [R3].

Practitioners say they care. 86% of those who answered (87 people) said it is very important that the developer's implementation closely match the look and feel of their designs, and only 13% treated their designs as recommended guidelines [R2].

Then look at what they do when the build drifts. 59% said design changes were needed to move the work closer to the implementation. 41% caught up with the implementation by editing or redoing their designs. 10% gave developers feedback to align with the design [R4]. One participant summed it up: "the real world challenge starts when it comes to implementation" [R1].

The survey ran in 2022 and was published as a peer-reviewed CHI 2023 paper. It is US-only, with 114 respondents, and not everyone answered every question [R1]. Small, but the pattern is hard to miss. My read: editing a frame is easier than reopening a merged ticket, so the design file gives way. Each time it does, the build becomes the design and nobody signs off on the trade.

HubSpot's post calls the result design debt and quotes Jess Eddy: "doing Design QA is a big step towards combating design debt" [R12].

Not every gap is a defect, though. At yousource we ship design work incrementally, so a released screen almost never matches the final mock-up. It matches the increment. Every release has to be shippable quality, and the end state only arrives when the project does. Along the way, feedback often changes what that end state should be.

So the useful question for design QA isn't "does this match the final design?" It's "does this increment match what we agreed for it, at shippable quality?" Then: "has the design file caught up with what feedback changed?" Changing the design to match the build can be the right call. The debt starts when nobody made the call.

Why nobody owns the check

By the time a feature ships, the designer may already be on the next flow. The developer built it and is the last person to have looked at it. QA has a test plan. Each of them can reasonably assume someone else compared the build to the design.

"The dev will catch it" doesn't hold up. In the same ICSE 2018 paper, 10 Android developers asked to detect design violations averaged about 50% recall and under 60% precision [R6]. They missed about half. The authors call manual checking "the time-consuming and laborious task of design teams" [R7].

QA doesn't fill the gap by default either. A functional test asks whether the error fires. It doesn't ask whether the error reads and looks the way the designer specified, unless someone wrote that into the test.

Collaboration alone hasn't closed it. In Figma's 2025 designer and developer report, 84% of designers say they collaborate with developers at least weekly [R18]. The top challenge developers cite when working with designers is still "differences in assumptions", at 52% [R18]. Figma doesn't state the sample size on the page.

The strongest counter-argument is that the design handoff itself is the problem. Andreas Møller, CEO of Nordcraft, says "we can't optimize the handoff — we have to eliminate it entirely" [R24]. Builder.io's Mike Chirokas makes the same case [R25]. Both sell tools built on that idea. Figma is moving the same way: its Dev Mode MCP server gives "developers a way to pull live design context into their editor" [R19], and at Config 2026 it announced code layers that turn a design layer into an interactive code layer [R20].

Fewer handoffs are good. They don't remove the loading state, the error state or the 375px breakpoint. Someone still has to look at those against intent before customers do.

Visual regression testing catches change, not the wrong design

Visual regression testing compares this build against an earlier baseline. It doesn't compare the build against the design.

Playwright's toHaveScreenshot shows why that matters. On a first run with no baseline, it writes the actual screenshot as the baseline once two consecutive screenshots match [R13]. If the first build was wrong, the wrong build is now the reference.

Then there's noise. Playwright's own docs warn that "Browser rendering can vary based on the host OS, version, settings, hardware, power source (battery vs. power adapter), headless mode, and other factors" [R14]. By default, maxDiffPixels is unset [R14]. A 2026 peer-reviewed study of 262 cases of web visual flakiness found visual changes more prone to flakiness than non-visual ones [R17].

The hosted tools work on the noise. Chromatic's SteadySnap "freezes dynamic content, and uses burst capture" [R15]. They still hand the judgement to a person. Chromatic renders snapshots "in cloud browsers and pixel-diffs the snapshots" to "Pinpoint changes in appearance, layout, fonts, and colors" [R15]. Tests it marks unstable "won't block your build" [R15]. In Percy, a reviewer approves snapshots or can "request changes" [R16]. With source-code integration, only approving the complete build marks the Percy check as passed [R16].

So the approver is the design QA. If that person doesn't know what the screen was meant to look like, the tool is recording drift, not catching it.

What owned design QA looks like: GitLab's ~UX label

GitLab publishes its process. Its contributing guide says to "Attach the ~UX label to any merge request that has any user facing changes" and to "Include Before and After screenshots (or videos) of your changes in the description" [R8]. It recommends "assigning the Product Designer suggested by the Reviewer Roulette as reviewer" [R8].

Look at what that buys. The rule is simple: user-facing change, add the label. That gives every UI change a review path. The recommended reviewer is a product designer suggested by Reviewer Roulette, not whoever has a spare hour. And the before-and-after screenshots let them review without checking out the branch.

HubSpot's version sits later in the cycle: a staging build, a Design QA board, the designer's checklist, and a final design QA on the live site [R11]. Either works. What they share is that the check has an owner and a place in the workflow.

The design QA checklist

Adapted from GitLab's UI-change checklist [R9] and HubSpot's [R11]. Run it against staging, with the design file open next to it.

  1. States. Error, rest, loading, focus, hover, selected, disabled [R9].
  2. Data size. GitLab says "Account for states dependent on data size" [R9]. Try no records, one record and enough to break the layout.
  3. Breakpoints. "Provide the same information and actions in all breakpoints" [R9]. Check screen sizes, phone sizes and browsers [R11].
  4. Accessibility. GitLab's list includes WCAG 2.1 AA [R9].
  5. Dark mode [R9].
  6. UI copy. GitLab follows its Pajamas guidelines for UI text, and Technical Writers review it [R9]. Include localization [R11].
  7. Edge cases and error states [R11].
  8. Evidence. Before and after screenshots in the merge request [R8].
  9. The agreed increment. Check against what this release was meant to deliver, not the end-state mock-up. If feedback changed the plan, update the design file in the same cycle.

Who owns design QA in a 10–80-person team

Split it by what each person can judge. The designer reviews intent: states, copy, and whether the screen does what the design meant it to. QA checks the build across browsers, devices and viewports, and runs the release smoke test. Don't make the developer the only check: in the ICSE study, developers reviewing screens with known violations caught about half of them [R6].

At 10 to 80 people you may not have a designer with time for this, or a QA engineer at all. If you're deciding which gap to fill first, Dev, UX, or QA: which role to hire first covers picking by the gap that costs most [P14].

yousource doesn't sell a service called design QA, and neither of our pages uses the term [P7, P12]. The closest cards: UX On Demand lists Usability ("Audit the checkout"), Polish ("Tighten the dashboard") and a "Dev-ready handoff" with "Specs and tokens your engineers can build from." [P2, P7]. QA On Demand lists "Cross-browser & responsive" ("Verified across the browsers, devices, and viewports your users are on."), "Release validation & smoke" and "UAT support" [P9, P10].

Both run at $3,495/mo for a single stream or $6,795/mo for dual, with a "3-day turnaround per task, daily async updates" [P3, P4, P11]. The single stream adds a "Task-by-task approval gate" [P5, P11]. "Start with one real task — judge the designer before you subscribe." [P6] Same for QA: "Start with one real task — judge the QA engineer before you subscribe." [P12] If you'd rather have one seat that moves between design, QA and development as the product changes, see one seat, three disciplines [P13].

Start this week: pick the last feature you shipped. Open the design file next to production and check the error state at a phone breakpoint. If nobody can say whose job that was, you've found the gap.

Frequently asked questions

What's the difference between design review and design QA?

Design review happens at intervals while the design is being made. Design QA is "the final, more rigorous check": the designer checks the built screen on staging against a checklist before release [R11].

Is visual regression testing the same as design QA?

No. Visual regression tools compare a build against an earlier baseline, not against the design. Playwright writes the first baseline from whatever the first run renders [R13]. In tools such as Percy, a person still approves or requests changes [R16].

Who should do design QA?

A designer should review intent, triggered by a rule rather than memory, as GitLab does with its ~UX label and a recommended product-designer reviewer [R8]. Don't make the developer the only check: in one study, developers caught about half of design violations [R6].

Does design QA mean pixel-perfect?

No. Exact pixel fidelity across today's viewports isn't realistic [R23], and if you ship incrementally, each release should match its agreed increment at shippable quality, not the final mock-up. A design QA checklist such as GitLab's covers states, data sizes, breakpoints, WCAG 2.1 AA, dark mode and UI text [R9].

Sources

UX On Demand
back to top
Book 15 min with Albert
Smiling man with short dark hair and glasses wearing a black suit, white shirt, and black tie against blue background.
Tell Albert what you're shipping.
He'll read this before joining the call. Phone number comes next, on the calendar step.
↳ info@you-source.com
↳ 4-hour response
Please wait while we retrieve meeting schedules.
Oops! There's a problem with your request. We're working on fixing it. Please try again later.