How to do visual QA on a design
Visual QA means comparing a live implementation against its Figma spec to catch spacing, typography, color, and component-state discrepancies before the client sees the result. Work through the design systematically — side by side, section by section — document each issue with enough context for the developer to act on it, then share the reviewed build for client sign-off. Most teams skip inner pages and component states; those are where drift hides.
Set up the comparison — Figma spec on one side, live build on the other
Open your Figma file at the exact frame you're reviewing, and the deployed staging URL in a browser alongside it. Pin the Figma frame so you're comparing one specific version, not whichever frame is currently in view. Use the same viewport width for both — 1440px for desktop, 390px for mobile. The most common mistake is reviewing by memory: 'that looks about right' is not QA. You need the spec and the build visible at the same time so the eye catches the 4px spacing difference it would otherwise miss.
Work through spacing, typography, and colour — in that order
Spacing first: inspect margins and paddings in DevTools (right-click → Inspect, then check the Computed tab). Gaps that look correct in a screenshot are often off by 4–8px — and a client spots misaligned columns faster than any other issue. Typography next: check font-weight, line-height, and letter-spacing. Developers frequently use `font-weight: 400` where the spec calls for 450 or 500 — subtle in isolation, obvious in comparison. Colour last: use a colour picker (the macOS Digital Colour Meter or the Chrome DevTools eyedropper) to sample the rendered value against the hex in Figma. Brand colours are the most common spec violation.
Check component states — not just the default
Most builds look correct in the default state. Visual QA catches what the default hides: hover states (does the button colour shift?), focus rings for keyboard navigation, disabled inputs, empty states, and error messages. These are the states a client will hit in real use, and they are almost never included in the Figma export the developer referenced. Tap through each interactive element on mobile too — touch targets under 44px are a common Figma-to-code gap that no desktop preview catches.
Document findings with exact context — not just screenshots
A screenshot circle is not a bug report. For each discrepancy, note: the page and section, the element (use the CSS selector or the component name from Figma), the expected value from the spec, and the rendered value from DevTools. 'The hero heading has line-height 1.2 but the spec is 1.1' is actionable. 'The text looks a bit tight' is not. Most visual QA rounds stall because the designer sends screenshots and the developer spends two hours locating the element — specificity is the fastest path to a fixed build.
Review inner pages and breakpoints — not just the hero
The hero almost always looks right. Drift accumulates on inner pages — the About or Pricing page where padding was eyeballed, the mobile breakpoint that was never formally checked against spec. After reviewing at full width, shrink the viewport to 768px and 390px and re-check the layout. The most expensive visual bugs to fix post-launch are the ones nobody looked at: a Contact page in a different font weight, a footer with mismatched spacing, a card grid that breaks at 414px. Systematic beats thorough — go page by page, not impression by impression.
Share the reviewed build for client sign-off — on the actual build, not a deck
Once the developer has addressed the QA findings, the client needs to approve the visual result. Do not email screenshots or export a PDF of the build — the client will annotate the export, not the real thing. Share the staging URL as a reviewable link where they can click the exact element they mean and leave a note pinned to it. Ask three specific questions: Does the visual style match the brief? Is the typography readable at this size on your device? Are there elements that feel off-brand? Specific questions surface real blockers; 'what do you think?' surfaces preferences.
The QA pass is yours to control — but the client sign-off is where rounds multiply. If their visual notes arrive as WhatsApp photos of a laptop screen or a wall of text with no clear location, you spend more time interpreting than fixing. Share the reviewed staging build as a Drafty link. Your client clicks the exact section — the hero, the pricing table, the mobile nav — and pins a note right there, without an account or extension. Every comment is anchored to the spot they meant, you see the thread in one place, and when the fix lands you push an update on the same link.
Open a live demoQuestions
- What does visual QA actually check?
- Visual QA compares a live build against its design spec — spacing, typography, colour values, component states, and responsive layout at each breakpoint. It is not functional testing (does it work?) or regression testing (did something break?). It is specifically about visual fidelity: does what was built match what was designed?
- Who is responsible for visual QA — the designer or the developer?
- Both. The developer should self-review implementations against the Figma spec before handing off to the designer. The designer then does the formal QA pass with the spec open beside the build. Treating it as the designer's job alone means the developer gets no feedback loop; treating it as the developer's job alone means visual fidelity rarely gets the attention it needs.
- How is visual QA different from a website QA review?
- A website QA review covers functional correctness — links, forms, mobile rendering, browser compatibility, content accuracy. Visual QA is specifically about whether the build matches the design spec: spacing, typography, colour, and component states. Both are necessary; visual QA typically happens first, because a broken layout makes functional testing ambiguous.
- How long does a visual QA pass take?
- For a five-to-eight-page site with one breakpoint, a thorough visual QA pass takes three to five hours done systematically. Double that for a responsive design reviewed at three breakpoints. Budget it as a deliverable, not an afterthought — catching a spacing inconsistency in QA takes ten minutes to fix; catching it after the client's first impression takes an email thread.
- What tools do designers use for visual QA?
- Side-by-side comparison of Figma and the live build is the baseline. Chrome DevTools (Inspect → Computed) gives exact spacing and colour values. The macOS Digital Colour Meter or the Chrome DevTools eyedropper samples rendered colours against the spec. For communicating findings, tools that let you pin a comment to an exact element on the live page — rather than circling a screenshot — cut the back-and-forth significantly.
- What do designers most commonly miss in visual QA?
- In order: inner pages with drifted spacing (the hero was perfected; the About page was eyeballed), component hover and focus states (developers reference the default Figma frame), typography at small sizes (line-height differences vanish at display scale but are obvious at body copy scale), and mobile breakpoints that were never checked against a spec frame. The 94% statistic — users form opinions about a site in 50 milliseconds — makes these worth the time.
Keep exploring
Stop emailing files back and forth.
Share one link. They comment on the exact spot — no account, always the current version.