We like static mockups for what they are good at: exploring a direction, agreeing on a rough shape, and getting a conversation started. But a static mockup is a drawing of an interface, not the interface. It lies about type, spacing, motion, responsiveness and performance.
So we prototype in the browser as early as we can. Not a polished build — a real one. Real content, real breakpoints, real components, real interactions. The point is not to show off. The point is to find out what the design actually is.
What the browser tells you that Figma cannot
- Type behaves differently. Line length, wrapping, font rendering and vertical rhythm change the feel of a page. You only see it when the text is real.
- Spacing is relational. A 32px gap looks generous in a frame and tight between two real components. The browser shows the relationships.
- Motion changes meaning. A transition that feels elegant in a prototype can feel slow in use. Timing is part of the design.
- Performance is a design constraint. A beautiful page that takes four seconds to load is not a beautiful page. The browser makes the cost visible.
- Engineers can react earlier. A shared prototype gives the team something concrete to discuss. It turns a review into a conversation about behaviour, not taste.
How we do it
We keep the stack small: semantic HTML, CSS, a little JavaScript when it earns its place. We use design tokens for colour, type and spacing so the prototype can become the product. We use real copy as soon as possible, because placeholder text hides the hard problems. And we resist the urge to polish too early. A rough prototype that answers a question is more valuable than a beautiful one that doesn't.
The trade-off
Prototyping in the browser takes a little longer at the start and a lot less time at the end. It also changes the conversation with clients: instead of approving a picture, they use the thing. That is a better test of whether the design works.
The earlier the work meets the browser, the fewer surprises there are at launch.