What Does It Really Mean To Design In The Browser?

Posted: 07 May 2015 05:30 AM PDT

What does it mean to design in the browser? You often hear the phrase connected to responsive design and I've talked about it myself a few times. What does it really mean though, and why do you see so many people push back against the idea of designing in a browser?

Note: This post includes an audio version. If you don’t see the audio player above, Click here to listen. You can also subscribe in iTunes

Some insist designing in the browser is the only way to design a website. Some say designing in the browser limits creativity and these people don't want to give up their graphic editors. What's going on? Why the split? Why so many for and so many against designing in the browser?

Like I said I've talked about this before, though I think it's been awhile. I was reminded of the topic by an article I recently came across from Stephen Hay. The article is from December of last year and I caught a reprint on Jared Spool's User Interface Engineering site.

I think the main reason for any pushback or misunderstanding is that detractors look at the phrase design in the browser literally and those in favor of it don't.

Deliverables in the Browser

When people say design in the browser they don't literally mean you have to design in the browser, though you certainly could design by writing code. I often do. Usually I sketch first to have an idea of what I'm coding and then I refine the design in code and view changes in one or more browsers. I can't remember the last time I opened a graphic editor to design a website.

However, that's not what design in the browser really means. Design in the browser just means moving your design to browsers as soon as possible.

As soon as possible see your design in the medium in which it will live. It doesn't make sense to show static comps. They've never been a good indicator of what a site will be. Deliverables should be in the browser.

A static comp shows a site or page design at a specific moment in time and under very specific conditions. The design is seen at an exact size perfect for viewing. There are no moving parts. Idealized content is used to make everything look just right. A static image simply can't tell the story about the design of a page or site.

You need to see and interact with your design in a browser to see if it works or not. Designers, developers, clients. anyone who works on the site or has a stake in it should be getting prototypes as deliverables and offering feedback on them.

Dan Mall called it deciding in the browser. I think of it as deliverables in the browser. All it really means is move your design to the medium in which it will live as soon as possible.

Thoughts, Words, Sketches, Code, and Prototypes

When I start a new design or a redesign I always begin by thinking. I collect my thoughts and write them down or type them out. They become the basis for questions I ask clients.

If there's an existing site I take a content inventory. I think about what page templates I'll need to design and what content belongs on each of those templates. Will there be breadcrumbs? A call to action button? I'll list all the elements that need to be on the page and then prioritize them.

I start with words, with verbal information. I think about the site's goals, what the client specifically wants, what the client has told me about his or her customers. I think about anything and everything that will help me better understand the problem so I can find a solution.

At some point I turn to the visual. I'll begin thinking in images to explore visual ideas. I'll start sketching ideas for layouts and how I might fit things onto the page. My sketches are very rough. They're only for me.

I used to take these sketches and turn them into high fidelity comps in Photoshop. Then I tried a little less fidelity working in Keynote. Now I don't bother with either. Instead I build a prototype.

It will be simple at first. It might be a few headings and paragraphs using real content for the site. Each heading and paragraph will be a different set of typeface pairings with different size, measure, and leading.

I build a simple page to show type options to a client. I don't present it as a design. I present it as some options for the client to choose. They offer feedback and I improve the prototype. I turn the rough prototype into what becomes the finished design one change at a time.

Maybe the next round includes a color scheme. I typically set colors as variables in a Sass file to represent the color scheme. I'll use a variety of tools like ColorSchemer Studio to choose colors and I'll add to and tweak the values in the Sass file. We (client and myself) will make decisions about colors after seeing them in browsers.

If the layout will be built on a grid, I'll work things out with pen and paper or more likely type in a text editor. Then I'll add the grid to the prototype.

I do literally design in the browser quite a bit and possibly more than most designers. It's easier for me to make changes to the code than to make changes in a graphic editor. They're just different tools with different sets of constraints and I choose the one easier for me work with. It likely does affect the resulting design, but it doesn't mean the resulting design has to look boring and lack creativity.

The only deliverable I've sent to clients the last few years is a link to a site in progress. I can't remember the last time I sent anything else. My clients can check the progress on the design any time they want, though I let them know whenever there are significant changes to check.

I doubt they resize their browsers, but they do check the design on every device they own and see how it changes from one device to the next. They get to offer feedback and make decisions based on how the site will function and look in the medium in which it will live.

I think it helps set expectations about the site and also gives clients a better idea of how much work is involved. Perhaps the best part is because my clients are involved in the process, they end up with a greater sense of ownership of the design making it much harder for them to ask for free changes later.

I'm always tweaking the process, but it's shown itself to work with my clients who are mainly one and two person businesses where I have direct contact with the owner. Your results may vary if your your clients are significantly different.

Does Designing in the Browser Limit Creativity?

One argument against the idea of designing in the browser is the thinking that designing with code and not graphic editors will lead to less creative design. I guess all the designers who worked in the days before computers lacked creativity, as they lacked access to Photoshop.

I disagree with the idea that you need a specific tool to be creative. You're welcome to use Photoshop or any other graphic editor if you want. And I'm free to use whatever tools I want.

Different tools just have different constraints. Some would argue prototyping and working more with code could lead to you giving in to the constraints of the browsers limiting what you can do.

Again I disagree. Your design will eventually live in browsers and be subject to all of the constraints of those browsers. It has to ultimately work in a browser so why not find out sooner than later if it does.

The Tool Doesn't Make You Creative

Your tools are not what make you creative. The tools are there to help you. I'm not knocking Photoshop (or your favorite graphic editor) by the way. It's great software that helps us do a lot of things we couldn't do otherwise. But it doesn't make you creative or limit your creativity.

The tools you should use are those that best align with your strengths and weaknesses. The tool should let you explore your strengths, while it compensates for your weaknesses and helps you to improve on them.

For me that's code. I can explore creative possibilities more by tweaking code than making changes in a graphic editor. I typically spend more time searching for how to do something in graphic editors. I know the code well enough that I don't have to look things up as much. I don't have to leave my creative flow as often.

Sometimes I can see something in my head and I already know how to code it. Writing the code is quicker for me. Any creativity or lack of creativity in my designs is due to me and not the tools I use.

That doesn't mean you have to do what I do. Explore different tools and find what works best for you. Thoughts, words, sketches, and code work for me. You should use whatever works for you.

The main thing is to move your design to browsers as soon as possible to see how it works. You can use static comps to communicate with your team, but I don't think they work well as deliverables to clients.

Closing Thoughts

While you can certainly design by writing code and viewing your code in a browser, that's not what the phrase design in the browser means. It's a poor choice of words for what is really deliverables in the browser or deciding in the browser.

A static image can't do justice to how a website functions or even how it will look. The only deliverables that can do justice to the finished product are those that are presented in the same medium. It means deliverables should be viewed in a browser or screen reader or any user agent that might later access the site.

I start with low fidelity prototypes and build up the fidelity as the projects progresses and as my client and myself work things out together. There are other ways you can start. You can turn a mood board or style guide into a simple prototype. How you put together the mood board or style guide initially is up to you, but when your client sees it let them see it as a working web page.

I think many designers who argue against the idea of designing in the browser do so because they think they can't be creative without their favorite tool. I don't agree, but perhaps it's true for some people. I think the tools you use work best when they align with your strengths and weaknesses and for some the preferred tools are visual in nature.

If that's you, great. Use Photoshop or Sketch or any visual design tool you want. However, it's silly to insist those tools are necessary, given the history of graphic design mostly precedes Photoshop.

I suspect many who push back come from a print background. They rely on and feel more comfortable working in a graphic editor. They don't want their favorite tools taken away and I don't blame them. I would feel exactly the same way.

I would never tell someone else what too they need to use, though. If you prefer Photoshop or Illustrator or Pixelmator or whatever, use it. Just understand that what you create in those tools doesn't make for a good deliverable to clients.

That's the point of designing in the browser, Use whatever tools you want to help you be creative. For me it's often code and I'm fine working under the literal definition of designing in the browser. You might find other tools work better with your design process.

No tool makes you creative or prevents you from being creative. All tools have their strengths and weaknesses and their own set of constraints. Choose whichever you prefer as long as you accept your design eventually needs to work as something more than a static image.

The best way to make sure it does is to push the design to code and browsers as soon as possible. That's all design in the browser really means.

Download a free sample from my book Design Fundamentals.

The post What Does It Really Mean To Design In The Browser? appeared first on Vanseo Design.