There is a gap between the file a designer hands over and the thing that reaches a user, and almost nobody owns it. The design is signed off, the tickets are closed, the build passes its tests, and the screen that ships is still subtly wrong. A label wraps. A disabled button looks like an enabled one. An error message appears in a place nobody looks.

This is not a developer failing. A Figma file shows one state of one screen at one width, with data the designer chose. A build has to survive every other combination. Design QA is the pass that closes that gap, and it takes about half a day.

Design QA is not a second design review

The distinction matters, because confusing the two is how design QA gets a reputation for slowing releases down. A design review asks whether this is the right screen. Design QA asks whether the built screen matches the agreed one, and whether it holds up under conditions the file never showed.

If you find yourself rethinking the layout during QA, you are doing the wrong activity at the wrong time. Write it down, ship the release, and take it to the next planning conversation.

The states the file never showed

Most design QA findings are states. A screen is designed full of plausible data and then meets reality.

  • Empty. First run, before the user has created anything. We wrote about this in empty states, the screens most SaaS products forget.
  • One. A chart with a single data point. A list with one row. Both tend to look broken.
  • Too many. A table with 400 rows, a name with 60 characters, a number with nine digits.
  • Filtered to nothing. Different from empty, and it needs a different message: the user did something, and can undo it.
  • Loading. Not a spinner over the whole page if only one panel is fetching.
  • Failed. Where does the message appear, and does it say what to do next.

On the investment dashboard the four cards at the top carry the whole first impression. They have to read correctly before a single holding has settled, which is a different design problem from the one the populated screen solves.

Text that is not the happy path

Designers type short, tidy words. Users do not.

  • The longest realistic name in the system, not “Jane Smith”.
  • Zero, and negative numbers, wherever a number appears.
  • A missing value: what renders when the field is genuinely blank.
  • Currency and date formats for the places you actually operate.

The Tronics registration system uses floating labels and conditional fields that appear behind a yes or no answer. Both are cheap to get subtly wrong in a build: a floating label that overlaps its value, a conditional field that appears but does not clear when the answer changes back.

Interaction, not just appearance

Static comparison catches spacing. It does not catch behaviour.

  • Focus. Tab through the screen. Every interactive element should show where you are.
  • Disabled versus hidden. If a control is disabled, it must be visibly different and it should say why.
  • Tap targets. Material Design asks for 48dp, Apple’s guidelines for 44pt, and WCAG 2.2 sets a 24 CSS pixel minimum at level AA. Check the small icons.
  • Destructive actions. Is the confirmation proportional, and is undo available where it should be.
  • Double submission. What happens if somebody taps twice.

The widths nobody designed

Designs get made at two or three widths. Browsers do not respect that. The awkward ones are around 820 to 900 pixels, where a two-column layout is deciding whether to collapse, and below 360, where the cheapest phones sit. We covered the low end in designing for a budget Android phone.

Check for horizontal scroll on every page. It is the single most common finding and the easiest to miss on a large monitor.

Who runs it, and when

The designer who drew the screens runs it, on a staging build, before the release is called done. Not after. A design QA pass on a shipped release is a bug report, and it competes with everything else in the backlog.

Record findings as screen, expected, actual, and a screenshot. Group them by severity honestly: a wrapped label on a rarely used settings page is not the same as a disabled state nobody can distinguish. Teams that mark everything critical get everything ignored.

What this has to do with the handover

Most design QA findings trace back to something the handover never specified. If you keep finding the same category of issue, fix the handover rather than the build: name the states, give the longest realistic string, say which element takes focus first.

This is also why we stay through implementation rather than handing over a file and leaving. It is in the UI/UX design work we do, and it is usually where the difference between the mockup and the product actually appears.

Frequently asked questions

How long should a design QA pass take?

Half a day for a normal release covering a handful of screens. If it is taking days, the handover was underspecified or the build drifted a long way from the agreed design.

Is this the same as accessibility testing?

No, and it does not replace it. Design QA catches some accessibility problems in passing, such as focus and tap targets, but a real accessibility audit uses assistive technology and covers far more.

Who should fix the findings?

The developer who built the screen, in the same release where practical. Small visual corrections batched into a later cleanup ticket tend to stay there.

What if the developer disagrees with a finding?

Then the handover was ambiguous. Resolve it by deciding what the correct behaviour is, then write it down so the question does not come back next release.

Do we need design QA if we have a design system?

A design system reduces the appearance findings, not the state findings. Components can be perfect and the screen can still have no empty state.

One check you can run today

Open your product, pick the busiest screen, and make it show nothing. Log in as a brand new account, or filter until no rows match. If what you see is a blank panel with no explanation, you have found the first item on your list, and it is almost certainly not the last.

If you would rather have somebody else find them, our free 15-point UX audit looks at a live product and comes back within one working day.