The distance between Figma and the browser

A Figma file is a still image of an intention. It shows one screen, frozen, at a specific size, with placeholder text that always fits and a typeface that looks perfect because a design engine is painting it, not a browser. The browser is a different animal: a live medium with time, user input, a flaky network, a viewport that's never the one you drew, and a rendering engine with rules of its own. Between the photograph and the film there's a distance. At Sors we've learned to measure it, because that gap is exactly where it's decided whether a product feels good or only looks good.

This isn't a piece about renouncing Figma. Figma is irreplaceable for thinking in systems, for ordering a hierarchy, for arguing a direction before spending a single line of code. The trouble starts when we treat the mockup as if it were the product instead of what it is: a blueprint. A blueprint isn't the house. And there are decisions — about motion, states, performance, real responsiveness — that don't exist in the blueprint and yet make up 80% of what the user perceives with their body. That's why, more and more, we design and prototype in the browser itself.

Handoff isn't a delivery: it's a translation

We tend to talk about handoff as passing a parcel from one hand to another. It's really a translation from one language to another, and like every translation, it loses things. And what's lost isn't trivial. You lose the easing curves, because in the mockup a transition is an arrow between two frames while in the browser it's a function of time the user can interrupt halfway. You lose the behaviour of real text, which overflows, breaks onto two lines and knocks over the button that in Figma sat centred with three tidy words. You lose the true type rendering — the hinting, the antialiasing, the weight that at 14 pixels looks thinner than it did on a Retina screen at 200%. And you lose the states, which in the mockup exist only if you remember to draw them and in the browser exist whether you draw them or not: hover, focus, active, disabled, loading, empty, error.

The last 20%

We call "the last 20%" everything that separates a screen that looks finished from a product that feels finished. And it's almost never 20% of the effort: it's usually half the project's time. Motion is the most visible part. It isn't "add some animations"; it's that every transition has an honest duration — fast enough not to get in the way, slow enough to explain where each element came from — a curve that isn't the default linear one, and above all that it's interruptible. An animation you can't cut off halfway isn't motion, it's a video holding you hostage. None of that is decided in Figma; it's decided by feeling it with your finger on the glass.

Beneath motion sits the least glamorous and most decisive part: performance and real responsiveness. Performance means the first screen paints before the user hesitates, the main thread doesn't lock up while we load a gorgeous shader, the scroll runs at 60 fps on the mid-range phone most people carry — not on the studio's laptop. Real responsiveness isn't three breakpoints: it's a continuum. It's accepting that content dictates the layout, not some magic width; using container queries when a component should react to its container rather than the window; and testing the awkward range — that tablet in portrait, that folded phone — where no mockup ever existed. All of this is invisible in a still image and obvious within two seconds of use.

Designing with the real material

A carpenter doesn't design a chair without touching the wood, because wood has grain, splinters one way and not the other, has weight. The web has grain too: the CSS box, the cascade, the event model, the cost of repainting. Prototyping in code is designing by touching the material instead of drawing an idea of that material. When we move a component in the browser we feel the real latency, we watch how the text reflows for a client who writes nine-word headlines, we discover the beautiful shadow costs 12 milliseconds a frame and we decide with that fact on the table. The design decision and the technical constraint stop being two separate conversations — one in Figma, one in the pull request — and become the same one.

A perfect mockup breeds false confidence. The browser doesn't lie to you: if something feels wrong, it is wrong.

— Sors

The hidden cost of false fidelity

There's a specific trap in highly polished mockups: the more pixel-perfect a screen looks, the more confidence it breeds and the fewer questions it raises. Everyone approves, the client signs off, and the distance to the browser surfaces late — when it's already expensive. Then comes the conversation we all know: "why doesn't it look like Figma?". The honest answer is that it never looked like it in Figma, because Figma had no real text, no actual phone, no interruptible animation, no slow network. The mockup's fidelity was a promise the browser hadn't signed. That misunderstanding isn't fixed with more polish on the still image; it's prevented by showing something that moves and can be touched as early as possible, even if it's ugly.

How we close the gap

We don't close the distance with a new tool, but with four habits. First: get to the browser early, with a code prototype the moment the direction is clear, so decisions about motion, states and performance are made with the material in front of us and not from memory. Second: a shared vocabulary between design and code — tokens for colour, spacing, type and time — so a value means the same thing in the mockup and in the stylesheet, and handoff becomes a conversation rather than a throw over the wall. Third: treating motion and states as first-class deliverables, not a detail resolved at the end; if the error state isn't designed, it isn't finished. Fourth, the cheapest and the one that saves the most: reviewing on real devices, not in the comfortable simulator on the desktop.

In the end, the distance between Figma and the browser isn't eliminated: it's managed. Figma will stay the place where we think through form and system; the browser will stay the place where the product finally exists, with its weight and its temperature. Our job as a design, code and motion studio is to shrink the stretch between them until the jump stops surprising anyone. When that jump is short, the client doesn't ask why it doesn't look like the mockup — because the mockup already moved. And that, for us, is the difference between a pretty design and a product that feels right in the hand.