Design 2024-03-05 · 7 min

Why We Design in the Browser

Static mockups lie. Designing in the production stack catches edge cases early, keeps design and build aligned, and ships faster.

SYSTEM BLUEPRINT // DESIGN-IN-THE-BROWSER FIG. 01
STATIC FIGMA MOCKUP ✕ Fixed canvas resolution only ✕ Perfect dummy data (no edge cases) ✕ No real scroll, hover, or focus physics ✕ Zero performance / TTFB feedback Requires Lossy Hand-Off Translation LIVING BROWSER COMPONENT ✓ Fluid fluid-clamp responsive layout ✓ Live production state & dynamic data ✓ Native keyboard, touch, & ARIA compliance ✓ Sub-second real Core Web Vitals What You Review IS What Deploys

A Figma file is a promise. A running prototype in the browser is evidence. We moved our design process into the stack years ago, and we have not looked back.

What static mockups hide

  • Responsive behaviour at every breakpoint.
  • Real data: long names, missing images, empty states, error states.
  • Interactions: hover, focus, keyboard navigation, loading.
  • Performance: font loading, layout shift, paint cost.
  • Accessibility: contrast, semantics, ARIA — tested, not assumed.

The workflow

We design in Astro/React/Svelte components from day one. The design system tokens (colour, spacing, type scale) are defined in code, shared between design and build. There is no hand-off — the same components that are reviewed in design are the ones that ship.

Client review changes

Instead of PDF annotated with red lines, clients click a staging URL. They see the real thing. Feedback is precise because the medium is honest. We iterate in the same environment we ship from.

When we still use Figma

Rapid concept exploration, brand exploration, and presentation decks. The moment we are designing interfaces that will be built, we are in code.