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.

Key Takeaways

• Figma can show you composition. It cannot show you timing, physics, transition behaviour, or latency, and those four things are most of what an interface feels like.
• The thresholds that decide whether an interaction feels instant are published and specific: under 100ms reads as direct causation, and Google treats 200ms as the ceiling for a good interaction. Figma has no way to represent either.
• A spec is intent. The browser is truth. Treat the round trip between them as the process, not as rework.

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.

This isn't a matter of taste. Jakob Nielsen's three response time limits put the boundary for "the user caused this" at 0.1 seconds, the boundary for uninterrupted flow of thought at 1 second, and the boundary for holding attention at 10 seconds. Google's Interaction to Next Paint metric — INP, the time from a user's input to the next frame the browser actually paints — became a Core Web Vital in March 2024. It sets the "good" threshold at 200ms and the "poor" threshold at 500ms, measured at the 75th percentile of real interactions.

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.

Which is a claim you should not have to take on faith. Press play:

Neither curve is wrong. They say different things about what the object is made of, and no still frame distinguishes them. I go deeper on why in why your animations feel wrong.

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, and by the numbers above, most of that range is already past the point where the interaction stops feeling like the user's doing. Designing the waiting state is designing the product. I've written more about treating that as a design problem rather than an engineering one in designing for speed.

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. It's the same lesson I took away from building my first design system: the foundations you can't see in a static file are the ones that decide whether the thing holds up.

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.

At 60fps the browser has 16.7 milliseconds to run scripts, recalculate style and layout, and repaint. Miss that budget and you get jank: the visible stutter when the browser fails to produce a frame on time and the animation skips instead of moving. MDN's own note on this is the part designers tend to skip: a high and steady frame rate matters more than always hitting 60. A stutter is more noticeable than a slower animation that never drops a frame.

No Figma file has ever contained that fact. It only shows up when you build the thing.

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.