Because a mockup is a picture of a website and a website is a system that responds. The picture has one width, no loading state, no scroll, no keyboard, and no slow connection. Everything that makes a real site feel good or bad is absent from the artefact everyone approves.
We are not anti Figma. We use it every week and it is excellent at what it does. What we stopped doing is treating a Figma file as the source of truth for a website, because the file cannot answer most of the questions a website has to answer.
This is our opinion rather than a rule of the industry, and plenty of studios we respect work the other way. Here is the reasoning, including where the browser first approach genuinely costs us something.
It means making the visual decisions in the medium the work will ship in, rather than making them in a picture and translating afterwards. We still sketch, still explore directions, still build a visual language. We just move into the real thing much earlier than a traditional process would.
In practice a project starts with rough directions and a defined system, and then moves into Webflow while a lot is still unresolved. Typography, spacing, colour, and layout get settled on a real page at real widths, with real content.
The critical words there are real content. A mockup uses the copy that makes the layout look best. A browser makes you confront the headline that runs to three lines and the case study title nobody wanted to shorten.
Designing in the browser is not the same as skipping design. It is moving the moment of truth earlier, when changing your mind is still cheap.
Exploration and agreement. Figma is faster for generating options, easier for stakeholders to comment on, and far better for the early conversation where nobody knows what they want yet. Nothing in a browser matches the speed of dragging things around a canvas.
It is also genuinely strong as a systems tool now. Figma Design supports variables and components, and Dev Mode exists specifically to translate designs into code. Figma has clearly invested in the handoff being less lossy than it used to be.
So we use it for the messy front end of a project. Moodboards, directions, the hero concept, the thing the client needs to see before they can say yes. That work is genuinely better in Figma and we would not do it anywhere else.
What we do not do is take that file and treat it as a specification to be reproduced pixel for pixel. It is a direction, not a blueprint.
It tells you the truth about behaviour. Hover states, focus states, scroll behaviour, sticky headers, how a grid reflows at 900 pixels, what happens when a font loads late, how a video embed shifts the layout underneath it. All of that only exists once it is real.
Responsive behaviour is the biggest gap. A Figma file typically has three or four fixed frames. A website has every width between about 320 and 2560 pixels, and the interesting failures happen at the widths nobody made a frame for.
Motion is the second gap. An interaction that reads beautifully as a described idea can feel sluggish or distracting at real speed on a real device, and you cannot know which until it runs.
The third gap is the one nobody talks about. In a browser you find out how the design behaves when the CMS gives it something it did not expect, which is the state your site will actually spend its life in.
Because a mockup has no weight. Every image in Figma is instant, every font is already loaded, and nothing blocks anything. A design that looks refined on the canvas can carry four typefaces, a full screen video, and a dozen animated sections, and the file gives you no signal at all.
The thresholds are public and specific. The Google Core Web Vitals targets are Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less, measured at the 75th percentile of page loads across mobile and desktop.
Notice that Cumulative Layout Shift is a design problem as much as an engineering one. Layout shift comes from images without reserved space, late loading fonts, and injected banners, and all three are decisions made during design.
Designing in the browser means the cost of a decision shows up while you are making it. Across our projects we hold an average PageSpeed score of 98, and the honest explanation is not clever optimisation at the end. It is that expensive ideas get caught in week two instead of week seven.
Because most accessibility failures are behavioural or contextual, and a picture has no behaviour. You cannot tab through a mockup, cannot hear it read aloud, and cannot tell whether a focus ring is visible against the background because there is no focus ring.
Contrast is the exception and it is the most common failure of all. The WebAIM Million report from February 2026 found low contrast text on 83.9% of the million home pages it analysed, making it the single most detected accessibility failure on the web.
That number is instructive because contrast is completely visible in Figma. Designers can check it on the canvas and often do not, which suggests the problem is not the tool but the moment when checking happens. Move the checking earlier and it stops being a remediation task.
Everything else, focus order, keyboard traps, screen reader output, only exists in the browser. If your process discovers those at the end, you are not designing for them. You are patching around decisions that were already approved.
It closes the translation gap, not the thinking gap. The Figma to Webflow plugin converts auto layout frames into clean HTML and CSS, and Webflow describes it as syncing your styling, layouts, colours, text, and images across. The Webflow Labs app goes further and syncs Figma variables and components through the Designer APIs.
That is genuinely useful and we do use it. Converting auto layout frames into responsive flexbox structures removes a chunk of mechanical rebuilding, and being able to set HTML tags inside Figma means the semantic structure survives the trip.
But faster translation of a static design is still translation of a static design. If the original decision did not account for a 1200 pixel width, a slow font, or a keyboard user, the plugin will faithfully reproduce that. Speed is not the same as correctness.
Our view is that these tools are best used in the direction we already work. Push the system across, then design the behaviour where the behaviour lives.
They make this question more interesting, not less. Figma now lists Figma Sites in beta, described as publishing fully responsive websites, alongside Figma Make, which it describes as prompting to code anything you can imagine. The line between design tool and build tool is genuinely dissolving.
We think that trend supports the browser first argument rather than undermining it. If the design tool is becoming a build tool, then the industry is converging on exactly the thing we are describing, which is deciding in the medium rather than deciding about it.
The caution we would offer is the same one we would offer about any generated output. A tool that produces a working page quickly still produces a page somebody has to be accountable for, and the accountability covers the parts nobody looks at. We set out how we think about this in our piece on the AI web design workflow.
Fast is only an advantage if the thing produced is right. Otherwise it is just a quicker route to rework.
Direction in Figma, system defined, then into the browser early and iterate there with the client watching. Most builds run four to eight weeks, and the browser phase starts far sooner in that window than a traditional design and build split would allow.
The part clients notice is that reviews change character. Instead of approving a picture and hoping, they click through something real on their own phone. Feedback gets more specific and less abstract, because they are reacting to the thing rather than to a representation of it.
The part we notice is that the design system gets stress tested immediately. A component that works in one context and breaks in three others reveals itself in week two, which is when fixing it is a decision rather than a crisis. We wrote about building those systems to survive contact in our guide to the web design system.
The honest cost is that early browser work looks rougher than a polished mockup. Some clients find that uncomfortable, and we have to explain that unfinished is not the same as unconsidered. That conversation is a real cost of working this way.
Only if your finished sites keep disappointing you relative to the mockups. That gap is the symptom worth acting on. If your Figma files reliably become sites that feel as good as they looked, your process is working and you should leave it alone.
If they do not, try moving one page into the browser earlier than feels comfortable and see what surfaces. You do not have to change the whole process to learn something. A single page built at real widths with real content will tell you plenty about what your mockups have been hiding.
This is also one of the quiet reasons redesign projects go wrong, which we looked at separately in our piece on why website redesigns fail. A lot of failures trace back to decisions approved in a format that could not reveal the problem.
If you are weighing up how to run your next build and want to talk it through with people who have argued about this a lot, we would enjoy that conversation. Come and find us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.