Process · October 20, 2026
Design in the Browser or Don’t Bother
Static mockups lie. The comp never survives contact with a real screen.
Elsie · Founder & Creative Director

We used to do the whole Figma dance. Three rounds of pixel-perfect mockups, a presentation deck, a round of revision comments, and then six weeks of development where the design quietly fell apart. The headline that looked perfect at 1440 pixels wrapped onto three lines on a client’s ThinkPad. The generous whitespace became a cramped mess the moment real copy, not lorem ipsum, went in.
The mockup is a promise you can’t keep
A static image cannot show you hover states, scroll pacing, how a font actually renders on Windows, or what the page feels like on a phone held in one hand on a bus. Those things are the website. Judging a site from a comp is like judging a film from a poster.
What we do instead
We still explore direction. Moodboards, type pairings, color systems, a few key frames. But within the first week of any build there is a live URL. Clients review work on their own phones, in their own browsers, and feedback is about the thing itself instead of a picture of the thing. Decisions get made faster, and they stick.
Nobody has ever asked us to bring the mockup phase back.
How a week actually runs
Monday is a conversation, not a deliverable. We talk about who the site is for, what they should do on it, and what the business needs to be true ninety days after launch. By Tuesday there is a type scale, a color decision, and a rough homepage skeleton running at a real URL. By Thursday the skeleton has your actual copy in it. Not lorem ipsum, because fake text hides every layout problem until it is too late to fix cheaply. Friday you get a link you can open on your phone and show your business partner at dinner. That link stays live for the whole project. It is never more than a few days stale.
The comp process gave clients one big reveal. This gives them forty small ones, and small reveals are where good decisions come from. You are never asked to approve something abstract. You are asked whether this specific button, on this specific screen, feels right. And if it does not, we change it in front of you.
What we still do on paper
None of this means designing blind. Before anything is built we still explore direction the old way: moodboards, type pairings tested at real sizes, a color system with actual contrast ratios checked, and two or three key frames that establish the tone. What we skip is the exhaustive screen-by-screen comping of every state and breakpoint. The work that looks thorough in a deck and evaporates in the first week of development. The thinking stays. The theater goes.
The questions that only a browser answers
Does the headline wrap badly on a thirteen-inch laptop? Does the fixed header fight the iPhone’s bottom bar? Does the animation feel smooth or does it jank on a three-year-old Android? Does the page still read well at two-hundred-percent zoom, which is how a meaningful slice of your visitors will actually see it? None of these are edge cases. They are the product. A mockup cannot answer any of them, and a team that designs in a static tool will not think to ask them until a client’s customer emails about it.
Performance is a design decision too, and it has to be made early. We set a page weight budget before the first hero image is chosen, the same way you would set a construction budget before picking finishes. It is much easier to design a fast site than to retrofit speed onto a slow one. The beautiful heavyweight comp that needs to be “optimized later” never actually gets fast. It just launches heavy and stays heavy.
When a mockup is still the right tool
To be fair: static design has its place. Investor decks, print collateral, signage, and early brand exploration all benefit from a controlled canvas. And for very large products, design systems with hundreds of components, a Figma library earns its keep as a reference, because engineers need a source of truth for states nobody has built yet. But even then, the library follows the build. The browser is where the truth gets decided; the file is where it gets documented.
What this means if you hire us
Expect a link before you expect a presentation. Expect to give feedback on real pages, in real browsers, on the phone you actually carry. Expect fewer meetings, because there is less to imagine and therefore less to debate. And expect the finished site to look like the thing you approved. Because the thing you approved was the site itself, not a picture of it.
The industry will keep selling the big reveal, because reveals are easy to photograph and hard to argue with in a boardroom. We will keep shipping links. Our clients’ conversion numbers are the only portfolio metric that has ever mattered to us, and those are decided in the browser. Where the work was designed all along.
Feedback without the meeting
Because the work is always live, feedback becomes asynchronous by default. Clients leave comments when it suits them, Tuesday night, Sunday morning, against the actual page instead of a PDF export that was stale before it was sent. We batch the notes, make the changes, and reply with the same link. No version numbers, no “final_v3_REALLYfinal” attachments, no forty-minute call to align on a button. The meeting load on a typical project dropped by more than half when we made this switch, and the decisions got better, because people give sharper feedback on things they can touch.
The mobile reality check
Here is the detail that ends the argument most quickly: for most of our clients, well over half of their visitors are on phones. A design process that begins on a twenty-seven-inch monitor and treats the phone as a “breakpoint” is designing for the minority experience first. Working in the browser flips that. The phone layout is not a squeezed-down afterthought reviewed in a narrower mockup. It is the same living page, checked on actual devices, from the first week. Thumb reach, tap targets, text size on a bright sidewalk: you catch these in a browser or you do not catch them at all.
What it costs, and why less
The comp-heavy process is not just slower. It is expensive. Weeks of meticulous static screens are billed hours, and those hours produce a document whose only destiny is to be approximated. Cutting that phase is one of the reasons our projects stay lean without cutting the craft. Clients are not paying for pictures of websites. They are paying for websites. Every hour of the budget lands in the product.
The habit worth stealing
Even if you never hire us, take this one practice: whoever builds your next site, ask for a live URL in the first week. Not a deck, not a walkthrough video. A link you can open on your phone. A team that can show you that is a team that builds. A team that cannot is a team that presents. The websites you love using were made by the first kind.
The objection we hear last
Occasionally a client worries the live-URL approach means the design will feel unpolished early. That showing work before it is finished will erode confidence. The opposite happens. Watching a site sharpen day by day builds more trust than any polished reveal, because there is nothing to hide behind. The rough edges are visible, then they are gone, and the client saw exactly when and how. Confidence is not the absence of visible process. It is the willingness to show it.
Why the industry resisted this for so long
The mockup era survived because it served the seller, not the buyer. Static comps are easy to annotate in a boardroom, easy to approve by committee, and, most of all, easy to sell. A beautiful deck creates a moment. A living URL creates accountability. Agencies that monetize moments had no reason to change. The tools finally made the choice for everyone: when a competent builder can have a real page up in an afternoon, billing three weeks for pictures of a page stops being a process and starts being a tell. Clients have noticed. That is why the requests for proposals we read have quietly changed over the last two years. Fewer “deliverables: design comps,” more “show us working software early.” The market figured it out before much of the industry did.
So design in the browser, or at minimum demand it from whoever you hire. The comp is a photograph of a meal. The URL is dinner. Hire the team that feeds you.
A final note on what this asks of clients: a little nerve. Reviewing rough, living work requires trusting that the roughness is a phase and not the destination. Every client who has made that leap with us has said the same thing at launch. Some version of “I cannot imagine approving this any other way.” The leap is small. The view from the other side is permanent.