Stop 11 · Collaboration & Developer HandoffTopics · 5/8

Design QA (Reviewing Built Features)

In short

The feature is built and it looks... almost right. Design QA is when you check the real build against the design and catch the small gaps before users ever see them.

Reviewing the actually-built, shipped feature against the original design — catching spacing, copy, or interaction drift before (or shortly after) release, closing the loop on design-dev consistency.

The jaadu stands on a stool trying on a sherwani while a tailor pins the long sleeve.

Think of it like this

The tailor's trial fitting

Before collecting your sherwani for the wedding, you go for a trial. The sleeve is slightly long, one button is loose. Small fixes now, or embarrassment on the big day. Design QA is your product's trial fitting.

Watch it happen

A design QA issue queue

enqueue(P1: Pay button cut off)

P1: Pay button cut off

Front of the queue is coloured

1/5On a small phone, the main button is hidden under the keyboard. Blocks users, so it's top priority.

The big ideas

What you need to know

Test on real devices

Check on actual phones, including a small and a cheap one. Emulators miss some real-world problems.

Check states, not just looks

Try errors, slow internet, long names and empty data. That's where builds differ from designs.

Prioritise issues

Separate blockers from polish. A clear priority helps engineers fix what matters first.

Report clearly

Each issue gets a screenshot, the device, expected vs actual, and a link to the design frame.

Save yourself the pain

Common mistakes

Oops

Sending a long list of '2px off' comments with no priorities.

Do this instead

Lead with issues that hurt users, then group small visual fixes together.

Oops

Only doing design QA the day before launch.

Do this instead

Review builds as they come, in staging or preview builds. Early fixes are quicker.

Your mission

QA a live site against itself

~30 min

Quick check

Which design QA issue should usually be fixed first?

Go deeper

1Compare a real shipped feature against its original design and list every discrepancy found.
2Learn to prioritize QA feedback by user impact, not just pixel-perfection.
3Practice giving QA feedback constructively, framed as collaboration, not blame.