Why I Like Designing in the Browser

It can be surprising for new clients to see just how much of our design process happens in HTML, CSS and (light) JavaScript. While we do plenty of ideation exercises, sketching, wireframes, mockups and more, we like to get our hands dirty in the browser as soon as we can.

There are business and process benefits to this approach, which we’ve written about before. In this article, I hope to answer a much smaller question:

What do I, a designer of 20+ years with many static mockups to his name, personally enjoy about designing in-browser with web standards in 2025?

For balance, I’ll include a few reasons why I enjoy dedicated design software, too.

Sound good? Let’s dive in!

Most design tools only approximate how the end result will look and feel. Will typography render as intended? Is that animation smooth or kinda janky? Does that toolbar feel weird when the virtual keyboard is visible? Is this idea even feasible?

When I’m already working in HTML and CSS, there’s no guessing. I immediately experience the strengths and weaknesses of the medium firsthand, and I can adapt to that reality in the moment instead of having to compromise much later in the process.

Many standards, especially in the last decade, don’t just streamline implementation: They open up whole new creative possibilities! CSS grid and subgrid, high-gamut color, container queries, scroll-driven animations, view transitions, color schemes and more!

Some of these ideas make it into design tools, but the wait can be long… understandably so, making interfaces for this stuff is hard! By the time Figma introduced their flexbox equivalent, the more powerful CSS Grid was already years into baseline availability.

It’s so much fun designing experiences with newer features as soon as our audience can benefit from them.

They say form should follow function, content should precede design, and there’s nothing more intimidating than a blank canvas. All reasons I love HTML as a starting point!

No matter what font family or color palette we’ve settled on, even if we’re waiting for finalized copy or feature requirements, there are usually a few basics I know a page will need: Headings, copy, navigation, form elements, etc.

It’s amazing how quickly I can stub out the majority of an interface’s building blocks with a small amount of basic HTML. Plus, that foundation can be surprisingly functional: I get links, accordions and various input types for free.

Whether you grew up with Silly Putty, Stretch Armstrong, Gak or a YouTube-fueled fascination with slime, you know that squashing and stretching stuff is fun. That’s how web pages work by default: Most HTML elements want to Elasti-Girl their way through any viewport size.

By comparison, design tools tend to assume static canvases of a fixed size. Some allow fluid-layout areas, or will approximate scrolling in a prototype mode. But you’ll probably end up maintaining separate mockups for a fraction of possible breakpoints.

So having a single design that’s nice and liquid by default? Perfect, no notes.

A good designer doesn’t pull pixel values out of thin air. These sizes result from a thought process, informed by an element’s importance and its relationship to everything around it. You didn’t size that heading at 36px because it’s your favorite number: You wanted it twice the size of your 18px body copy for adequate contrast.

CSS encourages you to express dimensions based on that intent, leaving most of the math to the browser:

• Want a heading that’s twice the size of the current copy? That’s 2em.
• Want that same value regardless of current copy? Swap em for rem.
• How about varying the size based on viewport width? Try vw units. Container width? Give cqi a whirl.
• Need to mix and match those options? calc lets you add, subtract, multiply and (usually) divide these values however you like.
• Want to try something fancy but keep the result within a minimum and maximum value? clamp lets you define that range.

And that’s just typography! Once you’re used to sizing things based on their relationship to the rest of the UI, pixels start to feel pretty limited by comparison.

Even seemingly minor design feedback can have a ripple effect. Unless you’re super diligent about maintaining a library of flexible symbols as you work, simply updating a button’s color could mean slogging your way through way too many mockups.

But in the browser, I’m not the one making those changes. That’s the browser’s job, based on instructions I write in the form of CSS. And I can apply those changes to as many elements as I want:

button {
  background-color: rebeccapurple;
  color: #fff;
}Code language: CSS (css)

Or as few as I want:

@container (inline-size >= 30em) {
  .intro > #cta:first-child {
    background-color: rebeccapurple;
    color: #fff;
  }
}Code language: CSS (css)

I type a few lines, hit ⌘ + S, and go take my dog for a walk.

There are countless ways to share browser-based mockups. Upload the files to a web server. Use a service like CodePen, Neocities or Val Town. If you know your way around a code repository, hook it up to Netlify or Cloudflare Pages or whatever. Drag a folder to a 3½-inch floppy disk, hide the disk in a hollowed-out book, leave the book at an agreed upon location. As long as those files make it to a web browser, you can view them, no license or subscription required.

And can we talk about the awesomeness that is dev tools? In any modern browser, developers (or curious nerds of any discipline) can inspect every size, color and property of every single element of the page without any additional effort from the designer. Super-powered design specs, absolutely free.

In the same way that I don’t limit myself to a single pen when drawing, I don’t expect a code editor to reasonably solve every design problem.

Most often, I rely on design apps for pre­production and asset creation. Flow charts, loose sketches, element collages, illustrations and iconography, preparation of images and video. These artifacts tend to benefit from free-floating layers and fixed dimensions. They may be theoretically possible to pull off in code (handwriting SVG, for example), but that can be a real slog.

And it’s hard to argue that design software isn’t more approachable in a project’s early days. I find HTML and CSS easier to grok than most Photoshop menus, but it’s a shorter walk from blank canvas to pretty pixels in a tool purpose-built for the task.

Usually, I’ll bounce back and forth. I’ll mock something up in the browser, then paste a screenshot in my image editor to quickly rough out a different idea. Or I’ll whip up an icon in Illustrator, then paste the SVG export back in my prototype.

Ultimately, any one design artifact is only as useful as what it contributes to the end result. No matter how much I enjoy a particular tool or workflow, if there’s too much friction or busy work for too little value, I’ll drop it like a hot potato.