by Jared Ponchot on June 1, 2012 // Short URL

Designing "in the Browser"

Is it for me?

"In all affairs it’s a healthy thing now and then to hang a question mark on the things you have long taken for granted." — BERTRAND RUSSELL

If you're like me, and visual, canvas-based tools like Photoshop are still a part of your design workflow, I hope to assuage any fears that you're a troglodyte. If you're one of those fancy pants people who doesn't touch anything that's not a text editor in your design workflow, I hope to hang a question mark on your process.

I recently attended A Web Afternoon, which is a fantastic little event here in Atlanta that brings in great designers and technologists from inside and outside Atlanta to speak about the web, design, and emerging technologies. It's a great event and I'm grateful to J. Cornelius and the others that put it on. J. and others like him help make the web design community here in Atlanta active and fun. There were a number of interesting and helpful talks at this year's Web Afternoon. There were talks on business, freelancing, social media strategy, women in tech, and some that were more design-focused as well.

There was one talk by Divya Manian that provoked me a bit. Divya works for Adobe's web platform team now and was formerly working for Opera. She's one of the people behind HTML5please and HTML5boilerplate, among other things, and an all around smart person and fun to listen to. Divya's talk was about "designing in the browser", and was largely focused on "why mockups suck". Now, I should say I've had thoughts on both sides of this issue for several years, and still find talks like this intriguing.

I've heard these arguments ad infinitum and I completely understand the limitations and weaknesses of high fidelity "mockups" created in a tool like Photoshop. As far back as 2008 I was reading the 37signals team talking about how they'd ditched Photoshop and went straight to HTML/CSS, and they made some compelling arguments. In case you've managed to avoid that conversation entirely, here's a list, handpicked and paraphrased by me from a variety of sources, of some of the most compelling arguments against designing website mockups in Photoshop:

  • Photoshop lacks tools for truly flowing type and floating elements within type.
  • Photoshop (at least prior to CS6) lacks the concept of reusable "styles" and therefore forces a great deal of re-work.
  • Photoshop provides a fixed canvas to work in and you're designing for a canvas that is not fixed.
  • Photoshop lacks any concept of pages and states of elements (this isn't entirely true), and leads to designers who don't really think about an interactive interface.
  • Clients looking at Photoshop mockups for approval are approving something that can't be identical to the real, finished product. Fonts are one of several things that simply don't render the same in Photoshop as they do within browsers.
  • Photoshop mockups are responsible for the concept of "pixel perfect design" being forced upon a highly-flexible medium.
  • Photoshop allows visual designers who have no knowledge of markup or CSS to "blue sky" in ways that are often not well suited to the medium they're designing for.

In spite of these arguments, designers like me (and perhaps you) continue to use tools like Photoshop within our workflows. Here are just a few reasons why.

The design process is much broader than any one tool or discipline

To me, suggesting that good design for web can only be done "within the browser" is akin to suggesting that good architectural design can only be done with 2x4's. On the flip side, suggesting that a web designer doesn't need to know and understand rudimentary things like HTML markup and CSS to design well for browsers is also like suggesting an architect need not know anything about how buildings get built in order to design one. Here be dragons!

I think the key point is that mockups and markup are just one small part of a broader design process. This is a process that should begin not in mockups or markup, and that often ends in something more complex and varied than simple markup as well. Many websites today are services with multiple interfaces, not all of which are built on markup or rendered in browsers. I'll soon be publishing articles on various aspects of our design process here at Lullabot, so I'll save more for another day on that.

Design drives technology more than technology drives design

While there may be exceptions to this claim, to a large degree, browser improvements have adapted technology to design, and not the other way around. Here's an elementary example. If designers had historically ONLY used CSS to design websites, and no designer had ever used a visual tool that allowed for things like gradients to be created, it's somewhat unlikely that we'd have gradients within the current CSS spec. In the words of the late Steve Jobs, "a lot of times, people don't know what they want until you show it to them."

Style and beauty come from people, not computers

Markup is about structure, CSS is about style. Style comes from the designer, not from the code. I encourage designers to use whatever tool suits them best to get them thinking visually, especially when in the styling phase of a project. As I mentioned before, our web design process at Lullabot begins well before we even think about opening Photoshop, and early on, is focused on understanding the root problems we're solving, the users we're solving them for, and the patterns by which similar problems have been solved in the web, software and elsewhere. By the time production of visual style comes into the process an enormous amount of work has already been done, none of which happens in Photoshop!

You can have it both ways!

Now that I've defended the use of Photoshop in your workflow, I should mention that we've engineered our process at Lullabot with the goal of producing as few Photoshop mocks as possible! We produce style tiles that are fully markup, though we create assets for them in Photoshop (and have a Photoshop template for doing so). These style tiles help define a direction for the fundamentals of style that often save us from producing a visual mock for every last corner of a website. Once a general aesthetic has been landed on, often from a mock of a single page of the site, we then begin implementing that visual style in markup and CSS and only use Photoshop along the way when we need to create specific elements or get back to thinking visually for a unique visual problem. Recent projects we've worked on have had only one or two static visual mocks for an entire large scale website. Yay! I promise, in my next article I'll begin to layout in more detail our design process here at Lullabot.

In Conclusion

As web designers, we work in a vibrant industry filled with lots of ideas and many who are great at voicing strong opinions. At least for me, it's easy to get sucked into trying to get everything right and wind up focusing on the wrong things. We all want to be great (or, I hope we do). I would posit that if you want to be a great web designer, focusing on the specific tools you use within your workflow is really not that helpful. Rather, focusing on how to uncover problems, how to understand users, how the technology of your medium works, how to discover and emulate beauty, and how to enjoy your work are going to be far more beneficial to your long term success! So go make something amazing, and use Photoshop if you want to. :-)

Jared Ponchot

Creative Director

Want Jared Ponchot to speak at your event? Contact us with the details and we’ll be in touch soon.


Darryn Nyberg


Love the article and especially the link to Styletiles. I first heard about styletiles in a drupal meetup organized by the owner of TheWeeklyDrop (great newsletter if you ever get a chance).

I have heard compelling arguments for and against both photoshop and browser design. You seem to have a good point on the integration of both and the need for designers to understand code.

Also great point about design pushing technology.

Thank you for the post!



A few personal thoughts

About 8 months ago I made the switch to responsive design. 99.9% of my project are done this way now. I attempted at first to start designing in the browser and quickly turned back to doing it in photoshop after only a few projects. Reasons why:

1. I noticed that my design quality went down. The stuff I was producing was based on what was easier to code. By doing it in photoshop first, that meant I forced myself to to code it. Essentially I was more creative in photoshop than in code.

2. It took longer to actually design in the browser. Adding simple concepts like rounded, corners gradients etc, while not hard, just takes a few minutes longer in the browser than in photoshop. Add a couple of minutes for each design aspect on a project adds up to a few hours in the end. Time saved, money saved.

3. Scrapping a design that is done is code is more more demoralizing than one in photoshop. I found that on some projects that were taking in a direction that I later regretted, it was somehow harder for me to scrap than one in photoshop.

I know do a hybrid of the two. I design the "normal layout" in photoshop. Ccode it. Then design in the browser for smaller device viewports.




The designing in/out of the browser debate is a funny one and I agree with most of your points. You are making it particularly hard for yourself though by using design software that was never intended for this kind of work (Photoshop). That's *your* decision and you can un-make it any time.

Fireworks fixes some of the issues described in your list of reasons why not to use Photoshop (in particular the point regarding pages/states).

I dumped Photoshop for Fireworks for these kinds of reasons years ago. Never looked back.



Good points...

With plugins like Firebug and the ability to compile tons of little code snippets in Coda 2, Codebox and other IDE's, designing in the browser will become more prevalent. At some point after the wire frame and mockup phase, it's the only way to do it. Going back and forth in photoshop for small iterations would just waste time.


Shaun Gorneau

I think this subject is moot

I think this subject is moot because design decisions should be made long before any visual representations are developed (other than small scope visual representations). Having brand guidelines, a developed content strategy, information architecture, and wireframes pretty much makes the "visual representation" stage an objective process. If clients want to see "what the site will look like" before the aformentioned prerequisites then it is our job to educate the client on the process.

With all that said, and entering the visual representation stage, I think "visual development" in the browser or any other tool (like Photoshop, Fireworks, Illustrator, etc.) becomes the preference of the designer; but I would argue in favor of "designing in the browser", which I believe is an inaccurate phrase for what is actually being executed.

HTML and CSS allow for rapid development of the visual representation where we can define design patterns that affect instances on the screen. Of course this can be done in layered iterations each becoming more detailed and fine tuned as the client approves them. The advantage here is being able to demonstrate the responsive attributes of the layout from the get go (even if what you coded up look like pure wireframes).

I think arguments for Photoshop (and the like) such as "design quality went down", "took longer to actually design in the browser", "Scrapping a design that is done is code is more more demoralizing than one in photoshop" are invalid arguments because they simply point to moving into the visual development phase without enough time spent in the design process.