1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
---
title: Zen and the Art of the Responsive Web Design Workflow
pub_date: 2014-03-12 10:08:57
slug: /blog/2014/03/zen-art-responsive-design-workflow
metadesc: Embracing the fluid nature of responsive web design means you can start building websites like Bruce Lee.
tags: Responsive Web Design
tutorials: True
---
[*Note: This is an excerpt from my book, [Build a Better Web With Responsive Web Design](https://longhandpixels.net/books/responsive-web-design). If you like what you read here, pick up a copy of the book and be sure to sign up for the newsletter over there in the sidebar.*]
[TOC]
If your current workflow is anything like mine and that of other designers I have worked with, it probably goes something like this: wireframe content -> sketch designs -> convert those to Photoshop comps -> pass to client for approval -> convert to HTML/CSS/JavaScript. I've left out a few steps, but the basic idea is pretty simple: Photoshop is the first place you go after you have the skeleton of the design on paper.
Perhaps not coincidentally that's almost exactly the workflow (albeit a greatly simplified version) of Wired magazine's print edition. It's the workflow that web designers inherited from print and one that's still taught in all but the most forward thinking web design programs. It's taught because for a long time it worked. Sure people might resize their browser or text, but for the most part you could mock up something in Photoshop and reliably convert it to HTML and CSS with maybe a bit of JavaScript thrown in.
To embrace a responsive approach and stick with the this workflow means you're going to have a very hard time not just thinking responsively but mocking things up. How will you know where your breakpoints need to be without putting your designs in a live browser and resizing them? Once you have those breakpoints you're going to have to back the Photoshop and create what, 4 mockups? 6? 10? That's a lot of extra work.
[](/media/images/2014/workflows-the-hard-way.jpg "View Image 1")
: Mockups the hard way. Why create tons of different size and state mockups in Photoshop when you can actually build it, live, fully-functional in the browser?
Just as we've shrugged off so much of the print design legacy in other ways -- flexible canvases, fluid designs and flowing text -- it's time to shrug off the print design workflow. It's time to put down the Photoshop, step away from the pixels and rethink our approach from the ground up.
That doesn't mean we shouldn't learn from print. A lot of web developers talk about starting from the content and working your way out, which is exactly what print designers do as well. The content should always be the starting point, but the way we think about the content and the way we figure out how it will behave and appear to the user needs to change.
## Working with the Responsive Flow
Quite frankly coming up with a responsive workflow that really works is going to take some experimentation on your part. Whether you're part of a small team, large team or working on your own, you have your idiosyncrasies and tics to consider. A good workflow will work with, not against your unique style.
While you should embrace your idiosyncrasies and tics, there are some general guidelines that have emerged from those of us who have worked on responsive sites big and small. I'm going to offer some methods and tools in the hope that they prove beneficial to you and your team.
The biggest change I suggest making when -- or even before -- you attempt your first responsive design project is to get your designers and developers working together. Too often developers are brought in much later in the process, after the design work is already done. That might work when your designs have only one, set in stone width, but for responsive design you'll likely benefit from bringing in developers right at the outset.
When your design and development teams work together you can start to get the kind of feedback loop you need for effective responsive workflows. Collaboration means there's immediate feedback for both teams. Developers can point out scenarios where designs fail and designers can go back and handle those. You decrease the likelihood of anything falling through the cracks. For example, what happens when the user denies access to geo-location data? What happens when the JavaScript fails and the ads don't load? What happens when the third-party fonts fail?
Developers tend to be better at imagining all the ways in which a design can fail. Let them in early so they can better inform the process. They can point out problems early, before they require a massive effort to solve.
The other side of the coin comes later, when you're building out the actual site. Keep designers involved and they can help sort out unforeseen problems. Developers might not know the why behind a decision, but if your designers are working alongside them they can help guide the development process by offering insight into decisions and helping to ensure the original, client-approved vision is maintained.
This sort of workflow necessarily requires good communication skills, but more than anything it requires rethinking your approach. Gone are the days when designers handed their work to developers and moved on. Gone too are the days when developers could just sit back and wait for finalized mockups to convert to HTML and CSS. If such days ever existed at all, they are certainly behind us now.
If your design and development teams aren't working together, get them working together post haste.
What does this look like on a practical level?
Well, as I've written elsewhere, [start with content](https://longhandpixels.net/blog/2014/02/work-smarter-plain-text-workflow#everything-starts-with-the-content) when you can.
Once you have the content you can move on to sketching and wireframing -- figuring out the structure of the page and overall site. I tend to do this stage mostly on paper because if find it the fastest way to get my ideas recorded, but I've seen other developers who use iPads with styluses, mind mapping tools, even one who used spreadsheets to create wireframes (yeah, he was a little strange).
If you haven't before embrace what designer Jason Santa Maria once termed the "[gray box method](http://v3.jasonsantamaria.com/archive/2004/05/24/grey_box_method.php)". That is, wireframe the basic elements of your site as a series of gray boxes you can then shuffle and rearrange as you figure out which bits of content need to go where on various layouts and screen sizes. You can even take this literally, cutting our gray shapes and taping them to something like a white board in various configurations. The point of using gray is to stop, in Santa Maria's words, "worrying about color and imagery choices and allow myself to focus on the site’s structure and hierarchy." This is particularly helpful in responsive design because it forces you to consider from the outset how you'll need to reshuffle content as the screen size changes.
Along with wireframes, I sketch user flows and step by step scenarios based on how the client imagines their visitors interacting with the site. This helps with design obviously, but it also helps tremendously when you get to the testing stage by providing an ideal against which to measure how visitors *actually* interact with the site. The gap between those two things becomes the basis of the next iteration.
## Designing in the Browser
Once I have a good idea of how I want to arrange the content on the page I immediately jump into the browser and start working with live HTML. At this point I'm just stacking text and creating structure, there's no CSS yet.
How I work in the browser is probably the most idiosyncratic part of my workflow. I've written a bit before about how I work with [plain text files and Pandoc to generate live HTML mockups](https://longhandpixels.net/blog/2014/02/work-smarter-plain-text-workflow#tool-2-plain-text). I then serve those mockups with a simple webserver, which I think is the [easiest way to get started "designing in the browser"](https://longhandpixels.net/blog/2013/11/easiest-way-get-started-designing-browser). From there I start editing and refining my mockups directly in the browser, using tools like the Chrome or [Firefox Developer Tools](https://longhandpixels.net/blog/2014/02/live-editing-sass-firefox-vim-keybindings).
It's worth pointing out that this process of sketching, wireframing, outlining user flows and building mockups in the browser is not all that different from what I've always done, responsive or otherwise, but there is one major difference -- responsive design requires a more circular flow.
In other words this is not a straight linear progression from sketch to wireframe live demo. It's more like a series of loops, something like: look at the content, sketch out basic ideas, create a wireframe, consider user flows, go back to content, rearrange slightly, tweak wireframe, create mockups, revisit user flows, re-tweak wireframe and so on.
## Rinse and Repeat
Once I've got a basic live site served up from a local folder, with at least one version of all the different pages the site is likely to have, the next step is to start doing all the things that make up building a responsive site. For me that means starting with my small screen layout, which is also typically the least capable device I'm supporting, and then working my way up the line. I create a basic mobile layout and then start stretching it until it looks like crap. I mark that as a breakpoint and head back to my text editor to start a new media query. Then I rinse and repeat with all the various pages until everything has been handled.
This will be ported over to template files at some point. This mockup process is still very loose and experimental and I shift back and forth between text editor and Firefox/Chrome, experimenting to see what makes the most sense.
This essentially begins the looping workflow I talked about above -- iterating through various pages, encountering issues and solving them, whether that's something I do myself or something slightly more structured when I'm working with a team.
One of the advantages of this workflow is the fact that you can take a live mockup to the client. In my experience this is usually incredibly helpful. It allows the client to interact with a mockup and see where the problems are before the site is in a more finalized form.
## Conclusion and Further Reading.
As I wrote at the start of this piece, there is no one size fits all responsive design workflow. That said I think it is helpful to distill the basics down to these three general principles:
* Start with content (when possible)
* Work with code directly as much as possible -- test everything in the browser.
* Iterate.
{^ .list--indented }
If you'd like more details on how I do all that and the tools I use be sure to look at my previous post on my [plain-text based workflow](). You might also want to pick up a copy of my book which has over 100 pages and dozens of videos devoted to various tools and [responsive design workflows](https://longhandpixels.net/books/responsive-web-design).
|
