Figma vs functional: catching design/reality gaps early
Design files are intent. Production is behaviour. How I compare a Figma file with the running product, journey by journey, without turning the review into pixel policing.
Most teams find the gap between the Figma file and the build in UAT, when a stakeholder stops on the third screen and says “this is not what we approved”. By then the build is feature-complete, and the only question left is whether the difference is bad enough to hold a release.
Figma is where a team agrees what it wants users to feel. The build is where compromises, integrations and edge cases show up. Functional QA sits in that gap. My job there is to ask whether the journey still matches the promise, early enough that the answer is cheap to act on. Spacing can wait.
Why the design and the build drift apart
A design file is a statement of intent, drawn with ideal data: a short customer name, a round price, three tidy rows in a list. Nobody has to be wrong for the build to depart from it.
- The API cannot supply it. The screen shows a field or a button with nothing behind it in the back end, so the developer leaves it out or substitutes something close.
- Copy changed in development. A label was shortened to fit, or the text now comes from a CMS and nobody updated the file.
- The layout collapses on a real surface. A flow that reads well at desktop width loses a step or a button on a phone.
- States were promised for later. “We will handle that in UAT” covers the error, empty and no-permission screens that were never drawn and so were never built.
Each of these is reasonable on the day it happens. But nobody tells Product, so the approved journey and the shipped journey become two different things.
How to compare a Figma design with the running product
My pass is journey-first. Scanning the file and the build side by side finds whatever is easiest to see, and those are rarely the gaps that matter. I pick the journeys the release exists for and trace each one twice.
- Trace the journey in the file. Entry point, happy path, then every branch that was drawn: errors, empty screens, a user without permission, anything that depends on another system. I note the branches that are missing.
- Walk the same journey in the build. On the surface users will have, with data that looks like theirs: the long company name, the account with two hundred records, the restricted role.
- Mark where the two disagree. A step on one side only, a different order, different wording, a control that is drawn but does nothing.
- Turn each mismatch into a question. Which side is right, and who decides? I do not assume the file wins.
The first trace is worth doing before a build exists. A journey that cannot be completed on paper, because nobody drew what happens after a failed payment, will not be completed in code either. The second trace starts with the first testable build of each story, while the developer still has the code open. On mobile I do it on a physical device, for the reasons in Mobile QA beyond “run it on BrowserStack”.
Which design gaps to raise and which to let go
This is where a design review turns into pixel policing if nobody draws a line. Mine is user impact: does the difference change what someone can complete, see or understand?
| Gap | Example | What I do with it |
|---|---|---|
| The journey cannot be completed as designed | The design offers “edit booking”; the back end cannot change one | Raise it to Product the same day. It is a scope decision |
| A state was designed and not built | An expired session leaves the user on a blank page | Defect, with severity from the journey it interrupts |
| A state was built and never designed | The developer improvised the declined-payment message | Ask Design and Product if this is what users should read |
| Behaviour or copy differs | The design saves on every change; the build needs a Save button | A question. Either can be right, but someone has to choose |
| Visual difference only | Spacing, a shade of grey, icon weight | One batched note to Design, never a defect each |
The last row has two exceptions. A visual difference that makes text hard to read or a control hard to hit has a user consequence, and I treat it as one. And where brand fidelity is part of what the client is paying for, the designer and I agree up front who checks it. Usually the designer does, and my review stays on the journey.
How to log a design gap so someone decides
I log gaps as product-facing notes: where in the journey it sits, what the file shows, what the build does and what that means for the user, with a screenshot from each side when it helps. Severity follows user impact, as I argue in Defects Product thanks you for. That keeps Design in the loop without a comment war over hex codes.
- Journey: renew a parking permit. Step 3 of 5, payment.
- Design: after a declined card the user stays on the payment step, sees a message and can try another card.
- Build 2.4 on staging: a declined card returns the user to step 1 with the form cleared. No message.
- User impact: the customer re-enters everything and is not told why. Likely to abandon.
- Question for Product and Design: is the designed behaviour still wanted? If yes, this is a defect, severity high. Design frame and screen recording attached.
The question matters as much as the evidence. A gap logged as “does not match Figma” invites an argument about whether the file is current. A choice between two behaviours, with the consequence of each, gets an answer. Sometimes the answer is that the build is right, because Engineering met a constraint the design did not know about. Then the file or the acceptance criteria are updated, and the next person does not raise it again.
Objections to QA reviewing designs
The first objection is that this is the designer’s job. Designers do review builds, and they should: they check that the build is faithful to the design. I check that a user can get through it. The two reviews catch different things.
The second is that the Figma file is out of date, so comparing against it is pointless. That is itself a finding. If the file is stale and the tickets are thin, nobody can say what the product is supposed to do. I ask Product to name the source of truth for each journey and compare against that.
When the comparison is done early, UAT gets shorter and calmer. Stakeholders are no longer discovering basic journey holes in week twelve. They are confirming that the built experience still serves the business case, and the places where it differs from the design are ones somebody chose.
Questions I get asked
Should QA test against the Figma design or the acceptance criteria?
Both, for different things. Acceptance criteria say what must be true for the story to be accepted. The design shows how the journey was meant to look and flow, including states the criteria may not mention. When the two disagree, or the build disagrees with either, that is a question for Product to settle. The tester should not pick a winner alone.
Is design QA the same as functional testing?
No. Design QA is usually a designer checking that the build is visually faithful to the file: spacing, type, colour and components. Functional testing checks that a user can complete the journey and that the behaviour is correct. A functional tester comparing design with build is looking for differences that change what the user can do or understand, and leaves visual fidelity to the designer.
What should QA do when the build does not match the Figma file?
Work out whether the difference affects the user. If it only affects appearance, batch it into a note for Design. If it changes what a user can complete, see or understand, log it with a screenshot from each side and the user impact, and ask Product and Design which behaviour is intended. The build may be right, in which case the design or the criteria get updated.
Filed under Product validation and acceptance criteria. Terms: Product validation.
