How to Catch Design Mismatches Before Release: 5 Checkpoints

What Is a Design Mismatch?

A design mismatch is a place where the shipped UI differs from the approved design in a way the design did not intend. The button works; it is 8px rounded where the frame says 12px. Functional tests and code review let it through because the page loads, the colors are close, and nothing errors. Design QA finds it by comparing the build to the design.

Why Design Mismatches Reach Production

Design mismatches reach production for three reasons: the design changed after the developer last looked at it, the browser renders values differently than the design tool, and nobody compared the build to the frame before release.

• The design moved after handoff: in the UX Tools survey, 80% of designers say changes to designs are missed by developers. A frame edited after the ticket was written produces a build that matches the old frame and misses the new one.
• Figma and the browser disagree: font rendering, sub-pixel rounding and color space mean a value copied correctly from the inspector can still render differently. The six causes are in why your CSS never matches the Figma file.
• The team skipped the comparison: functional QA asks "does it work", code review reads the diff, and both pass a button with the wrong radius. Figma's 2025 designer and developer trends report found that 84% of designers collaborate with developers at least weekly, yet only 67% of developers and 63% of designers rate that collaboration as effective, which leaves a gap where a side-by-side comparison should be.

The cost compounds. The NIST 2002 study of software testing infrastructure puts the relative cost of fixing a defect after release at 30 times the cost at the requirements stage and 6 times the cost during coding (Table 5-1, which NIST labels an example). A mismatch found in the pull request is a one-line CSS change. The same mismatch found by a client is a hotfix, a deploy, and a conversation.

How to Catch Design Mismatches Before Release: Five Checkpoints

Catching design mismatches before release means checking the build against the approved design at five points: handoff, build, pull request, staging, and release. Each checkpoint catches the mismatches that enter at that stage, and each takes five to thirty minutes.

• 1. Handoff: freeze the approved frame, specify states and breakpoints, link the frame in the ticket.
• 2. Build: the developer compares the page against the frame while coding, using tokens instead of typed values.
• 3. Pull request: screenshots at 375, 768 and 1280px in the PR; the reviewer checks them against the frame before reading the code.
• 4. Staging: a design QA pass against the approved frame, at three widths, with every miss filed as an issue.
• 5. Release: a production check for environment-only differences, then a scheduled scan so the next mismatch is caught without a person looking.

1. Handoff: Freeze the Frame and Define Done

The handoff checkpoint prevents the mismatches that no later check can catch: the ones where the design itself was ambiguous. Before a ticket moves to development, the designer and developer agree on three things.

• Which frame is approved: one link to one frame, not a page of explorations. If the frame changes later, the change goes into the ticket as a comment that says what moved.
• Every state and breakpoint: hover, focus, disabled, loading, error and empty, at 375, 768 and 1280px. A state that is not in the frame will not be in the build.
• What done means: "matches the approved frame at three widths, with all states" written into the acceptance criteria, so the developer and the reviewer check the same thing.

For the seven handoff practices that make this routine, see how to improve your design-to-dev handoff.

2. Build: Compare While You Code

The build checkpoint is the cheapest place to catch a mismatch, because the developer is already in the file. Keep the frame open next to the browser and check four things before opening the pull request.

• Tokens, not values: every color, spacing, radius and type value references the design system token. A typed hex is a mismatch waiting for a theme change.
• Computed values against the frame: inspect the element and read the computed padding, font size, line height and radius against the inspector values in the frame. Expect sub-pixel differences; flag whole-pixel ones.
• States exist: hover, focus, disabled and error on every interactive element that changed.
• Component, not lookalike: the design system button, card or input, in the variant the frame uses, rather than a styled div that resembles it.

3. Pull Request: Screenshots at Three Widths

The pull request checkpoint adds a second pair of eyes and a record. The developer attaches screenshots of the changed pages at 375, 768 and 1280px, and the reviewer compares them to the frame before reading the code.

• Review the screenshots first: a reviewer who starts in the diff approves CSS that reads correctly and renders wrong.
• Check the design system element: the three mismatches that survive most code reviews are token substitutions, variant drift and responsive breakage. What to look for is in 3 design system bugs that survive every code review.
• Compare, do not remember: keep the frame open in a tab during review. A reviewer working from memory approves "close enough".

4. Staging: The Design QA Pass

The staging checkpoint is the full comparison: the approved frame next to the staging build, at three widths, with every category of mismatch checked and every miss filed as an issue. A full pass over one page takes 15 to 30 minutes; a focused pass on the components that changed takes about five.

• Use a checklist: typography, color, spacing and layout, alignment, component states, responsive behavior, icons and images, borders and shadows, animation, and content. The 60-check version, with a printable PDF, is the design QA checklist.
• Check accessibility alongside fidelity: text contrast of at least 4.5:1 per WCAG 2.2 success criterion 1.4.3 and pointer targets of at least 24 by 24 CSS pixels per success criterion 2.5.8. A failing contrast ratio is a mismatch against the design system as much as against the standard.
• File, do not list: each miss becomes its own issue with the expected value, so fixes can be assigned, tracked and verified one at a time.
• Run the scanner first: token, contrast, consistency and missing-state checks can run automatically before the human pass, which leaves the person with alignment, animation and whether the copy reads right.

5. Release: Verify Production, Then Keep Scanning

The release checkpoint catches mismatches that only exist in production: a font that loads late and shifts the layout, an environment variable that changes a theme, a CDN that serves a stale stylesheet. Open the released pages at the same three widths and compare them to staging, not to the frame.

• Fonts and layout shift: a web font that loads after first paint changes line lengths and can move content. Google's Cumulative Layout Shift guidance sets 0.1 as the threshold for a good score.
• Production-only differences: feature flags, environment-specific themes, analytics scripts that inject elements, and cookie banners that cover the layout at 375px.
• Schedule the next check: a weekly scan of the released pages, with a baseline and a delta report, catches the mismatch introduced by the next deploy before the next human review.

Who Runs Each Checkpoint

Each checkpoint has one owner: the designer at handoff, the developer during the build, the reviewer in the pull request, the designer or QA engineer on staging, and the release owner in production. When two people share a checkpoint, each assumes the other ran it.

On a team without QA engineers, the designer who made the frame runs staging and the developer who built the page fixes misses in the same sitting. For the roles question in more depth, see who should own design QA.

How to File a Design Mismatch

A design mismatch report needs six things: the page URL, the viewport width, the element, the expected value from the frame, the actual value from the browser, and a screenshot. With those six a developer can fix it without asking a question.

• URL and viewport: "/pricing at 375px", because a mismatch that exists at one width often does not exist at another.
• Element: the CSS selector or a precise description ("the primary button in the Team plan card"), not "the button".
• Expected and actual: "border-radius 12px (frame) vs 8px (build)". Those two values are what the developer fixes; the rest helps them find the element.
• Screenshot: of the element in the build, beside the frame when you can.
• Type and severity: label it a mismatch rather than a bug, so the fix queue separates "does not match" from "does not work". In OverlayQA the issue type picker offers Bug, Mismatch, Improvement and General for this reason, and Visual Comparison stamps its own findings Mismatch.

For the template and the reason behind each field, see bug report template: what developers actually need.

What to Automate at Each Checkpoint

Part of each checkpoint needs a person's judgment. The rest is a comparison a scanner can run on the live page, and running the scan first leaves the person with the judgment calls. OverlayQA runs these scans from the Workflows tab in the Chrome extension, or from Team Review in the dashboard on any public URL with no extension (Components still needs the extension):

Every finding becomes an issue with the selector, computed CSS, screenshot, URL, viewport and browser attached, in the same list as the mismatches a person filed, and syncs two ways with Jira, Linear, Notion, Asana and Trello. What stays manual: whether the frame is the right frame, alignment judgment, animation feel, and whether the copy reads right.

Detect design mismatches, accessibility violations and design token drift on any live page with AI analysis, CSS extraction and accessibility auditing. Every issue carries the selector, computed CSS, screenshot and viewport, and exports to Jira, Linear, Notion, Asana or Trello.

Frequently Asked Questions

What is a design mismatch?

A design mismatch is a difference between the approved design and the shipped UI that the design did not intend: spacing, typography, color, radius, a missing component state, the wrong component variant, a responsive layout that breaks at one width, or content that changed after handoff. The UI still works, which is why functional testing and code review let mismatches through.

How do you catch design mismatches before release?

Check the build against the approved frame at five points: handoff (freeze the frame, specify states and breakpoints), build (tokens and computed values against the frame), pull request (screenshots at 375, 768 and 1280px), staging (a full design QA pass with every miss filed as an issue), and release (a production check, then a weekly scheduled scan). Each checkpoint catches the mismatches that enter at that stage.

Who is responsible for catching design mismatches?

One owner per checkpoint: the designer at handoff, the developer during the build, the code reviewer in the pull request, the designer or QA engineer on staging, and the release owner in production. On small teams the designer who made the frame runs the staging pass and the developer who built the page fixes misses in the same sitting.

What is the difference between a design mismatch and a visual bug?

A visual bug is anything that renders wrong, including things no design specified: overlapping text, a broken image, a layout that collapses. A design mismatch is the subset where a design exists and the build differs from it: the right component in the wrong size, color or state. Visual regression testing catches changes from the last screenshot; design QA catches differences from the design. For which bugs each one catches and misses, see design QA vs visual regression testing.

Can design mismatches be detected automatically?

Partly. A scanner can find token substitutions, inconsistent component instances, missing interactive states, responsive gaps, leftover placeholder content and contrast failures on the live page, and can compare a Figma frame or image against the page and list the differences. Whether the frame is the right frame, alignment judgment and animation feel still need a person.