Why we still write HTML before opening Figma

A composition argument that survives every redesign cycle: prototype in the medium, then design the polish on top.

Most studios start in Figma. We don't.

For the last four years, the first artifact on every web project is an HTML prototype. Plain HTML, plain CSS, no framework, no design tokens. Just the structure of the page, the rough type scale, and the actual content laid out in the browser at the actual viewport. Sometimes it takes an hour. Sometimes a day. It's never skipped.

The reason is composition. Figma is a wonderful surface for visual decisions, but it's a poor surface for structural ones. A two-column layout that works on a 1920px artboard collapses badly at 380px, and Figma will let you ignore that for weeks before someone notices. The browser will not. The browser is honest about how content actually breaks, where the text wraps, what the line length feels like at the actual reading distance, and whether the section transition reads as one idea or two.

The browser is honest about how content actually breaks.

Writing HTML first also forces a content decision. You can't lay out a hero in HTML without knowing what the headline says, and you can't write the headline without knowing what the page is for. We've killed at least a dozen projects' worth of beautiful Figma artboards because the headline didn't survive the rewrite. Better to find out in plain text than in a polished mockup.

The Figma file still gets made: color, type variations, photographic direction, the polish layer that does need a design surface. But it's made on top of a structure that's already proven. The handoff to development is shorter, the build matches the spec, and the live site doesn't surprise anyone.

It's not a romantic argument. It's a tactical one. The HTML prototype is the cheapest place to find out a design doesn't work, and the most expensive place to skip.

Filed under Process. Have a question? Get in touch.

Recent postsAll posts
Mar 18, 2026

ACF Pro field architecture: a default starting point

The skeleton we start with on every WordPress build: flexible content blocks, options pages, and the rules we use to keep the dashboard livable.

Read
Feb 9, 2026

Migrating Squarespace to Shopify without losing search rankings

A redirect map, an hreflang plan, and a DNS cutover sequence: the parts of a migration that determine whether the new site arrives healthy.

Read
Jan 14, 2026

What we measure, and what we don't

An argument for fewer dashboards, fewer KPIs, and a single number per channel that the founder can recall from memory.

Read
Keep the thread going

Spotted something worth a reply?

We read every note. Send a thought, a counter-argument, or a brief for the thing you're building.

Send a noteStart a project