Why the ‘design in the browser’ movement failed

Not long ago, every designer was talking about designing in the browser. The buzz around this idea has mostly faded, but you can save a ton of time and increase your creative output by designing in the browser selectively at key points in your process.

The original idea of designing in the browser was to stop using design software entirely, instead designing each interface as you build it. The argument was that mockups will never be close enough to the real thing. Designing in the browser lets you react and create in the real context, which is always better than trying to imitate the real thing in design tools.

In hindsight, the reason this failed is pretty obvious. Back when people were pushing the idea of designing in the browser, the assumption was that all designs should be created from scratch in the browser. And as it turns out, that’s really difficult.

Designing from scratch in the browser requires substantial coding skill, so much that it’s prohibitive to most designers. The sheer number of HTML tags and CSS properties to memorize alone is enough to kill it for many. Add other techniques like responsive design, mobile-first design, and progressive enhancement, and it’s an awful lot to learn.

Further, even for those of us who are experienced coders, designing while coding is just distracting. When you’re building a new layout, there are so many things to remember and account for, and it’s hard to be creative in the midst of that.

However, while the original movement is mostly over, designing in the browser can still be worthwhile and realistic for a larger number of designers with more basic coding ability, if you are more cautious about when you do it during the design process.

In fact, designing in the browser saves me tons of time and effort when I use it at the right times.

Examples of when to design in the browser

Designing animations, transitions, and interactive elements

Interactive elements encompass a lot more than a couple of snapshots. Even if you include layers or symbols for the various states of interactive elements in your design files, this really isn’t enough to get it right. For example, a button isn’t just a couple of snapshots of how it looks by default and on hover. Animations between the states play a huge role in the visual hierarchy of the design and the user’s overall understanding of the interface. Designers need to be able to design those transitions and animations too, not just the snapshots of the states.

Many designers turn to prototyping tools for this, and these tools are great. The catch is that many prototyping tools use different animation easing equations and properties that can be tough to match exactly using CSS. And most buttons will be animated in CSS, unless you’re designing for mobile.

Designing these animations right in the browser ensures that they can be implemented exactly as you design, and I think this gives designing in the browser an advantage over prototyping tools in this case.

Responsive layout design

Creating new mockups for every screen size or responsive breakpoint is incredibly time consuming. Not only is creating the first draft a lot of work, but every minor design revision requires updating across all mockups. Even if you’re using symbols and libraries, it’s a lot of work.

A much faster and effective process is to create a batch of mockups for just 1 screen size, then design the responsive layouts right in the browser after a grid system has been implemented. No matter what UI library you use, there’s a simple way to adjust elements amongst grid columns at various screen sizes.

Refining how the columns in the grid system are applied at breakpoints after some development has been done can be so much faster than planning it all out ahead of time in a design tool.

Adding small features or components

Often designers are challenged with designing a new feature or component within a view that already exists in a site or app. If you don’t have updated mockups for that view, you have to update design files or completely redraw the interface just to add the small element. This can take hours.

In these situations, I prefer to jump right into devtools and design the new component in the browser. I can often complete the new component design in less time than it would have taken me to update the mockups for the page. It’s a huge time saver and helps me avoid the tedious work of updating mockups.

Design revisions on early development builds

During and after design handoff, designers usually end up sending lists of minor change requests to developers. Usually it’s small stuff, like an incorrect font size or color here and there.

The workflow for sending these changes is a big hassle for both designers and developers. Designers often take screenshots and highlight the issues, or try to explain it in an email. There’s some back-and-forth until everyone understands one another. It takes a surprising amount of time just to get little issues like these fixed, and no one enjoys it.

The rare designer who can send pull requests directly on the live codebase has already solved this issue.

But for the rest of us, I’ve found that opening up devtools and making minor changes like these directly, then sending the CSS changes to a developer is equally expedient. Developers see the exact CSS that needs to change, can decide on how to implement the changes correctly, and there’s a lot less time spent explaining and asking questions.

Examples of when not to design in the browser

Do not design new projects or layouts from scratch in the browser

The hardest thing about design is staring at a blank screen and figuring out what to put on it. The creative challenge is enough. Coding at this early stage further complicates the challenge and forces you to consider too many things at once. Creativity thrives on constraints. You need to narrow your focus to do your best creative work, not expand it.

Designing from scratch in the browser will also slow down the pace of experimentation and exploration which is critical to finding the right solution. Designers need to move through ideas quickly in order to find the best one. Designing in code slows down that pace substantially, so that it takes longer to find the best idea.

For these reasons, when you’re starting a new project or full-featured layout, use your standard design tools!

Don’t create detailed graphics or visual design in the browser

This might seem obvious, but I’ve seen designers trying to design graphics, logos, and other detailed visual elements using SVG, JavaScript Canvas, and even CSS code. It’s kind of hilarious how much work it takes to draw a simple shape programmatically compared to doing it in design software.

On the other hand, some designers have recommended a different approach to visual design in the browser: creating wireframes in a design tool and then finalizing visual details like colors and fonts in the browser. The idea is that you figure out the most difficult part to build in a design tool, then do the rest in code.

This seems like a good idea on paper, but in practice it still breaks down. This is true even when using more convenient coding tools like CSS preprocessors which let you change a single color value globally in seconds. What ends up happening is that you’re still spending more time looking at the code than evaluating the visual qualities of the design. Again, this slows down the creative exploration that’s central to the design process.

Instead, get your fundamental design styles decided in a design tool before you move into the browser. That includes layout, type, color, and aesthetics.

Design in the browser is still worthwhile, if you do it right

Working directly in the browser still deserves a place in every designer’s process. If you try some of these ideas, you’ll find it can be a huge time saver, and that simple coding can feel equally creative and inspiring as working in a design tool.

If you’re ready to give it a try, check out my free ebook, Just Enough Code. You’ll learn all the fundamentals to get hacking in devtools within a 30 minute read.

Written by Jarrod Drysdale, creator of Mod&Dot

Just Enough Code. Learn just enough code to be dangerously creative. A free eBook from Mod&Dot.

Free eBook

Learn to Code

Code like a designer. Learn faster ways to prototype & explore ideas using basic coding. In a 30-minute read.

Get the Free Ebook