Designing in the browser is a topic that comes up often as web designers shift to a responsive workflow. There’s something of a divide in opinion, though. Some insist designing in the browser is the only way to go, while others suggest it can’t be done and graphic editors like Photoshop are still required. I think part of the divide has to do with what it really means to design in a browser.
An article by David Bushell and a couple of presentations by Brett Victor caught my attention recently and both clarified my thoughts about designing in the browser and why questions about its value exist.
I wanted to share some thoughts about the article and presentations and then offer where my own process is when it comes to designing and developing a site.
What Does it Mean to Design in a Browser
David’s article suggests designing in the browser doesn’t mean abandoning the mock-ups we’ve always delivered to clients, but rather means adopting a more iterative and agile workflow for designing and developing a site.
I completely agree with the idea of designing with a more iterative process. Thinking back before responsive design a typical workflow moved through several phases each with different deliverables.
- Research and Planning — deliverables were most often written documents
- Design — deliverables were one or more static design comps for client sign off
- Development — deliverable was a site in progress seeking client feedback
- Deployment — deliverable was the finished site
The biggest problem is in that word static. Not that a website was ever a static thing, but it’s now less so under responsive design or at least the responsive part is calling our attention to the dynamic aspects more. A static comp produced in Photoshop doesn’t really give an accurate picture of how the design will work.
For clients to get the complete picture they need to see our designs in the browser, which means some development is going to be involved.
It doesn’t mean we have to abandon graphic editors. Designers are visual people and visual tools help us create. We’ll still sketch with pen and paper and use tools that allow us to move text and shapes around the canvas.
What’s most important is our old deliverables don’t communicate enough of what’s going on and browsers are better tools for the communication. We can still use graphics editors and send design comps as long as we and the client understand those comps aren’t communicating everything. As soon as possible we should push deliverables to the browser. Ultimately it leads to greater understanding and a better process with better results.
As David points out we can design outside the browser and communicate within it and the best way to accomplish that is with a more agile workflow where design and development happen in concert.
Thinking in Pictures or Procedural Abstraction
Brett Victor’s presentations aren’t specifically about web design. They’re more about the way we think and create. Both presentations demonstrate a new tool he’s working on and after watching I couldn’t help but see the connection with this divide about designing in the browser.
Here are the presentations (35 and 40 minutes) along with some additional notes from Brett. Again they aren’t specifically about web design, but both are interesting and I think worth watching.
- Drawing Dynamic Visualizations
- Additional Notes on “Drawing Dynamic Visualizations”
- Media for Thinking the Unthinkable
- An Ill-Advised Personal Note about “Media for Thinking the Unthinkable”
Brett suggests we currently have 3 ways to visualize data.
-
Use an existing tool or template — This is easy, but doesn’t allow for creative freedom. It’s not expressive, because you’re forced to work within the fixed structure of the tool or template.
-
You can draw (thinking in pictures) — This allows for creative freedom and a directness of expression, but presents a static picture of a system. New data requires a new drawing.
-
You can code (procedural abstraction) — This allows you to generate dynamic pictures, but does so by blindly manipulating symbols. You have to imagine the final visualization and can’t manipulate it directly.
It’s easy to think about these 3 ways of visualization in the context of responsive design workflows. The first is using a templating system like Bootstrap. The second is sketching and creating with tools like Photoshop that produce static mock-ups. The third is designing solely with code.
Brett doesn’t think any of the these 3 ways are ideal for visualizing the dynamic systems we deal with today. The tool he’s building aims at giving us a 4th way that will allow people to create visual pictures that can be dynamically updated.
Isn’t this the current divide over designing in the browser? Some people grab the nearest framework, make a few tweaks, and instant website. Others think in pictures and create however many static wireframes and comps they feel necessary. Some seem to suggest designing in code with the browser as a canvas.
What we’d ideally have is a combination of these things. Something that would allow us to draw pictures of procedural abstractions that we could directly manipulate and easily modify. Toss in a way to modularize some of the work we know will get repeated in or across projects and we’re set.
My Evolving Process
Unfortunately the tools we’d ideally like aren’t currently available. Our best solution at the moment comes back to adopting an agile workflow with more iteration and deliverables closer to the medium in which the work will live.
Ever since I began building responsive sites my workflow has been evolving. I find myself relying less on graphic editors for design, though I still sketch and make use of graphic tools. When using visual design tools I understand the result is only a static snapshot of the design and I’m delivering less of these static snapshots to clients, and presenting more deliverables in the browser.
Because my process is now more iterative and design and development occur together there aren’t clearly distinct phases like in the past.
- Research and planning
- Design
- Development
Research and planning still works like it always did. There’s a back and forth with the client as we both ask and answer questions. I also research the client’s industry to understand it better. My goal is to define a concept for the design, organize the information, set up the site architecture, etc.
Design begins with sketching and starts while I’m working out a concept. I may or may not work out visual details in a graphics editor. When I do I’m keeping these “static comps” rougher than in the past. They’re mainly for me and may never get sent to clients. I also create style guides that include possible typefaces, color palettes, and meaningful aesthetic details. While working in these style guides I tend to work out any necessary grid math.
I’m still working out the best way to create deliverables for this phase, but more and more the deliverable is living in a browser usually as a simple html/css page built around the layout I’ve sketched for the design.
Development begins with these deliverables. I use the information I work out in the style guides and add them to the layout. Essentially I build a rough version of the design in html and css and show it to the client. I try to keep everything as modular as possible to make changes quicker and easier. For example I’ll set up colors as Sass variables and if the client wants to try another palette it’s a quick change to incorporate a new color scheme.
Thinking about the process in regards to designing in the browser, I don’t literally design in the browser. Rather I refine in the browser. I create enough visuals for myself to get started developing. That always includes sketching and may include something more refined in a visual editor. As soon as possible I begin developing my rough idea and show it to my client in a browser. At that point the design is a collaborative iteration until we both agree it’s done.
The major change in my workflow has been to modularize the visual design as I work on type, color, layout, and aesthetics independently before combining them. As I’ve done that my deliverables are moving from a high fidelity comp to something of a cross between style guides, mood boards, and style tiles.
Summary
I understand why people are divided over designing in a browser. I think part of the reason is that designing in the browser isn’t literally designing in the browser, but rather moving deliverables to the browser sooner and iterating those deliverables until they become the finished site.
I also suspect whichever side you lean to in the divide has to do with how you entered the world of web design. If you entered from the graphic side, perhaps with a print background you probably feel more comfortable creating static comps. If you entered from the development side you probably feel more comfortable working with code and a browser.
What we ideally need are new tools that incorporate the visual and the dynamic and create deliverables that communicate more effectively to clients. Until then I think a more iterative and agile workflow where deliverables are pushed to the browser sooner is the way to go.
Download a free sample from my book, Design Fundamentals.
Great article! This consolidates some disconnected thoughts that have been floating around my mind about the problems with developing in either the browser or as static images.
I couldn’t help but be reminded of this Smashing Magazine article that is quite relevant to iterative development as well:
http://www.smashingmagazine.com/2012/05/29/mud-minimum-usable-design/
Applying these principles correctly may also help with the age old problem of clients assuming the website is finished once they see a picture of it.
Thanks John. I remember Paul’s post for Smashing Magazine. I was going to write a post here referring to it, but never did for some reason. It’s definitely a good read and I think it does apply to the current conversation.
I do agree with you that design is an iterative process, and we might currently be lacking tools.
I have a process that I find extremely helpful when I start creating design comps and I’ll just like to share.
What I do is that I’ll design static comps in photoshop according to the grids and layouts that I have determined in my sketching process. I then proceed to save the image and load them into the browser as a background image in the body selector.
Although there are many limitations, I feel that this small little step allows me to envision how the design really looks like in a web browser. I also create a few static comps with varying widths to show them in a browser for a “responsive mockup”.
I’ll prefer to go through as many iterations as I can with static comps before moving on to HTML and CSS, where SASS is then crucial to the whole iterating process.
Interesting process. I understand how it helps. For me it takes considerable time to create a comp in Photoshop, at least one with a lot of details. That’s why I’ve switched to creating much rougher comps, often in Keynote. I just want to get a general sense of the layout.
I know I’m going to have to build the layout eventually so now I do that earlier in the process. When I do I can add things like type and color and develop something that I can change quickly with client feedback.
For me it’s so much quicker than making changes in Photoshop and it has the added benefit that by the the time my client approves the design, much of the development work has been done.
That’s very true.
I dislike making changes in photoshop because it takes up so much time. On the other hand, if I have established a good foundation with variables in SASS, changing colors and minor layout details are much much faster than in photoshop.
How do you show your design comps to clients in the browser? I do most of my development work on a local host and I can’t share it with people at all.
Would love your insights
I’ve only recently started this and still working out the best way to send deliverables to clients. I first started sending out less detailed comps created in Keynote. I’d send them to clients mainly to get feedback on the general layout.
Then I’d build a single page with html and css and put it online. That’s becoming the deliverable I use instead of the more detailed comp.
The last site I built was a simple one page site for a client who’s been with me awhile. I never sent a comp of any kind. I just built the page and sent a link. The client sent feedback. I made changes. More feedback. More changes. Together we iterated the page until everyone was happy.
Interesting. Can I ask where do you put it online?
Say if I was creating a wordpress site for a client, the only place where I can think of showing the client it is either (1) on a separate domain that I own or (2) On their actual domain.
Either of them doesn’t seem to be attractive to me. for (1) I will have to “deploy” the site twice. Once on my extra domain, while the other time on the client’s actual domain while (2) might really mess up the client’s website if they currently have one..
I must be missing something here
I think this is a good example of how design is not about the tools you use. Tools communicate your ideas. If your tools are communicating, that’s a success.
I would say though, once you’ve communicated the idea to the client, why not move on to building the actual website?
I think Steven mentions he uses keynote. That’s really interesting because it supports my idea communicate quickly and efficiently at multiple places in the design process.
For me, I just show the client my sketchs and I talk through them. If the client agrees on the user flow and basic structure I move into HTML and CSS from there.
I think it’s all about communicating the idea quickly and accurately so you can move into development faster with the most clarity as possible.
A couple of years ago there were a few people talking about how they used Keynote to help them design prototypes for iOS apps. Keynote made it easy for them to link different pages and have everything display on a phone and act enough like the app they were developing.
Since I had Keynote I thought why not see what it could do and I found it really quick and easy to get a basic design down. It was detailed enough for me to see the design and even enough to send comps to clients. It didn’t take long at all though. It’s kind of like a wireframing tool with a little more fidelity.
I just place things inside a temporary folder on one of the domains I own. I’m not deploying a full site. Right now it’s really about creating a single page template in html and css and iterating that until we’re happy with the design. The template serves as a comp and once the client approves it, I’ll start developing it more completely locally.
Most sites I build are WordPress driven and I’m set up locally to build themes. I prefer to wait on putting things on the client’s domain until I have to.
If you need to build the site on the client’s domain there are several options. If there’s no current WordPress install just install it in a subfolder off the root and when it’s ready to take live you can adjust settings in WP so it runs as if it’s installed inside the root. Then you can rename or move the client’s old files.
If WordPress is installed you can create your theme in that install. There are plugins that will let you see your theme even if it’s not the one currently set. Search for theme switchers or something like that. Some will let you set things so you as admin will see the theme you’re developing while everyone else sees the existing theme.
I think you’re totally right. I’ve always said that design is not about which tool you use. Tools help you communicate your ideas. If the tool you’re using is doing that effectively than it’s a good tool.
All that said, I do think there’s a lot of reasons to try browser design. But like you said in the summary, it’s going to be easier for some than others.
I think the real difference is that Photoshop allows for a different type of visualization than the browser does. I find that designing in browser takes more compartmentalizing of your design process.
I put together some tips that I’ve lived by while designing in browser. I talk about a lot about how your design process has to change.
http://andysearles.com/designing-in-the-browser/
Let me know what you think.
Thanks Andrew. I completely agree about design not being the tools you use. They’re tools. You learn to use them so they can help you communicate. They influence what and how you communicate, because of what they can do and what you can do with them, but ultimately it’s you doing the communication.
As I read more from people on both sides of this, I started noticing those who preferred graphics editors clearly had a lot of skill with them. Those who preferred the browser seemed to feature less graphics in their designs. I started thinking the chose had a lot to do with which tools they felt most comfortable using and that’s fine. In the end whatever works best for you is the right approach to follow.
Now I’m off to read your post. 🙂
I think both you of are absolutely correct.
I usually set off with a few sketches to get a general feel for the design and send it off for discussion.
I think I go a little too much in detail afterwards when I switch over to photoshop and try to get as many details in as possible. Rather than allowing myself to be more creative, I find that I might be boxed up because of the amount of work required to change things in the photoshop comp.
Thanks for sharing your processes, it really helps clear up my mind
I was getting bogged down in Photoshop comps too. In part it was wanting to make them as refined and detailed as possible and in part it was me fighting against my own skills in Photoshop. I’m ok with it, but by no means great.
Sketching is always the start for me and lately when I’ve needed something more for a client I’ve been creating quick and less detailed comps using Keynote. I’m thinking of buying one of the vector editing apps for the Mac though and using that when I need to.
I am pushing more and more to the browser quicker and for me it’s helped. I seem to be getting through projects a little quicker than I was before.