By Mehdi HassanWhat is design QA and when should you run it?
Design QA is the step where a designer reviews the built product against the design and flags where they differ. It's not the same as functional QA, which checks that features work. Design QA checks that they look, read and behave the way they were designed, across states and screen sizes.
Run it per feature, on a staging build, before release, rather than once at the end of a project. Small, frequent reviews keep fixes cheap and stop the same mistake spreading across screens. Design QA is the final layer of a design-to-development handoff: the file says what to build, and QA confirms it was built.
What should a design QA checklist include?
A design QA checklist should cover nine areas, checked in order from the problems users notice most to the ones they notice least. Spacing and pixel details come late on purpose. A missing error state hurts users far more than a few pixels of padding.
- States: loading, empty, error, success, disabled and permission states all exist and match the design and annotations.
- Copy: the real, approved words are in place, with no placeholder text, typos or truncation that hides meaning.
- Responsive behavior: resize from the smallest to the largest width. Nothing overlaps, overflows or disappears unexpectedly.
- Components: buttons, inputs, menus and cards use the library components with the right variants, not near-copies.
- Layout and hierarchy: alignment, grouping and spacing between sections match the design's structure.
- Typography: font, size, weight, line height and the type scale at each breakpoint.
- Color and theming: tokens applied correctly, including hover, focus and pressed states, plus dark mode if you support it.
- Motion and feedback: transitions, timing and feedback on actions match the prototype or the motion notes.
- Accessibility basics: keyboard order, visible focus, labels, contrast and zoom behavior.
For product interfaces, add domain checks. Dashboards need number formatting and chart states, as in our SaaS dashboard design best practices. Apps with themes need a pass in each one, which our guide to dark mode for SaaS apps covers.
How do you run a design QA review step by step?
Run design QA as a fixed routine, so every feature gets the same review regardless of who does it. Here's the order we follow when we review our own builds.
Get a stable staging link
Review a deployed preview with realistic data, not a local build or a screen recording. Confirm which Figma section is the source of truth.
Walk the happy path first
Complete the main task once as a user would, noting anything that feels wrong before comparing details.
Force every state
Trigger empty, loading, error and permission states with test accounts, slow network throttling in browser devtools, or seeded data.
Resize and switch devices
Drag the browser through every width, then check on at least one real phone. Touch, scrolling and keyboards behave differently on hardware.
Compare details against Figma
Put the build and the frame side by side, or use an overlay extension, and check type, spacing and components.
Test with a keyboard
Tab through the whole flow, open and close every overlay, and run an automated accessibility check.
Log issues with severity
One issue per ticket, rated by severity, with evidence. Then agree on fixes with the developer in a short call.
How should you rate design QA issues by severity?
Rate every issue on a four-level scale agreed with engineering before the review starts. Severity decides what blocks release, what gets fixed in the next cycle and what goes on a polish list. Without it, every note looks equally urgent and developers have to guess.
Severity | Definition | Example | Action |
|---|---|---|---|
Blocker | Users can't complete the task, or the interface misleads them | Error state missing, so a failed payment looks successful | Fix before release |
Major | Clearly wrong and noticeable, but the task can be completed | Mobile menu covers the main action | Fix before release if possible |
Minor | Visible difference from the design that doesn't affect use | Wrong button variant in a secondary area | Fix in the next cycle |
Polish | Small visual detail only a careful eye would notice | Icon slightly misaligned with its label | Batch on a polish list |
Accessibility failures should start at major. A control that can't be reached by keyboard is a blocker for anyone who relies on one, whatever it looks like. Our accessible web app UI checklist lists the checks that deserve that treatment.
Which tools help with UI QA and visual QA?
Most design QA needs nothing more than a browser, devtools and the Figma file. Tools help with three jobs: comparing against the design, testing states and devices, and catching regressions after the first review.
Job | Tools teams commonly use | What they're good for |
|---|---|---|
Compare build with design | Figma Dev Mode, browser overlay extensions | Checking values and lining up the build with a frame |
Inspect and throttle | Chrome or Firefox devtools | Responsive modes, slow network, forced hover and focus states |
Component states | Storybook | Reviewing every variant and state without clicking through the app |
Visual regression | Playwright screenshots, Chromatic, Percy | Catching unintended visual changes in later releases |
Accessibility | axe DevTools, Lighthouse, a screen reader | Automated checks plus a real keyboard and reader pass |
Bug reporting | Screen recording and annotated screenshot tools | Clear evidence attached to each ticket |
Visual regression tests are worth setting up once a design system stabilizes, because they stop old screens from drifting when shared components change. They only compare against the last approved build, though. They can't tell you whether that build ever matched the design. That's still a human job.
How do you write a design QA report developers can act on?
Write each issue so a developer can fix it without asking a question. That means one issue per ticket, a clear title, the severity, where it happens, what you expected and what you saw.
Hypothetical example: a well-written QA ticket
For example, suppose a reviewer finds a problem in a checkout flow. A weak ticket says: payment form looks off on mobile. A useful ticket says:
Title: Card error message hidden behind keyboard on small screens. Severity: Major. Where: Checkout, payment step, widths below the sm breakpoint, tested on a real phone. Expected: error appears above the card field and the page scrolls to it, as in the Figma frame Checkout / Payment / Card declined. Actual: error renders below the field and stays hidden behind the on-screen keyboard. Steps: enter a declined test card and submit. Attached: screenshot and the Figma link.
The second version takes a minute longer to write and saves a round of back-and-forth.
Most QA issues trace back to the file: missing states, unclear responsive rules or detached components. Fixing those upstream with the Figma handoff checklist shrinks every future review. When the same team designs and builds, as on our projects, QA becomes a quick check rather than a negotiation, which is the core argument in why design handoffs fail. Before launch, pair this review with a website handover checklist so you own everything you paid for.
