Design QA: Owning the Gap Between the Figma and What Actually Shipped

Design QA means verifying a shipped screen against the original design intent, not just against the ticket's acceptance criteria — checking spacing, state coverage, motion, empty and error handling, responsive breakpoints, and real content before calling a feature done. It's where "passed tests" and "matches the design" stop meaning the same thing.

Quick answer: Design QA is a dedicated pass — run by the PM, designer, or both — that checks a shipped build against design intent across six dimensions: spacing/layout, interactive states, motion, empty/error edge cases, responsive breakpoints, and real (not lorem ipsum) content. It happens after "acceptance criteria met" and before "done."

Why "It Passed Tests" Isn't the Same as "It Matches the Design"

A ticket can satisfy every acceptance criterion and still ship a screen that looks wrong. QA verifies behavior — does the button submit the form, does the API call fire, does the error toast appear. It rarely verifies fidelity — does the toast look like the one in Figma, does it sit 16px from the edge instead of 24px, does it animate in or just snap.

That gap exists because engineering acceptance criteria are usually written as functional statements ("user can submit form," "error displays on invalid input"), and functional statements are satisfiable by an infinite number of visually different implementations. The ticket doesn't encode intent about how it should feel — only that it should work.

For a design-led PM — the role this site's complete guide to the design-led PM's expanded remit covers in full — this is the actual shift in what "quality" means:

• Ticket-based quality asks: does this do what the acceptance criteria say?
• Design-QA quality asks: does this look and feel like what we approved, at the moments a real user will actually experience it — mid-scroll, on a slow connection, with a name that's 40 characters long?

Both are real quality bars. But only one of them is usually gated before ship. Nielsen Norman Group's research on usability heuristics has long argued that consistency and adherence to platform conventions reduce cognitive load measurably — a design that drifts from its own system reintroduces exactly the friction the design process was meant to remove. A screen that's functionally correct but visually inconsistent still costs the user something, even though no ticket captured that cost.

The Three Places the Gap Opens

The Figma-to-build gap isn't one failure mode — it's three, and they need different fixes:

1. Translation loss. The engineer interprets a static frame without the states, motion, or edge cases the designer had in their head but didn't document. Nobody is at fault; the artifact was incomplete.
2. Scope trims under deadline pressure. The engineer (or the PM, silently) drops a hover state, a loading skeleton, or a breakpoint to hit a date, intending to "come back to it."
3. Design drift after handoff. The design changes late, or a downstream component gets reused in a context nobody designed for, and nobody re-checks the new combination.

Design QA doesn't prevent all three. It's the backstop that catches them before a customer does, which is the entire reason it earns a place in the release process rather than living as an informal "does this look right?" glance.

The Design QA Checklist: What to Actually Check

A design QA pass is fast when it's structured and endless when it isn't — the checklist exists to bound the review to what actually predicts a bad shipped experience, rather than an open-ended aesthetic argument. Run it screen by screen, against the live build, not a staging screenshot.

Spacing, Alignment, and Visual Rhythm

Spacing drift is the most common and most invisible gap, because a 4px difference doesn't fail a test but does register — even subconsciously — as "something's slightly off."

• Check padding/margin against the design system's spacing scale (commonly a 4px or 8px base unit), not just "close enough."
• Check alignment of text baselines, icon centers, and button groups — misalignment compounds across a screen faster than any single instance suggests.
• Check that reused components render identically wherever they appear; a card component styled once in Figma but implemented twice in code is a common drift source.

Interactive States

A static Figma frame typically shows one state. A shipped component has at minimum five, and most fidelity bugs live in the four nobody screenshotted:

Walk every interactive element through all six states with keyboard navigation (Tab, Enter, Space), not just a mouse — focus states are the ones a mouse-only review will never catch, and they're a real WCAG 2.2 requirement, not a nice-to-have.

Motion and Micro-interactions

Motion is the hardest thing to spec in a static tool and the easiest thing to drop under time pressure — it's also disproportionately what makes an interface feel "premium" versus "cheap," per the aesthetic-usability effect Nielsen Norman Group has documented.

• Does it animate at all, or does it snap? A modal that should fade/scale in but instead pops instantly reads as broken even though it's functionally identical.
• Is timing in the right range? Google's RAIL performance model treats 100ms as the threshold for an interaction to feel instantaneous and roughly a 16ms frame budget (60fps) as the bar for animation to read as smooth rather than janky — a 400–500ms transition on something meant to feel snappy will read as sluggish even if nothing is technically slow.
• Does it respect prefers-reduced-motion? A common accessibility miss that's invisible unless someone tests with the OS setting on.
• Does easing match? A linear ease where the design specified ease-out reads as mechanical even at identical duration — this is a real, perceptible difference, not PM pedantry.

The Doherty Threshold — IBM research from the early 1980s showing user engagement rises sharply when a system responds within about 400ms — is a useful backstop when a fidelity conversation turns into "does this actually matter." Motion past that threshold isn't a taste disagreement; it's a measurable regression.

Empty, Error, and Edge States

Design files disproportionately show the "happy path" screen: populated, successful, ideal-length content. Real usage spends meaningful time in the states that never made it into the Figma file.

• Empty state: first-run, zero-results, and post-deletion empty states are often three different screens conflated into one generic "nothing here" message.
• Error state: network failure, validation failure, and permission failure typically need different copy and different recovery actions — a single generic error toast collapses distinctions a user needs.
• Partial/degraded state: what does the screen look like when three of five API calls succeed? This state almost never exists in Figma and almost always exists in production.

This is the point at which understanding the underlying customer job pays off — a screen designed around the job the user is actually trying to get done, in the framing laid out in a proper Jobs-to-be-Done breakdown, makes it much easier to tell which edge states are load-bearing for that job and which are cosmetic.

Responsive Breakpoints

A design approved on a 1440px desktop mock and never checked at 768px or 375px isn't really "approved" — it's approved for one viewport out of the several a real user will actually load it in.

1. Check the primary content breakpoints the design system defines (commonly mobile, tablet, and desktop tiers).
2. Check the awkward in-between widths — a browser window at 900px, a tablet in landscape — where layouts often break in ways neither the mobile nor desktop mock anticipated.
3. Check touch target sizing on mobile — WCAG 2.2's target-size guidance calls for a minimum of roughly 24×24 CSS pixels for AA conformance, and interactive elements that were fine as a mouse target routinely fail that bar once rendered for touch.
4. Check text reflow — does a two-line heading at desktop become a five-line heading at mobile that pushes the primary action below the fold?

Real Content, Not Lorem Ipsum

This is the single highest-leverage item on the checklist and the one most often skipped, because it requires content the design file was never built with.

• Test with the longest realistic string in every text field — a real customer name, a real long email address, a real 12-word article title, not "Lorem ipsum dolor."
• Test with zero, one, and many — an empty list, a single-item list, and a 200-item list frequently render as three different layouts, only one of which was designed.
• Test with real numbers — currency formatting, large numbers with separators, negative values, and percentages all break differently than a rounded placeholder does.
• Test with actual user-generated content, including the messy version: emoji, line breaks, right-to-left text if the product supports it, profanity filters if relevant.

This checklist item alone tends to surface more shipped-but-wrong bugs than the other five combined, because "design for real content" is a discipline that has to be practiced deliberately — it doesn't happen by default in a tool where every string is typed once and never stress-tested.

Who Runs Design QA: PM, Designer, or Both

The honest answer is that ownership shifts by context, and pretending there's one correct owner is how design QA quietly falls off both people's plates. The dividing line that actually works in practice is who has the design system in their head versus who has the acceptance criteria in their head — those are different kinds of knowledge, and each catches different bugs.

A few operating principles hold across all of these:

• The designer owns fidelity to intent. They're the only one who can tell you whether a deviation is "close enough" or "actually a different thing." Nobody else should make that call unilaterally.
• The PM owns coverage and prioritization. Whether every state got checked, whether the gap is worth blocking release over, and whether the fix happens now or next sprint is a PM call, informed by the designer's fidelity judgment.
• QA/engineering own regression. Once a fidelity bar is set, keeping it from drifting again on the next change is a testing discipline (visual regression tooling, snapshot tests), not a manual review that has to happen forever.

The pattern that consistently fails is nobody owning it explicitly — every ticket assumes "someone" will check fidelity, and the check happens only when a designer happens to notice after launch, which is the most expensive time to catch it.

Negotiating Fidelity Fixes Against Velocity

Every fidelity gap you find creates a negotiation, and running that negotiation badly is how a design-led PM earns the "pixel police" reputation that makes engineering start avoiding you. The fix is to make the negotiation explicit and criteria-based instead of a one-off argument each time.

Triage by Real Cost, Not by How Much It Bothers You

Not every gap deserves the same response. A useful triage splits fixes into three tiers based on what the gap actually costs, not how visible it is to the person who noticed it:

The discipline is naming the tier out loud, in the ticket, rather than letting every fidelity note default to "well it should just match the design." That single habit is most of what separates a design-led PM who's respected from one who's tolerated.

Frame the Ask Around User Cost, Not Aesthetic Preference

The fastest way to lose a fidelity negotiation is to argue from taste. The fastest way to win one worth winning is to argue from what the gap costs a real user in a real moment — which is where a well-built customer journey map earns its keep, showing whether the broken screen sits at a high-stakes point in the journey or a backwater nobody lingers on.

1. Name the specific user cost. "Users on mobile checkout will see the CTA below the fold" beats "this doesn't match Figma."
2. Quantify exposure where you can. A gap on the account-settings page nobody visits monthly is a different conversation than one on the primary conversion flow.
3. Offer the tiered alternative, not just yes/no. "Ship-block the focus state, fast-follow the spacing" gives engineering a real choice instead of a binary fight.
4. Timebox the fix. An open-ended "please make it match" invites scope creep in the other direction; a bounded fix ("adjust padding on these three elements, nothing else") is easy to say yes to.

This is also where the gap between a hunch and a defensible call matters — a useful check is asking whether a fidelity concern would survive being written down as a testable claim, a distinction covered in more depth in how design intuition and data actually combine in practice.

Don't Let "Velocity" Become the Default Winner

Velocity has a natural home-field advantage in these conversations, because the cost of shipping the gap is deferred and diffuse while the cost of fixing it is immediate and visible on a burndown chart. Counter that asymmetry structurally rather than by re-litigating it every time:

• Pre-agree on ship-blocking criteria with engineering leadership before the pressure moment, not during it — see the tier table above as a starting template.
• Track fast-follow debt visibly. A fidelity gap that's "fixed next sprint" and never revisited is a broken promise, and it trains everyone to stop trusting the tier system.
• Bring the fix estimate, not just the ask. A PM who says "this is a two-line CSS change" (and is right) gets a very different reception than one who just flags the gap and walks away.

Where This Breaks Down at Scale: Systems, Not Screens

A single screen's fidelity gap is a bug. The same gap repeating across twelve screens because they share one drifted component is a systems problem, needing a systems response rather than twelve tickets — the kind of reasoning laid out in a systems-thinking approach to product work changes what you actually fix.

• If a spacing gap traces back to a shared component, fixing it once at the component level (and adding a visual regression test) is worth more than fixing twelve instances of its symptom.
• If a motion gap traces back to a missing animation token in the design system, the fix belongs in the token, not in each screen that consumes it.
• If a fidelity gap keeps recurring at handoff specifically — not after — the actual defect is in the handoff artifact, not in any individual build.

Design QA findings are also a useful, honest input for stakeholder-facing moments — a screen that looks unfinished undercuts a demo's credibility regardless of how well the underlying feature works, which is one more reason the discipline behind narrative-driven product demos treats visual polish as part of the story, not a separate concern from it.

Making "Matches the Design" an Explicit Acceptance Criterion

The recurring failure across everything above is structural: fidelity almost never appears as a written acceptance criterion, so it competes for attention against criteria that are written down, and unwritten criteria lose that competition by default. The fix isn't more vigilance — it's moving the check earlier, into the artifact that defines "done" in the first place.

This is the specific gap Prodinja's Spec Studio is built to close. Spec Studio treats the spec as a living document with PR-style diffs and readiness gates, rather than a document written once and forgotten — which gives a design-led PM a real place to attach experience-intent notes: spacing expectations, required states, motion behavior, edge-case coverage, tied directly to the spec.

From there, a readiness gate can require that "matches the design" clear before the item moves to done. That turns the checklist above from something a PM has to remember to run into something the spec itself asks for, at the same review layer as every other acceptance criterion — not a value judgment applied informally after the fact.

Key Takeaways

• Passing tests and matching design intent are different quality bars — acceptance criteria verify behavior, design QA verifies fidelity, and only one is usually gated before ship by default.
• Run the checklist in six dimensions: spacing/alignment, interactive states (especially focus and loading), motion and timing, empty/error/edge states, responsive breakpoints, and real (not placeholder) content.
• Ownership shifts by context — designers own fidelity-to-intent judgment, PMs own coverage and prioritization, and engineering/QA own keeping a fixed bar from drifting again.
• Triage fidelity gaps into ship-blocking, fast-follow, and won't-fix tiers explicitly, in the ticket, instead of treating every gap as either urgent or ignorable.
• Argue from user cost and journey stage, not aesthetic preference — a gap on a high-emotion, high-traffic screen is a different conversation than the same gap on a rarely-visited settings page.
• Recurring gaps are usually a systems problem — a shared component or missing design token, not twelve unrelated screens that each need their own fix.
• The durable fix is structural: make "matches the design" a written, gated acceptance criterion on the spec itself, not a hope that someone remembers to check.