The Figma-to-Browser Gap Is Where Design Actually Lives
A Figma file is a set of static frames. Even with prototyping, transitions, and smart animate — it is ultimately a sequence of images with some choreography.
That is not what users experience. Users experience motion, timing, response to input, states that weren't designed for, edge cases that weren't anticipated. They experience the gap between frames.
The gap is where design actually lives.
What Figma can't show you
Timing. A Figma prototype transition takes 300ms and looks smooth. In the browser, 300ms on a large DOM paint can feel sluggish. 150ms on a lightweight element can feel instant. The number is meaningless without the implementation context.
Physics. Spring animations feel different from easing curves. In Figma, you can approximate with ease curves. But the difference between a panel that eases open and a panel that springs open is the difference between "this feels like software" and "this feels like a real thing." That difference doesn't live in the spec. It lives in the browser.
State transitions. A Figma file shows you state A and state B. It doesn't show you the transition when A becomes B because the user did something unexpected. It doesn't show you the animation running over an existing animation. These states aren't edge cases — they're the normal use of any interactive interface.
Response latency. A click in Figma is instant. A click in a real application goes through an event handler, possibly a network request, a state update, a re-render. What does the interface look like during those 200–800ms? Figma doesn't have an answer. The browser does.
The designer who only works in Figma
A designer who hands off a spec and never sees the browser version is flying blind on half the product. They are designing static compositions and hoping that someone else resolves the dynamic behavior correctly.
This works at companies with enough resources to have a dedicated interaction designer, a thorough prototype review process, and a frontend team that proactively raises implementation questions. Most teams are not those companies.
Most teams ship designs where the gap is filled by whoever is closest to the deadline. Sometimes that's a thoughtful engineer. Sometimes it's no one — the default behavior of the library just runs.
What working in both looks like
My process: Figma defines intent. The browser defines truth.
I design components in Figma until the composition is right — hierarchy, color, spacing, responsive behavior. Then I build them. And when I build them, I discover things Figma couldn't tell me: this transition is too slow; this hover state draws the eye wrong in context; this loading state is jarring enough that it needs a skeleton.
Those discoveries go back into the design — not as Figma updates, necessarily, but as actual intent. The spec gets richer because I know what the browser is going to do with it.
The back-and-forth is not a sign of a broken process. It is the process. Design and implementation are not sequential stages — they're concurrent conversations, and the browser is a required participant.
Why this matters for the work
Interfaces that feel inevitable are not specified into existence. They're discovered through iteration between design intention and implementation reality.
The designers I respect most are not the ones who produce the most detailed Figma files. They're the ones who can feel the difference between a 0.3s ease and a spring, who know that a skeleton loader at 60fps feels different from one at 30fps, who open the browser early and treat what they find there as information.
Design is not complete when the Figma file is done. It's complete when the browser does something worth shipping.