The responsive design process

The web design process

This article gives one possible approach for designing responsive websites. It is not a technical document, and does not require knowledge of HTML, CSS, or any other programming or mark-up languages.

NOTE: This post was originally a document created for internal use at the design agency where I work and was intended for graphic designers as well as web designers.

Defining some terms

Fixed-width

This is a traditional web page. With fixed width sites it doesn’t matter what size screen or browser a visitor has, the site is always the same size (in pixels) as the design in our Photoshop file. If the screen isn’t big enough to fit the design in, the visitor has to scroll sideways. If the screen is huge, the design has empty space around it.

Adaptive

Adaptive design is based on top of fixed width designs. Instead of having one fixed-width design, there are multiple fixed-width designs for a single page. Normally these designs are split up based on the width of the browser, so there can be one fixed-width design for mobile, another for ipad, and another for a computer. Although they’re “multiple designs” they’re generally based on the same thing, just re-arranged to better suit a larger (or smaller) screen. In effect the website adapts to the size of the visitors screen/browser by automatically selecting a different fixed-width design to use.

Fluid

Instead of an element being a known and fixed size, it can stretch to fill any available space. But, only horizontally (this is a stretch, not a scale). Whole pages can be made of fluid elements, meaning the whole site becomes fluid. The layout doesn’t change.

Responsive

Combines Adaptive and Fluid techniques. In a responsive project there are a series of designs each of which is fluid - stretching up to a given point before switching to a different design or layout.

Mobile first

Is a way of managing the design and build process. The idea is to start by considering the simplest possible version (usually the mobile version, hence the name) and work up through larger and more complex designs only once a smaller one is complete. The advantage in terms of design is an emphasis on core content and design elements (typography and colours, then layout, etc). From a technical perspective this is quite essential, from a design perspective it’s less so.

Breakpoint

A breakpoint is the width at which a given design starts to look broken, and therefor at which point a new design should be applied.

What are we designing for?

Traditionally a website has been seen as something viewed on a ’standard’ computer. The size of a ’standard’ computer has changed over the years - we used to design at 640px width. Then most people got bigger screens and we decided 800px was better. Then it happened again and we went up to 1024px. Change continues to happen, but there is less and less a ’standard’ size. There never really was a ’standard’ - we as an industry just picked something that worked for most people, and let outliers fend for themselves ("you don’t have a big enough screen, your computer is too old").

Now we’re hitting problems where this ‘pick a standard size’ method won’t work well enough anymore. There is too much variety in the devices used to look at a website. Ignoring mobiles for a moment and looking just at ’standard’ computers; a lot of people have 24 or 27 inch screens and a 1024px wide design would fit onto that 27″ screen two and a half times. But similarly, a lot of people also use small laptops, some of which still max out at around 1024px wide. There isn’t an obvious majority using one specific size of computer.

The problem has continued to get worse, and now we have to deal with devices that can browse the net that are only 240px wide - new Android phones ship with screens that small but which can access the web. And there are a lot of people using phones to read websites. So, screen widths that people use to view a single website can vary from 240px up to 2560px. That’s a tenfold difference.

It’s been the case that web designers have largely ignored mobiles until recently, trusting to the device to zoom in and out like some sort of grotesque digital magnifying glass. We can’t continue to ignore those smaller screens because they are being used more and more. Recent studies have projected that as soon as 2015 more people will visit a website from a mobile phone than they will through a traditional computer. We’re now having to design websites that will work well on *all* devices that can access the web, we can no longer hedge our bets and get acceptable results.

Making sense of the web landscape

Clearly old-school fixed-width web designs are less and less suited to the web that exists today. They’re either far too small for people on large monitors or far too big for people on mobile phones. Fluid design’s help but are not enough, they can’t cope with a 10 fold stretch! And we can’t do Adaptive designs forever because there are more and more devices coming out all the time. If we wanted to address all the device sizes that people are using today we’d have to do fifty or more designs. And that’s if we assume the site is able to take up the whole screen, and isn’t stuck inside some application window that makes it slightly smaller - this is going to happen a lot.

This is where Responsive Design steps in. It combines adaptive and fluid techniques to help keep things sane. From a technical perspective the most useful solution is often to have a few “major” designs, each of which is fluid - stretching within reasonable ranges, before switching to a different design.

How do we approach the actual design?

It’s no longer a workable option to pick an arbitrary size in photoshop, mock-up a design, and hand it over to developers to code up. This process simply doesn’t work well enough, not even when we pick some sensible seeming canvas sizes to work from. It’s hard to think about the responsive properties of a design when you’re using an unresponsive canvas, and there are technical limitations that mean developers can’t re-arrange things arbitrarily. So, although each design might work individually, it may be impossible to get to one from the other. We have to test as we design.

Which means we need a new design process if we’re to carry on making quality websites.

Not all projects require a responsive approach, but given a responsive project a reasonable design process would be:

1. Get the content for the site
2. Sit with the developer to talk about your ideas. They will do the information architecture, as a navigable website;
   • This is just a super-simple un-designed site used to help planning
   • It has all the pages of the real site, linked to each other - you can navigate around
   • Each page has examples of the content that will be on there, but no real content or design
3. Do the normal design research, sketching, brainstorming and idea generation.
4. Using the IA site as your reference, start designing for the smallest resolution - a simple linear flow. Typography, colours, and non-layout design.
5. Hand this over to a web developer who will code it as a real site.
6. When the developer is finished, sit with them and test it on real devices; iPhones, Android, iPads, etc.
7. Fix any usability or design problems with the developer.
8. Re-size the browser window until the design is no longer acceptable. This is the breakpoint for your next design.
9. Tweak the design and layout for this new size. Do this with the developer.
10. Repeat the previous few steps until you’ve gone as large as the project needs.

As you can see, this process requires the designer and developer to work together right from the start. Coding has major impact on the design and visa-versa, the two are no longer separable and must be tested together to inform the next stage. As a guide, a responsive website typically consists of three or sometimes four designs. Remember that these aren’t really unique designs but modifications and expansions of smaller designs.

The key to designing for responsive websites is constant communication, as with any design - but it’s more crucial than ever with responsive designs.

Visuals, and addressing the client

Creating visuals is a key part of our normal design process, and it’s easy to feel that the responsive design process is a straight jacket leading to graphically boring designs heavily reliant on type. It doesn’t help that a lot of early responsive designs are good examples of exactly that. It doesn’t have to be. We just need to re-assess how we create visuals, and their role in the process. Maybe even their name, to help avoid confusion.

For the responsive design process, visuals are more like mood-boards (used in research) than they are blueprints (a schematic to build from) - visuals in responsive design are conceptual. So, maybe we should call the visuals we make in responsive designs “concepts”, to help keep our thinking straight. We can’t promise that a concept is practically build-able, but it’s still very useful to get some realistic ideas going. So in terms of design, it’s fine to do the usual research and photoshop experimentation, perhaps on some common design breakpoints. But don’t go into too much detail with regard to overall design. It’s worth getting ideas and visual themes, it’s worth thinking in terms of components and how those will look etc. But change is likely, and layout especially is likely to have to be different to any specific visual. So don’t get too attached to “the whole” at the concepts point.

The reality of working with clients throws another aspect into the mix: If the design is dependent on the build and the build is dependent on the design, how can we create visuals of the final product for the client to sign off? The truth is, we can’t create “visuals” as we’ve known them at all - it would be irresponsible to pretend that any graphic we delivered is a promise of how the site will look - to do that is bad for the client and bad for us. We have to change the process. The old workflow of: “get job > research > create visual > get sign off > build the visual” no longer works. But there is still a strong business need to show the client something - no client is going to feel comfortable not knowing how a site will look until it’s already being built.

So, we should show the concepts we’ve done as described above, but educate the client that these are not visuals, not set in stone. We don’t get sign-off for them, we use them as a communication tool to establish expectations without promising a final product’s look - in much the same way we do when presenting mood-boards at pitches. With responsive designs it’s even more critical than normal that we keep the client involved closely throughout the build, getting their feedback as we go.

External resources

Trent Walton has a very good and honest post about his reaction to Responsive Design, and his approach to websites that’s well worth reading.

Stephanie Rieger has a compelling post A plea for progressive-enhancement detailing the staggering numbers showing the shift in our industry, and how it’s vital we address it.

Entry Information

Posted:

Wed, 1st Feb 2012 at 15:02 UTC

Filed under:

• Web Development

Tags:

• best practices
• design
• responsive design
• web development