Figma (and other web design tools) are working on the wrong file

Web design has a handoff problem. For 25 years, we’ve blamed it on communication problems, unclear specs, bad workflows, or developers “not matching the design.”

But the real issue is much simpler: the designer and the developer are working on different files.

When a designer creates a layout in Figma, they are placing objects in a coordinate system. Each object has a position and a size. Even with auto-layout and responsive variables, the underlying model remains the same: the designer is arranging objects on a fixed canvas.

That is not how a web page works. A web page is a set of rules a browser resolves at runtime. A box doesn’t have a fixed size; it has constraints. Layouts must respond to screen size, dynamic content length, accessibility settings, and user interaction. The browser calculates the actual size every time the page loads.

Figma’s model and the browser’s model are fundamentally different things. One is a coordinate system. The other is a rule system. Figma does not define its designs in the same way as a browser does.

Because of this, when developers receive a Figma file, they are forced to translate. They look at a box at a specific coordinate and reverse-engineer what CSS rules would produce something close to that in a real browser.

During that translation, information gets lost. How should this section behave on mobile? What happens when the text grows? Which spacing rules are intentional, and which are just artifacts of the mockup? That context isn’t in the file. It lives outside the design, scattered across Slack messages, meetings, Jira tickets, and assumptions. Both sides introduce error.

The handoff problem is a representation problem. The designer is handing off a picture, and asking the developer to build the thing the picture was approximating.

We’ve spent years trying to close this gap by teaching design tools more web concepts. Auto-layout approximates flexbox. Variables approximate CSS custom properties. Every year, tools move a little closer to how browsers work.

But approximations have edges, and eventually, they break.

The only way to fully close the gap is to stop approximating. Use an actual browser as the canvas. Use actual HTML and CSS as the file. But that would require replacing the core of what Figma is. Its coordinate-based scene graph is not an implementation detail; it is the product.

Imagine a design tool where the canvas is an actual browser window. A designer drags a button to the right, and somewhere in a CSS file, a margin value changes. A developer opens that same CSS file, adjusts the font size, and the visual canvas updates instantly.

No export. No handoff. No translation.

One file. Two ways to edit it.

A new generation of tools is finally starting to move in this direction. Onlook, Cursor’s visual editor, and others are experimenting with editing real code visually. While they are still early, and heavily indexed on complex React/Tailwind applications, the architecture is right.

But realizing this future requires more than just new architecture; it requires a shift in how we define reality in product design. Code must be the absolute master, not the design file. Code is what is live. It is what actually ships to the user.

We can still have an ideal goal in a design tool: a vision of what we want the page to be. We can use those visual canvases to map out ideas, note issues, and flag visual errors. But the HTML and CSS must remain the actual source of truth.

The future of web design doesn’t rely on generating code from a picture. It acknowledges that the code is the truth, and builds tools that let us mold that reality directly.