There's a moment in every project where I stop working in Figma and start working in the browser, and the project gets noticeably better. Not because the code is better than the mockup. Because I can finally see the thing I'm actually building.
In Figma, I'm looking at a picture of an interface. The spacing is whatever I set it to. The text is whatever I typed. The layout doesn't reflow, the data doesn't change, and nothing moves unless I've manually set up a prototype flow. It's useful for early exploration, but it's not the real thing.
Take spacing. I can set 24px between two sections in Figma and it looks fine. In the browser, with real content at a real viewport width, that same 24px might feel cramped because the text above runs longer than expected, or the visual weight of the element below is heavier than it looked in the mockup. Whether 24px is right depends on context that only exists in the running interface.
I make these calls in DevTools, and I use Agentation to annotate the changes so they're easy to communicate back to AI or commit directly. Select an element, adjust the margin live, watch how the page responds. Try 24. Try 32. Try 24 again. The right value usually becomes obvious once you can see it in context, and it's rarely the one I picked in Figma.
Type hierarchy is the same story. A type scale can look perfectly balanced in a Figma frame. In the browser, you see it against real content, real line lengths, real contrast with surrounding elements. A heading that felt right in isolation might not create enough separation from the body text when there's a dense paragraph underneath. Or a secondary label might disappear at small viewports because the size that worked on desktop doesn't hold up when the layout compresses.
Colour too. I'll pick a palette in Figma that looks cohesive in a grid of swatches. Then I'll see it in the browser and realise my muted text colour doesn't have enough contrast when there's a lot of it on screen, or that my primary vibrates against a particular grey in a way that didn't show up in the isolated swatch. Colours behave differently in context than in isolation. The browser is where you see the context.
Motion is the biggest one. Animation is almost impossible to design in a static tool. You can prototype a transition in Figma, but you're working with linear keyframes and fixed durations. You can't feel whether a spring-based ease with a specific stiffness and damping ratio is right. You can't judge whether an entrance animation is too fast until you see it at the actual frame rate on an actual device. And you can't tell whether it's performant... whether it stays on the compositor thread or triggers layout recalculation that causes jank on a lower-end phone.
Speaking of performance, that's another component that only shows up in the browser. I use DevTools' network throttling to see what the interface feels like on a slow connection. A design that looks great on fast wifi might feel broken on 3G when images load in stages and data takes seconds to arrive. That's a design problem, not an engineering problem. The decisions about what to show while things load, asset size, what to prioritise, whether a skeleton screen or a spinner is the right approach, these are choices about the user's experience of time, and you can only evaluate them by actually experiencing the delay. Same with CPU throttling. An animation that runs smoothly on my MacBook might stutter on a mid-range Android phone. I'd rather discover that during the refinement pass than after shipping.
The shift I've made over the past year is moving into the browser much earlier than I used to. I used to treat it as the place where designs got implemented. Now I treat it as the place where designs get finished. "Implemented" means the decisions are already made and you're translating them. "Finished" means there's a whole category of decisions that haven't been made yet, because they couldn't be, and the browser is where you make them.
In practice this means less time polishing Figma files and more time refining in DevTools.
This is only possible because AI handles the implementation gap. Before, "designing in the browser" meant either learning to code well enough to build what you wanted, or working so closely with an engineer that you could iterate together in real time. Both were expensive in different ways. AI removes that bottleneck. I can describe what I want, get a working implementation in seconds, then refine it in the real medium.
The part that took me longer to figure out is how to keep things consistent. When you're making taste decisions in the browser one component at a time, it's easy for the product to drift. The spacing that felt right on the dashboard doesn't quite match what you chose for the settings page. A colour that works in one context gets subtly adjusted in another. Without some structure, designing in the browser produces a product that feels hand-tuned in every individual spot but incoherent as a whole.
The answer, for me, is that the design system lives in the codebase rather than alongside it. Token scales (spacing, type, colour, radius, animation) are CSS custom properties that every component draws from. If a value isn't on the scale, it's immediately visible as an outlier. Component conventions (prop naming, composition patterns, variant structure) are codified in a Claude Code skill file I've open-sourced called system-craft. Project-level decisions live in CLAUDE.md files that carry context across sessions.
The thing I like about this setup is that the decisions I make while refining in the browser feed back into the system. If I discover that a particular spacing value works better than what I originally chose, I update the token scale, and that change propagates everywhere. If I find a better component pattern while building a feature, I codify it and every component built after that point inherits it. The product gets more consistent over time rather than less, because each design decision improves the system rather than just the thing I'm looking at.
For the decisions that matter most, the ones about whether something actually feels right, I make those in the browser. And because those decisions feed back into the token scales and component conventions that govern the rest of the project, the product gets more consistent the more I build. That's the thing I didn't expect. I thought designing in the browser would feel ad hoc. In practice, it's how the system comes together.