Designing in the browser

Designing on the web is changing. In a world of multiple devices and capabilities we have many new, exciting challenges. I have found designing in the browser to be a helpful approach in solving some of these design problems.

First off, some clarifications. Designing in the browser does not mean that you uninstall Photoshop, burn the license key and swear an oath never to push another pixel. Design in whatever way works for you. Get inspired in the park or with a Sharpie. Think through problems in the way you enjoy. Never let anyone tell you how you should be creative.

In what follows I would hope to convince you that:

1. We should spend design time working in the medium of HTML, CSS and JS.
2. Clients should be shown HTML and CSS mockups in place of static images as the final design deliverable where possible.

The static comp is a bad deliverable

Traditionally the final static comp has served two distinct purposes: to get client sign-off and as a blueprint to hand to a developer to build the final site. It's a bad deliverable in both these instances.

For clients it sets false expectations, emphasises the wrong things and does not represent the web well to beginners. As designers we are always communicating. Be it listening to clients, talking through approaches, working with feedback or convincing people at least half the work of design is communicating. Static comps confuse this communication. They emphasise surface impressions when we also need to talk about the feel of browsing and the experience of interacting. Getting "design sign-off" as images of pages we teach them to think of sites in terms of pages rather than components. Comps give a false impression of the web as something which neither ebbs nor flows but stays stubbornly static.

For developers static comps provide a confusing, incomplete and often frustrating blueprint. It's hard to get an overview of a site from images of a subset of its pages. A static comp does not describe well the purpose and potential re-usability of its contents. There is often confusion over what things should do and where they will be reused. Developers can also become frustrated with the assumptions contained in the comp. The perfect content of the comp gives way to reality lurking in the database. The unchanging perfection of static images can be hard to match in older browsers. Comps can become sink holes of developer time leading to brittle, buggy code and time misspent on elements of dubious importance.

The advantages of the browser

It's easy to criticise and poke holes. I don't want to spend more time being negative. All approaches have draw backs. I don't believe that designing in the browser is simply the least worst approach. I believe the compelling reasons for designing in the browser are its virtues rather than other approaches' failings.

Responsive by default

The web is responsive by default. We are all excited about responsive design. Proper geniuses are working on proper genius stuff. We are all experimenting and trying new things. Let's not forget, though, that the web is responsive by default. The basics of the web are to create HTML documents and have them be viewable almost everywhere on almost anything. By default the web has no optimal width, optimal height, optimal font-sizes or optimal anything really. Designing in the browser gives us responsiveness for free. It also, just as importantly, centers our design thinking around the fluidness of the web.

Designing in the browser gives practical benefits. We have tools (such as Shadow and LiveReload) to design across multiple devices simultaneously. We can experiment with our design and have the changes reflected instantly across desktops, tablets, phones in landscape and phones in portrait. This is Sci-Fi stuff! Just as importantly we are changing the way we think about designing web pages. We are designing with the diversity of the web in mind. In fact, more than that, we are designing with the variety of the web front and center. The variety of the web becomes part of our canvas.

Plan as prototype

As designers on the web we are lucky. Our medium is neither expensive nor impractical to shape. Architects can't easily test their ideas in brick. Few other mediums allow us to move so nimbly between plan and prototype. Let's cherish this. Let's spend time with our designs as practical rather than theoretical things.

Designing in the medium we will build in allows us to test our design decisions against something close to the final product. We can decide in a more informed way. We get to test more than just the surface appearance of our designs. We get to metaphorically hold them in our hands, measure their weight and test their balance.

This is not to say we must only design in the browser. Experiment and try things out in what ever way your comfortable with. Never listen to anyone who has a prescription for creativity. But try not to second guess your design. Make final decisions based on your impression of it in the browser.

Summary

Designing in the browser is not a silver bullet. I do believe, however, that it provides strong advantages over traditional approaches especially considering the new design challenges faced when designing across multiple devices.

It's as much a change in mindset as a change in tools. Designing in the browser gets clients, designers, UX people and developers focused on the product rather than a deliverable. It reminds us what and why we are building. Try it out, see how it feels, let me know how you get on.