Designing in the Browser is Not the Answer | March 14, 2012

The argument for “designing in the browser” seems very seductive at first glance. The web is an interactive medium that defies the fixed canvas of traditional layout tools, so why not use the browser as your primary design environment?

The reason is simple. The browser was intended as a delivery mechanism with HTML and CSS a means of describing content rather than defining it (a subtile distinction I know, but an important one). As such the browser lacks even the most rudimentary tools like the ability to draw lines or irregular objects through direct manipulation. Instead this process is heavily abstracted through code. As the best design tools are the ones that put the smallest barrier between the creator and their creation (the pencil is a good example of this) designing in the browser adds an unnecessary level of cruft to the process.

Despite the ability to create rounded corners, drop shadows and gradients in CSS 3 (along with even more sophisticated effects using SVG and Canvas) it’s still preferable to present your richer design details as raster graphics. So designing in the browser forces you to do graphic production in one tool and then design layout in the other. Not only is this an inefficient process but it’s also the wrong way round. As such, “design in the browser” encourages a minimal design aesthetic based on the rendering capabilities of CSS. This may be acceptable for a small number of companies like 37 Signals, but I don’t believe this is desirable in most situations.

People seem to be treating “design in the browser” as a new idea, but in the early days of the web this was the norm. So it was only through the act of co-opting existing design tools like Photoshop that the quality of design on the web was pushed forward. Now I’m not saying that “design in the browser” will relegate us to 1999 style websites, as both the technology and our aesthetic abilities have moved on, but I do think it’s a step backwards rather than the great leap forwards as many people are suggesting.

This doesn’t mean that I believe that Fireworks or Photoshop are perfect tools and I’m fully aware of their inherent problems when it comes to the fluidity of the web. I just think that on balance and in most situations, these tools are the least worst options we have available. That’s not to say that all design must happen in Fireworks/Photoshop, or that no design should happen in the browser. After all I work for a company that believes in the power of HTML/CSS prototyping and does responsive design by default, so understand that a certain amount of back-and-forth is inevitable.

Until our tools evolve, traditional graphic design tools like Photoshop and Fireworks will remain the natural jumping off points for the majority of projects for many years to come. Designing in the browser isn’t the magic bullet many in the industry want (or are promoting) it to be. However I do think it’s a useful sign-post in what should be the true quest for a truly native web design tool.

Posted at March 14, 2012 6:38 PM


Natalia Ventre said on March 14, 2012 11:37 PM

For print, motion graphics, etc. there are very solid tools, but for the web, not so much, so I usually create some graphics in Fireworks but I design the link styles, buttons, etc. directly in CSS. It’s not ideal, but I rather spend my time building something real instead of a mockup that won’t perform well or it’s a nightmare to develop.

Kean said on March 15, 2012 11:02 AM

Designing in the browser seems to be advertised as a consequence of responsive design, saving the need to design sites at multiple breakpoints. In my experience knowing how to code gives you an awareness of how to build a responsive website and so you make relevant choices whilst still in Photoshop/Fireworks and adjust your design accordingly.

I’m in agreement with Andy where I see designing in a browser as a block to creativity and while the sites built in such a way are still functional and practice good design they can be visually bland and certainly suffer from the lack of being able to experiment within a graphics package.

Nick Bramwell said on March 15, 2012 11:22 AM

Interesting post, there seem to be quite a few people talking about it at the moment. In fact I blogged about it last week at

I think like many things it’s a case of using the right tools for the job. It depends on what the design needs to be, some sites that are more simple can easily be designed in the browser. While others are much better designed in a graphics package.

I think it also depends on your own skills, just like the difference between Fireworks or Photoshop. The best tool is the one that helps you get things done most effectively.

Jesse Bennett-Chamberlain said on March 15, 2012 5:47 PM

I’m really hoping that the next version of InDesign allows different sizes & orientations for pages as it appears they are doing here

If they can get that nailed down, and allow items to snap to the pixel grid, I think we’d be looking at a pretty great web design app for responsive design projects.

Rahul said on March 15, 2012 7:23 PM

“As such, “design in the browser” encourages a minimal design aesthetic based on the rendering capabilities of CSS”

This shows a misunderstanding of what the actual rendering capabilities of CSS are. Right now I’m working on a website design in which elements are positioned in 3d space using perspective and one can navigate by flying around that space using keyboard and mouse. This is all done with HTML, CSS and Javascript - no WebGL, no Canvas, no other crazy plugins. Just the basics.

To argue that CSS facilitates only minimalistic designs indicates you don’t really know the full extent of what CSS can do for you these days. Yes, in 2004 Basecamp reflected where CSS stood then. But there is much more possible today, and designing from the browser is an excellent approach which deserves at least as much recognition as any other tool.

I’m designing abovementioned site in the browser using my own web-based prototyping tool. I didn’t do any mockups or Photoshop design work because the idea I had could simply not be represented by those mediums. This approach is only going to become more accepted the more understood modern CSS is and the more browsers implement support for some of these features.

Much respect to you for CSS Mastery, but that book is nigh on 6 years old now and the landscape has changed. I suggest you dust off your CSS skills and have a look at what’s out there, because the “minimalistic encouragement” you’re describing simply does not exist anymore.

Marc Robichaud said on March 15, 2012 7:30 PM

My workflow goes something like:

paper > html > screen cap > photoshop > html > screen cap > photoshop > html > screen cap > photoshop > html > screen cap > photoshop > html > screen cap > photoshop > html > screen cap > photoshop > html

Process doesn’t have to be linear.

Rob said on March 16, 2012 4:13 PM

I think you nailed it with your conclusion. Design in browser is a (flawed) response to a lack of good tools.

I was really excited to see movements like pop up - I think it’s our responsibility in the industry to push for the tools we need to do our jobs. However, I think this mission is in danger of losing out to apathy. Let’s not let this one slip quietly away and simply accept what we are given!

Ryan Bollenbach said on March 17, 2012 4:34 PM

Hi Andy,

Very interesting article.

As Marc mentioned his workflow consisting of “paper > html > screen cap > photoshop > html” - I think this is more the definition of “designing in the browser”.

Now that a lot of brands are wanting responsive layouts, I feel that HTML responsive wireframes are a great way to start a project. Right from the get go, everyone involved in the project can get a sense of what the layout will look like in many different browser resolutions. Once you move into the look and feel stage, you can jump into illustrator or photoshop to bring up the visual design and then integrate it into your HTML wireframe. I’m in total agreement with you though, browsers are rendering devices not necessarily creative design tools (PS, AI).

I find that getting things designed faster in HTML allows more time for style and behaviour design which takes layouts to the next level.

Treavor Wagoner said on March 20, 2012 7:56 PM

I agree with you Andy. I mean, that’s how I started designing websites: in-browser design — until I discovered Photoshop.

And I think with responsive design (or rather, relative width websites long-favored by web programmers, the scientists of the Web world—let’s take up as much space as we can!) becoming the latest “thing,” maybe it really depends on the project.

For heavy graphic web sites, graphically-rendered first. For light, CSS-only web sites, a pencil sketch is enough of a jumping point.

But again I agree that always not doing a graphic render as a means for cutting corners and getting to communicatively successful-yet-visually appealing faster is not smart design. It’s really all about knowing what kind of process the web product/site needs.

David Aimi said on March 22, 2012 8:47 PM

Hi Andy,

After reading your article a few times, I’m afraid I absolutely don’t agree with what you have said.

Coming from someone who has spent well over a decade in both front-end development and design environments I can honestly say its refreshing to have some of the leg work and attention brought to the browser. And that is from a design, development, and architecture perspective. Why create things like graphic gradients and painful button image sprites by hand? The list goes on. The reason designing in the browser is easier for certain things is because code is more maintainable, and more time efficient then having to open a design suite, make a design change, and then replace the design element on the page. By rendering within a browser - you are also reducing server request load by limiting image requests to the server.

Your article also implies that traditional software like Photoshop, Fireworks, Illustrator, and more are somehow being replacing by browser designing? That is certainly not the case, nor is that the direction design is going. (In my opinion) If anything, designer responsibilities are growing and evolving to meet the demands of responsive websites and applications. With responsive web design & development we are heavily relying on designer’s abilities to adapt to things like an ever-changing fold, and device-agnostic design. The reason things like drop-shadow gradients were brought to browser rendering in the first place was because doing something like applying a drop shadow image gradient around something was a god-awful cluster nightmare. It’s my firm belief that application design has had TOO MUCH grasp onwebsites over the years. (i.e. flash).

I’m also confused as to “what the answer is”, given that your article only spoke about what you deemed not the answer.

Adrian said on March 23, 2012 11:48 PM

Interesting article. The agency I work for has recently began using the CSS framework ‘Foundation’. This seems to be reversing our design process with the aim of rapid prototyping and designing in the browser. I think we have to be careful not to compromise on design when taking this approach.

Thanks for sharing :)

David Trindade said on March 26, 2012 1:43 PM

Well said Andy.
I found that designing in the browser is just a pipeline (bad) dream. No real substance.
In real life projects how often do you have to come up with a working design to get the client to sign on the dotted line and commit to a project??
You would instead need a design mocked-up to showcase your ability to convey the product/service/website goals first, combined with your approach to solve the client’s needs, then get the client on-board before you show anything working.

Another thing that comes to mind is, If you design in the browser, What browser do use for it?
If you’re ‘desining’ in IE7 or 8 it might not look as refined and polished as if you’re ‘designing’ in Chrome, but i guess IE8-based design is not that big these days. Oh wait, what if you need to show the ‘design’ that you spent days crafting in your Chrome on the Mac on the clients old Dell using IE8 with Javascript disabled for example.
“Ooops, sorry, that side panel should be much nicer looking, with a nice shadow with rounded corners and this lovely subtle background…” That wouldn’t work in a real world client meeting would it?

Much easier to send a hi-def jpeg that can be easily opened and shown around the clients office, printed, added to other documents and so on.

The real craft is to design your sites with the added knowledge of how to code it, not to design with code.