Why we design in the browser now instead of handing off static comps

A static design comp shows exactly one, single state of a page: one specific screen width, one specific amount of text, one hover state, usually none at all shown explicitly. It's a genuinely beautiful lie about how the actual page is going to behave once real content, real screen sizes, and real user interaction all enter the picture at once. We've shifted most of our interface work to happen directly in the browser for exactly this reason.

A headline that's a tidy twelve words in the original mockup becomes a client's actual twenty-two-word headline once real copy arrives, and the layout that looked perfect at twelve words now wraps awkwardly or quietly breaks a card's careful alignment. Designing with real, or at minimum realistic, content from the very start, directly in a live browser, catches this kind of problem before it becomes an unpleasant surprise partway through development.

Handing off a single desktop comp and a single mobile comp leaves every screen width in between entirely to a developer's guesswork during implementation. Designing directly in the browser means testing the actual intermediate breakpoints as you go, catching the awkward tablet-width states that essentially never make it into a two-comp handoff process but absolutely show up in front of real visitors on real devices.

When design happens inside a component library that maps directly onto the actual production code, the same design tokens, a genuinely similar underlying structure, the gap between "design approved" and "feature actually shipped" shrinks considerably in practice. Developers aren't reverse-engineering precise spacing and color values from a flat static file anymore. They're implementing something already reasonably close to production-accurate from the start.

Reviewing work in a live, functioning browser instead of a static exported image changes the actual review conversation too. A client can resize the window themselves during the call, click through a real interaction, and ask "what happens if I do this" and get a genuine answer immediately, instead of a promise that it'll behave correctly once it's actually built.

This shifts feedback earlier and makes it more specific. Instead of a vague "can it feel more premium" comment on a static image, we get "this button needs to feel faster when I click it," which is a note we can actually act on precisely, rather than interpret.

We haven't abandoned static design work entirely, and pretending it has no place would be dishonest about how the process actually runs. Early exploratory concepts, the kind meant to communicate an overall direction and mood before any real layout decisions get locked in, are still faster and more useful as static comps, since building three full exploratory directions in the browser costs far more time than the exploration phase should reasonably take.

The shift happens once a direction is chosen and approved. From that point forward, everything moves into the browser, because that's the point where responsive behavior, real content, and actual interaction start to matter more than the broad visual mood the static comps were originally built to communicate.

This approach only works reliably with the right tooling in place, and we invested real time building it before rolling it out across client projects. A shared component library with design tokens that both designers and developers reference directly means a color or spacing change updates everywhere at once, rather than requiring a manual hunt through a static file and a separate hunt through the codebase to keep the two in sync.

Without that shared foundation, designing in the browser just becomes a slower, more fragile version of designing in a static tool, since every change still has to be manually reconciled between two disconnected systems. Getting the tooling right up front is what actually makes the workflow faster rather than just different.

Designing directly in a live browser environment requires a genuinely different skill set than producing static comps in a purely visual tool, closer to the boundary between design and front-end development than either discipline sat on its own before. We've adjusted our hiring and training accordingly, looking for designers comfortable working with real code and developers comfortable making real visual judgment calls, rather than treating the two roles as entirely separate lanes that only meet at a formal handoff.

This has been a genuine adjustment for some team members who trained in a purely static-tool environment, and the ones who've made the shift consistently tell us they can't imagine going back to handing off a flat file and hoping it survives contact with real content and a real browser.

A static comp gives a client something clean and unambiguous to formally approve, a specific, unchanging image, and some clients initially worry that a live, working prototype feels less final or less official as an approval artifact by comparison. We handle this by pairing every review session with a recorded video walkthrough plus a written summary of exactly what was approved and at what breakpoints, so there's still a clear, documented record of sign-off even though the thing being approved is interactive rather than a flat file.

In practice, most clients find this more reassuring, not less, once they've been through one review cycle this way, because they're approving something that behaves like the real product will, not a promise about how a static image will eventually translate into one.

Prospective clients sometimes compare proposals and notice a competing agency promising a full set of polished static comps for every page upfront, which can read as more thorough than our browser-first process on paper, especially before either approach has actually been experienced firsthand. We explain the tradeoff directly rather than letting the comparison stand unaddressed: a full static comp set looks more complete on day one and tends to require more expensive rework once real content and real breakpoints inevitably surface problems the static file never showed.

The clients who've worked with us through a full project consistently tell us the browser-first process felt slower to produce an initial visual on day one and faster to reach a genuinely finished, working product overall, because far less time gets spent later reconciling a beautiful static file with what a real browser and real content actually do to it.