Design In The Browser Means An Iterative Workflow

Posted: 17 Jun 2013 05:30 AM PDT

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.

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.

The post Design In The Browser Means An Iterative Workflow appeared first on Vanseo Design.