Over the last year many blog posts have appeared on the web about the benefits and consequences of “designing in the browser,” which simply means foregoing the traditional use of image manipulation tools like Photoshop in the process of crafting visual mockups of a design and instead choosing HTML, CSS and Javascript code to build the visual design directly in the browser.
Because it is an ongoing debate in the Web Design world that seems to be picking up more steam as time goes on, we here at UX@UW decided to have each member of our team briefly share their thoughts on the matter to hopefully start a discussion and build understanding around the topic.
Jared says:
“I have found myself wanting to move straight into designing in the browser from early sketches on a lot of projects recently. Since I began adding LESS and UI packages such as Twitter Bootstrap to my workflow I have just found it to be faster.
It is much easier for me to modify existing code snippets than it is to push pixels in Photoshop. This allows me to get a functioning browser-ready prototype in a much shorter time than if I worked through Photoshop first, allowing for early testing of interactions and architecture.
I have tried to completely rely on designing in the browser but I have found that I end up feeling constrained by the limitations in CSS when used as a sole tool for design. I think Photoshop is still essential in my process for refining visual style and probably won’t ever be fully replaced by any amount of CSS or other browser-based design. I also think the approach I use is very project specific, with each project calling for its own blend of browser-based design and usage of other tools such as Photoshop.”
Jason says:
“Yay — it looks like Designing in the Browser vs. Photoshop is being unfurled as yet another divisive cause to get the Design world all a-Twitter and give design consultants something to blog about for the next few months. It is time for many of my fellow designers to get loud, polish those jackboots and tell everyone else to do things the way you do. I don’t get it.
Each of these tools (paper, Photoshop, CSS/HTML) simply assist the designer to efficiently and effectively answer the design questions they have at any point in the process. It is the prerogative of the individual designer to determine which tool is appropriate for them to use at what point and the responsibility of the individual to understand the affordances of the tool (and their expertise with the tool) for what they are trying to do.
At the stage where I am thinking about switching to primarily Designing in the Browser (cue thunder effects), I’ve pretty much made every critical design decision that needs to be made. I know what information needs to be presented and the priority of this information, what functionality needs to be present at each step to help the user complete their workflows, and I’ve ridden my data and assumptions as far as they will take me to make implementation decisions. For visual design, I have some ideas and all the rest is just tweaking. At this point, the real danger is that I isolate myself and get lost in the thicket of details, where I start fretting over subjective decisions (as I’ve exhausted all I can do objectively), which — as a UCD guy — I know should really be determined by my users or user proxies. Photoshop and sketching afford me this isolation in a way that designing in code does not.
A major reason that I don’t jump into the browser for earlier design work is that I don’t want the technology or my habits with the technology influence my design decisions. An affordance that Photoshop or my notebook both share is that they are implementation neutral and I find myself far freer in concentrating on what the experience should be rather than wondering how in the world it will be coded or looking through widget libraries for a best approximation.”
Ammy says:
“When I was a UX Designer, before taking a UX Researcher position, I always went through the following steps: (1) paper sketches; (2) Visio/Illustrator wireframes; and (3) Photoshop/Illustrator mockups. I have not done Designing in the Browser myself because I do not have the coding skills. However, I can see why those with the coding skills would want to skip a static high-fidelity prototype, and go right into an interactive HTML prototype.
Photoshop mockups (and the likes) are time-consuming. When I worked on it, I often got caught in visual details too early when I should have focused on overall design. In contrast, (IMHO) working with HTML will help designers focus on behavior, functionality, and overall design, which leads to a more testable prototype.
As a UX Researcher, I prefer to run a usability test with a working prototype because it helps us discover more usability issues very early on. In my recent project, MyUW Mobile web application, the designers went from wireframes to HTML prototype. We could even test conceptual design with a working prototype. It was much easier to test behaviors and interaction with a working prototype. So, if Designing in a Browser isn’t expensive for designers, I would vote for it!”
Sergei says:
“The benefit of having a Photoshop mockup is that it serves as a very detailed specification of how the design should look. To argue that one can get rid of Photoshop and jump straight to the browser, I think we would need to assume that the designer possesses the visual as well as the coding skills. This perfect blend is becoming more and more common, though. Also, static mockups are not only used for final delivery (communication with client), but also as prototyping tool that helps designers externalize their thinking and communicate with other designers.
I view static mockups as sketching — you are thinking while doing and not concerned with constraints relating to implementation, but only with having that conversation in the abstract that helps you move forward. I feel static mockups at various resolutions are still helpful. Low-res for the purpose of “sketching”, and hi-res for documenting nuances that are just not that easy to implement on the fly in the browser.”
Diego says:
“I have always felt some level of consternation when I hear designers expounding the benefits of “Designing in the Browser” as if all of a sudden they realized everything they’ve been doing wrong all along. It’s true the Web is not a static medium and some static tools we use in our work, like Photoshop for example, don’t fully extend themselves to the potential of the Web. There is no reason to abandon these proven tools, though, just based on their limitations in relation to the changing aspects of the Web. These tools add a significant contribution in the early part of what we should really be focused on — the entirety of the design process.
In my personal experience, I have ran afoul when I jumped straight into the browser without having a “blueprint” of sorts, having to eventually rewrite much code because of lack of visual and structural planning, and organization. Designers who are worth their mettle can easily turn a Photoshop comp into working HTML prototype with little effort. You will ultimately end up doing a minimal level of design in the browser — again, because the web is a dynamic beast that cannot be accurately represented statically — but I disagree that it should be an initial, major or sometimes only step in the design process.”
Lauren says:
“I worry that all this excitement about jumping straight into the HTML and CSS to create dynamic, interactive prototypes will make it too easy to skip over some of the important steps of user research, workflow discovery, information architecture, and usability testing. In particular, I have made good use of paper prototyping to gather user feedback at very early stages of product development.
One of the major arguments in favor of paper prototyping hinges on the idea that the lower the fidelity of the prototype, the more fundamental the feedback you’ll get. That is, sketches or basic grey-box wireframes will let users focus on issues with workflow or information organization, while a higher-fidelity prototype or comp will have them pointing out which color blue they prefer and asking why you chose that font. (Apparently this is still under discussion, though.) My concern with moving straight to the browser is that the value of this step will be lost.
Designing for the Browser doesn’t seem inherently to rule out “early and often” user feedback methods such as paper prototyping, or other internal and external deliverables that are traditionally produced in the early stages of projects (personas, workflow diagrams, etc.). It’s just a matter of being mindful of the quality and quantity of user research and feedback needed at each point, and identifying the right tool to use to seek it out, without letting our enthusiasm for a shiny new tool distract us.”