Figma vs functional: catching design/reality gaps early

Figma is where teams align on what they want users to feel. The build is where compromises, integrations, and edge cases show up. Functional QA sits in that gap — not to nitpick spacing, but to ask whether the journey still matches the promise.

My Figma pass is journey-first. I trace the critical path in the file: entry, happy path, error states, empty states, permissions, and anything that touches another system. Then I map the same path in the running product. Mismatches become questions before they become production surprises.

Common gaps I catch early: copy that changed in dev, buttons that exist in design but not in API reality, mobile breakpoints that collapse a flow, and “we will handle that in UAT” states that never got built. None of these require a designer to be wrong. They require someone to represent the user while the surface is still cheap to fix.

I log gaps as product-facing notes — severity tied to user impact, screenshots from both sides when useful. That keeps Design in the loop without turning QA into a comment war on hex codes.

When Figma review is done well, UAT gets shorter and calmer. Stakeholders are not discovering basic journey holes in week twelve. They are confirming that the built experience still serves the business case.