For years I designed the way everyone taught me to: static mockups, pixel-perfect, signed off, then handed to engineering to “make real.” It looked professional. It also lied — to the client and to me.
A flat mockup can’t tell you how a layout breaks at 380 pixels, what happens when the headline is twice as long, or how a hover feels under your cursor. You find all of that out later, during the build, when changes are expensive and everyone’s already attached to the picture.
A mockup is a promise about a thing. The browser is the thing.
What changed
Now I design hi-fi directly in the browser, on the same design tokens the final product will use. The “mockup” I show a client is real HTML — it resizes, it responds, it has working states. When they click it on their phone, that’s the actual behavior, not an approximation.
- Layouts are tested against real content lengths, not lorem ipsum.
- Responsive behavior is decided in the design phase, not patched in later.
- There’s no “handoff” — the design is the start of the build.
The token discipline underneath
This only works because everything sits on a shared system. Colors, type, spacing, and components are defined once, as tokens, and every screen pulls from them. Change the accent in one place and the whole site moves together.
--cobalt-500: #2563EB; /* one source of truth */
--font-display: "Space Grotesk";
--radius-lg: 10px;It feels slower for the first day. Then it’s faster forever — because nothing drifts, and the thing the client approved is the thing that ships.
What clients get out of it
Confidence, mostly. You’re not signing off on a picture and hoping the build matches. You’re steering the actual product, every Friday, while it’s still cheap to change your mind. By the time it launches, there are no surprises left in it.
That’s the whole pitch, really: see the real thing early, change it while it’s easy, ship something you’ve already used.