Design QA: Verifying Implementation Against Figma Specs

BEGINNER

Run a systematic design QA process to verify that implemented components match Figma specifications — layout checks, typography validation, color token verification, and interactive state testing.

90 min

Tutorial 4 of 22

Learning Objectives

Create a design QA checklist covering layout, typography, color, spacing, states, and accessibility for any component
Use browser DevTools alongside a Figma design file to compare CSS values against design specifications
Identify the most common implementation deviations — incorrect rem conversions, missing hover states, wrong font weights
Document QA findings with screenshots and precise measurement differences in an actionable format for developer correction
Establish a QA gate in the sprint workflow that prevents design review from becoming a last-minute bottleneck

Introduction

Design QA is the systematic verification that the implemented UI matches the design specifications. Without QA, small deviations accumulate — a 2px margin difference here, a missing hover state there, an incorrect font weight — until the product looks noticeably different from the design.

As a developer, understanding how designers conduct QA helps you anticipate what they will find and fix common deviations before submitting work for review. As a designer doing QA, structured checklists make the process consistent, fast, and unambiguous.

This lesson covers a complete design QA methodology: the checklist, the tools, the common issues, and the documentation format that makes corrections actionable.

The Design QA Checklist: Six Dimensions of Fidelity

Design QA covers six dimensions of fidelity. A complete checklist verifies all six for every component before marking it accepted.

Layout and Structure:

Element dimensions match spec (±1px tolerance for sub-pixel rendering)
Spacing between elements matches gap/padding spec
Element alignment matches design (text left-aligned, icons centered)
Grid column count and gutter width match at each breakpoint
Nested hierarchy mirrors Figma layer structure

Typography:

Font family loads correctly (verify in DevTools Network tab)
Font size correct (DevTools Computed → font-size in rem)
Font weight correct (numeric: 600 not 'bold')
Line height correct (unitless ratio × font-size = correct px height)
Letter spacing correct (em value × font-size = specified px)
Text color matches Figma hex

Color and Opacity:

Background color matches Figma Inspect hex
Text color matches Figma token
Border color matches
Overlay/backdrop opacity matches
Gradient stops and direction match

Interactive States:

Hover: color, shadow, transform — all present
Focus-visible: ring visible with correct color and offset
Active: correct press effect
Disabled: correct muted appearance + cursor: not-allowed
Loading: spinner visible, label hidden
Error: red border and message

Spacing and Rhythm:

Internal padding matches Auto Layout padding in Figma
Gap between children matches Figma gap
Section padding at each breakpoint

Responsiveness:

Breakpoints trigger at correct viewport widths
Columns stack correctly
Typography scales with clamp()
No horizontal scroll
Touch targets ≥ 44px at mobile

Quick self-QA before PR submission:

Text

1[ ] Hover state works on all interactive elements
2[ ] Tab through page — focus ring visible every time
3[ ] No horizontal scroll at 375px, 768px, 1440px
4[ ] Font-weight numbers match (not 'bold' keywords)
5[ ] Color hex values match Figma Inspect
6[ ] Spacing differences < 4px everywhere

QA Tools: DevTools Alongside Figma

The most efficient QA workflow uses Figma Dev Mode on one monitor and browser DevTools on the other, comparing values directly.

DevTools setup for QA:

Right-click any element → Inspect
Select element in HTML panel
Switch to Computed panel — shows final calculated values
Search for specific properties (font-size, line-height, color)

Checking layout dimensions:

Hover element in DevTools HTML panel → browser shows blue/green/orange overlay
Blue = content, Green = padding, Orange = margin
Numbers in overlay match CSS values
Compare to Figma measurements (Alt+hover for spacing)

Simulating hover states in DevTools:

Right-click element → Force State → :hover
Also available: :focus, :active, :visited, :focus-visible
Use this to QA all interactive states without actual mouse interaction

Common QA findings and frequency:

Text

1Finding                            Frequency  DevTools location
2Incorrect font-weight (400 vs 600) High       Computed → font-weight
3Missing hover state                High       Force :hover → check styles
4Spacing off by 4-8px              High       Element box model overlay
5Incorrect border-radius            Medium     Computed → border-radius
6Missing focus ring                 Medium     Tab navigation
7Wrong color (one shade)           Medium     Computed → color
8Missing transition on hover        Low        Watch for instant color change

PixelParallel extension (Chrome/Firefox):

Export Figma artboard as PNG at 1x
Upload to PixelParallel overlay
Adjust opacity to see design over implementation
Toggle on/off to spot deviations

Figma Dev Mode reference:

Open Figma share link → Ctrl+Shift+D
Click any element → copy exact CSS from Code tab
Compare line-by-line with DevTools Computed

Documenting QA Findings for Actionable Fixes

QA findings must be precise enough that the developer can fix them without follow-up questions. Vague findings ('the button looks wrong') waste time. Precise findings ('font-weight is 400, spec is 600') get fixed immediately.

QA finding format:

Text

1Component: [name]
2Location: [URL + element description]
3Issue: [what is wrong]
4Spec: [what Figma specifies, with exact value]
5Actual: [what browser DevTools shows]
6Priority: Critical / High / Low
7Fix: [exact CSS to apply]

Example QA finding:

Text

1Component: Course Card
2Location: staging.devbootstrap.com/courses — first card title
3Issue: Title font-weight incorrect
4Spec: font-weight: 600 (Figma: font-weight: 600)
5Actual: font-weight: 400 (DevTools Computed)
6Priority: High — breaks visual hierarchy
7Fix: .course-card__title { font-weight: 600; }

Severity levels:

Text

1Critical: accessibility failure (no focus ring, color contrast fail)
2          wrong brand color, completely missing interactive state
3High:     wrong font-weight, incorrect spacing > 8px,
4          wrong component state color
5Low:      ±1-4px spacing, minor color shade difference,
6          sub-pixel border-radius difference

Sharing QA findings:

GitHub Issues: one issue per finding, label 'design-qa', assign to developer
Linear: tasks with screenshot attachments
Figma comments: pin to specific element with exact CSS fix
Confluence: consolidated QA page per sprint

QA passing criteria:

Zero Critical findings (accessibility failures block release)
Zero High findings (visual regressions block release)
Low findings: developer discretion (sub-pixel rendering is acceptable)

QA in the Sprint Workflow: Preventing Bottlenecks

Positioning QA correctly in the sprint workflow prevents last-minute crunch and ensures quality without blocking velocity.

Recommended QA timing in a 2-week sprint:

Text

1Day 1-2: Design freeze
2  Designer: confirms artboards are final, no further changes
3  Developer: reads specs, asks all clarifying questions
4
5Day 3-9: Implementation
6  Developer: implements and runs self-QA checklist daily
7  Developer: fixes all Critical/High deviations before branching off
8
9Day 10-11: Feature branch QA
10  Developer: full self-QA against 6-dimension checklist
11  Developer: submits PR only after self-QA passes
12
13Day 12-13: Designer QA on staging
14  Designer: 30-60 min QA session against staging URL
15  Designer: files GitHub Issues for all findings
16  Developer: fixes Critical+High same day
17
18Day 14: Sign-off
19  Designer: confirms fixes
20  Issues closed → sprint complete

Preventing QA bottlenecks:

Share staging URL early (day 5-6) — designers can flag issues while developer is still in flow
Daily async QA check: designer looks at staging 15 min/day during implementation
Clear acceptance criteria: define what 'done' means before sprint starts
Design token contracts: if token names match between Figma and CSS, half the color QA is automatic

Automated QA tools:

Chromatic (from Storybook): visual regression testing

Catches unintended changes: if a CSS change breaks 10 components, Chromatic flags all of them

Percy: screenshot-based visual testing in CI
BackstopJS: open-source visual regression

Automated QA in CI pipeline:

YAML

1# .github/workflows/visual-qa.yml
2jobs:
3  visual-regression:
4    steps:
5      - run: npx chromatic --project-token=$CHROMATIC_TOKEN
6      # Chromatic screenshots every Storybook story
7      # Flags any visual changes for designer review
8      # Designer approves changes that are intentional
9      # Rejects changes that are regressions

QA Session Report: Course Card Component

A complete QA session output comparing a staged course card against its Figma specification.

Example CodeText

1/* QA SESSION: Course Card Component
2   Figma: figma.com/file/xxx — 'Course Card / Default'
3   Staging: staging.devbootstrap.com/courses
4   Date: 2026-06-01 | Reviewer: Design team
5
6=== FINDING #1 — CRITICAL ===
7Issue: Missing focus-visible on Enroll button
8Spec:  outline: 2px solid #2563EB; outline-offset: 2px (Figma)
9Actual: No focus ring (outline: none in CSS resets)
10Fix:
11  .course-card__cta:focus-visible {
12    outline: 2px solid #2563eb;
13    outline-offset: 2px;
14  }
15
16=== FINDING #2 — HIGH ===
17Issue: Title font-weight incorrect
18Spec:  600 (Figma Inspect → font-weight: 600)
19Actual: 400 (DevTools Computed → font-weight: 400)
20Fix:
21  .course-card__title { font-weight: 600; }
22
23=== FINDING #3 — HIGH ===
24Issue: Hover shadow not applied
25Spec:  0 8px 24px rgb(0 0 0 / 0.1) (Figma shadow in hover variant)
26Actual: No shadow on hover (DevTools shows box-shadow: none on :hover)
27Fix:
28  .course-card:hover {
29    box-shadow: 0 8px 24px rgb(0 0 0 / 0.1);
30  }
31
32=== FINDING #4 — LOW ===
33Issue: Border-radius 2px too small
34Spec:  12px → 0.75rem (Figma: border-radius: 12)
35Actual: 10px → 0.625rem (DevTools: border-radius: 0.625rem)
36Fix:
37  .course-card { border-radius: 0.75rem; }
38
39=== PASSING ===
40Font sizes: title 1.125rem/600/1.44 ✓, meta 0.8125rem ✓
41Colors: title #111827 ✓, meta #6B7280 ✓, badge bg #DBEAFE ✓
42Responsive: 375px (1col) ✓, 768px (2col) ✓, 1440px (3col) ✓
43Border color on hover: #2563EB ✓
44Card body padding: 1rem ✓, gap: 0.5rem ✓
45
46=== QA RESULT: FAIL ===
471 Critical + 2 High findings
48Required before release: Findings #1, #2, #3
49Optional: Finding #4
50
51Developer action: Fix in same sprint, re-submit for QA sign-off */

How It Works

The QA report provides both the spec value and the actual DevTools value for every finding. Finding #1 (missing focus ring) is Critical because it breaks keyboard accessibility — the button cannot be focused at all via keyboard without the visible ring, which is a WCAG 2.1 AA failure. Findings #2 and #3 are High severity because they affect visual hierarchy (font-weight) and hover interaction (shadow). Finding #4 is Low because a 2px border-radius difference is below the threshold of perceptibility in most contexts. The exact CSS fixes are included — the developer can apply them without any additional communication.

Key Takeaways

Design QA covers six dimensions: layout, typography, color, interactive states, spacing, and responsiveness — all six must pass for a component to be accepted for release
Use DevTools Computed panel (not Styles) for QA — it shows final calculated values including inheritance, giving the actual rendered value rather than what the CSS file declares
The three most common QA failures are incorrect font-weight (400 instead of 600), missing hover state transitions, and spacing off by 4-8px — always check these first in self-QA before submitting
Document QA findings with exact Spec value, Actual value, and the specific CSS fix — findings without fixes require back-and-forth that slows correction by days
Chromatic automated visual regression testing catches unintended component changes in CI — it screenshots every Storybook story and flags visual diffs for designer approval before merge

What's Next?

The next lesson covers Figma Dev Mode in depth — the CSS generation, variable inspection, and annotation features that make design QA faster by reducing manual measurement against spec.

Your progress is saved in this browser, on this device only.

Previous: Figma Dev Mode Deep Dive & CSS Extraction

Next: Figma Dev Mode: Complete CSS Extraction Workflow

UI/UX Design

Design QA: Verifying Implementation Against Figma Specs

Learning Objectives

Introduction

The Design QA Checklist: Six Dimensions of Fidelity

QA Tools: DevTools Alongside Figma

Documenting QA Findings for Actionable Fixes

QA in the Sprint Workflow: Preventing Bottlenecks

QA Session Report: Course Card Component

How It Works

Key Takeaways

What's Next?

Table of Contents