Design-QA the Built Product with Vision Models

Workflow area: Accessibility & Design QA · Tier: Core · Hands-on time: ~30 minutes

Every designer knows the slow leak: the build ships at 90% fidelity, nobody has three hours to compare screens against frames, and the product drifts one "close enough" at a time. Pixel-diffing tools can't help because the build is never a pixel-clone of the frame — real data, real fonts, real viewport. What design QA needs is judgment about which differences matter, applied at a scale no designer has time for. Vision models are good at exactly the first half: enumerate everything that differs. You stay the second half: decide what's a defect, what's an acceptable adaptation, and what's the build being righter than the frame.

When to use — and when not to

• Use it at feature-complete, before releasethe window where discrepancies are cheap to fix and the frame is still fresh enough to be authoritative.
• Use it after design-system migrationstoken and component swaps produce exactly the subtle spacing/type/color drift this pass catches in bulk.
• Use it on responsive breakpoints you never reviewthe model compares the tablet build against the tablet frame you barely remember making.
• Skip screens whose design is still movingQA against a stale frame generates noise and erodes trust in the pass; sync the file first.
• Skip functional QA ambitionsthis pass judges appearance and state presence, not logic, data correctness or performance; don't let a visual pass masquerade as testing.

The recipe

1. 1.

   Pair the artifacts. For each screen in the flow: export the design frame from Figma, and screenshot the built product at the same viewport with realistic data. Capture the states, not just the resting screen — hover, focus, error, empty, loading — because missing states are the most common and most invisible build gap. Name pairs consistently (checkout-01-frame.png / checkout-01-build.png).

2. 2.

   Run the comparison, one pair at a time. Two images, one structured ask:

   Copy

   Image 1 is the design frame. Image 2 is the built product.
   List every visual discrepancy between them.
   
   For each discrepancy report:
   - WHAT: the element and what differs (spacing, size, type, weight,
     color, radius, alignment, missing/extra element, missing state)
   - WHERE: location on screen, precisely enough to find in code
   - EXPECTED vs BUILT: frame value vs. build value, estimated
   - GUESS-SEVERITY: cosmetic / noticeable / breaks-design-intent
   
   Rules: report only what is visible. Do not assume the frame is
   always right — note where the build handles real content better.
   Ignore differences caused by placeholder vs. real data unless the
   layout itself breaks. Number every finding.
   

   Good output looks like this:

   Copy

   1. WHAT: primary button vertical padding smaller in build
      WHERE: "Place order", bottom of summary card
      EXPECTED vs BUILT: ~16px vs ~10px → button height ~44 vs ~38
      GUESS-SEVERITY: noticeable (also a touch-target concern)
   2. WHAT: card shadow missing entirely
      WHERE: order summary card
      GUESS-SEVERITY: breaks-design-intent (cards read as flat panels)
   3. WHAT: build truncates long product names with ellipsis; frame
      shows single-line short name only — build handles this BETTER;
      consider back-porting to the frame.
   

3. 3.

   Triage every finding yourself — this is the design judgment step. Walk the numbered list and assign each a verdict: ticket (real defect, engineering fixes), frame-fix (the build is right; update Figma), accept (intentional adaptation or below the care threshold), or verify (model's estimate needs measuring). For the verify pile, use browser dev tools or Figma Dev Mode to get true values — vision models estimate pixel values and are routinely off by a few px; never put an estimated number in a ticket without checking it.

4. 4.

   Write tickets engineers can act on. Have the model draft them from your triaged list — one ticket per defect with screen, element, expected value (from Dev Mode, not estimation), built value, severity and screenshots attached. Batch cosmetic fixes for the same component into a single ticket; nothing burns goodwill like fourteen one-pixel tickets.

5. 5.

   Track the drift pattern, not just the defects. After a few passes, ask the model to summarize recurring categories across your triaged lists: if shadows are always missing, the token isn't mapped; if spacing is always compressed, engineering is reading redlines wrong or the frame never used auto layout. Recurring drift is a systems bug — fix it in the design system, the handoff spec (pb-12), or the MCP-ready file prep (pb-34), and this QA pass shrinks on its own.

Make it yours

• Playwright for capture at scale: script screenshots of every route at three breakpoints on each release candidate, then batch-compare against exported frames — the capture is automated, the comparison is the model, the triage stays yours.
• Figma Dev Mode as the truth source: resolve every verify finding against Dev Mode's actual values, and paste those values into tickets — the model finds, Dev Mode measures.
• State-matrix mode: feed the model your pb-07 state matrix alongside the build screenshots and ask specifically which enumerated states are missing from the build — the highest-value single question in the whole pass.

Quality check

• Comparisons used same-viewport, real-data capturesmismatched viewports produce a findings list that is 80% viewport.
• Every finding got a human verdicta model list forwarded raw to engineering outsources design judgment to an estimator and burns trust on false positives.
• Numbers in tickets came from Dev Mode or dev toolsestimated pixel values were verified before anyone was asked to fix them.
• The build got credit where it was rightframe-fix verdicts flowed back into Figma; QA that only ever blames the build teaches engineering to ignore it.
• Recurring categories became systemic fixesif the same drift shows up three passes running, the ticket is against the system, not the screen.