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.
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.
I haven’t done much code or design wise lately, too busy with work and school.
I need to play with it and test it, and to be able to share it live with friends or clients easily. If it’s an illustration or a graphic, it’s fine to send an image. But a website or app is not a graphic, it’s a living prototype that must go through several phases (and it must be useable). There’s really no way to tell if something is useful if you’re not using it.
That’s how I feel about it!
It’s been awhile since I was in school, but I completely understand. Once upon a time I was an engineering student and I still have no idea how I was able to keep up with all the work.
Obviously we feel the same way about designing in the browser. For me it’s just easier working with the code than with the graphic editor. That’s not always the case. I will sometimes sketch things out with a graphic tool. In fact, I’m planning a session of that in about an hour.
With some clients and at certain points in the project an image can make sense as a deliverable, but for most things you need something you can interact with and something that can change with user input to really understand the design.
I suppose if you’re dealing with someone who understands the process that person might be fine with an image. I can tell you from experience it hasn’t been fine with most of my clients. It’s only set unrealistic expectations and it raised questions about things I had already worked out, but couldn’t show in an image.
That makes sense.
I’ll use photoshop to develop color schemes or to design an image/group of images and slice it. Then I’ll just add images into the code, but I always establish a framework within the browser itself first. I believe that sets a firm foundation, whether it be WordPress, custom, or otherwise.
While I know many like to design the whole theme upfront and whatnot, to me it is not as valuable as establishing the framework first based on the site/app requirements.
What I’ll always do is sketch “on paper” first. 😉
Now I love that process and it goes perfect with setting up the framework in the browser.
With me learning responsive design now, I am even more cautious about the static nature of images in design programs. As I want my sites to be fluid, typically any images I make would fit right in the center to keep things simple.
Unless it’s a sidebar or something that will flow to the edge of the page or right outside the center.
Yep. I definitely don’t want to imply you can’t use Photoshop. It’s deliverables that shouldn’t be sent as static images produced by Photoshop.
I’m with you on sketches. It’s always an early part of my process.
Don’t feel like you have to place images in the center. You can still design responsively without centering images.
What a good read! I totally agree with most of this and I think this works really well when you’re working by youself. Whenever I do freelance by myself I get into the browser almost immediately and send the client a link. When I work on projects with other people and Im the designer I tend to stay in Photoshop/Sketch a lot longer since the developer is responsible for the decisions made with code. I’ve always wondered how people worked on projects with teams that designed in tge browser.
Thanks Steve. Great name by the way. No question this works better when you’re working for yourself and by yourself. I hope I was clear enough about who my clients are.
I can see how working with a team could make this more challenging. Since I’m both designer and developer it works well for me.
With teams I still think it makes sense to have a prototype in place as early as possible. I don’t think there’s one right way to do anything and that includes designing and developing websites.
I work in code because it is quicker for me and I can explore creatively working that way. If someone else works better and more creatively in a graphic editor then that’s what that person should use.
The main thing is the deliverables should love in a browser (or other user agent) as soon as possible since that’s where it will ultimately live and it’s the only place to get an accurate sense of the design.
I do agree with your saying that tools doesn’t make more creative or limits our creativity. Though I don’t know much coding but I am good in tweaking code to explore my creativity on websites rather than making changes on graphics.
Thanks Shefali. Yeah, tools are just things that help us express our creativity. There’s no question you’ll end up with a different expression using a different tool, but it’s not necessarily more or less creative. it’s just different.
This was a great piece. You articulated quite well something that I also experience and also gave me a lot of new ways to look at things that I already do.
Thanks Brandon. I’m glad you enjoyed the post and found it helpful.