Introduction: the responsive design process

Notes from Steve Fishers talk on responsive design process, at the Future of Web Design 2012 conference. Four key takeaways:

• the web is not fixed width
• mobile is not a rushed context
• clarify the why
• discover, design, develop, deploy.

The web is not fixed width

The web is not fixed width. That's not to say don't use fixed sizes, just remember that the medium isn't fixed. Even the iPhone for example; you may think you're working with 320px, but change the orientation and you've just changed width.

Mobile is not a rushed context

Mobile is not a rushed context. Assumptions can't be made about user intentions or location. There's no denying we see less on a smaller screen. So what? Everyone still needs to access all the information.

Clarify the why

The golden circle is an approach that will drive a designer or developer to deliver higher quality, robust and innovative solutions over and over. The golden circle has three parts:

• How
• What
• Why

It doesn't matter what you do, it matters why you do it. Everyone knows the what. Most people know the how¹. Not a lot of people know the why…

If you can concentrate on working out the why, you'll be a lot more successful in the what and how. The why is the question. The design is the answer.

Apple are a classic example of this. People are so absorbed in why they do what they do, they are happy to pay Apple prices.

¹I love this way of thinking but it got me thinking… Do most people attempting responsive know the why, but not the how or what? AKA, they acknowledge the multi device issue but struggle with optimised implimentations?

The responsive design process

Steve went into some detail about the 4 stages of his responsive design process:

1. Discover
2. Design
3. Develop
4. Deploy

Discover

Kickoff and project charter

Get to know your client and let them get to know you. Be fully informed. It's so important to understand who you are working with. If someone's not been involved at the kickoff, question their right to chime in with input at a later stage.

Project analysis

What are the business needs, personas, audience profiles? Get to know them.

IA and content strategy

Audit existing content for quality and quantity. Does your content do what it needs to do? Set about gathering content, use sitemaps to ensure you've got everything accounted for.

Search strategy

Look at page structures, URL naming conventions, meta data requirements, hierarchy. Everything you need to consider when building for an SEO'd site.

Strategic direction

All the info found in the discovery phase should now be brought together in one document, to be thought of like a project map. This should cover search, content, technical and creative strategies. This is the point when the full budget and scope should be set. This moment helps define the project. It prevents people coming in with a solution first; telling you what needs built, then constantly changing the requirements on the fly. Stakeholders shouldn't be coming in suggesting solutions. Problems should be discussed together.

Design

Note: it is only now that we look at the design phase. Look at all that planning that came first. Remember that, next time someone asks you for a mockup. It should also be noted don't worry about your toolkit (the actual quote was more like tools are bullshit). Use whatever tools suit you.

UX Sketches

Iterative process to create rough wireframes. It's fine to use paper sketches, but get into the browser quickly.

Page tables

Key to keeping content separate from presentation, page tables identify each content area in order of importance, with the most important messages to be conveyed in each content area. Content should never be dependant on layout to work effectively.

This is the why. This message is what informs the design. Stories are data with a soul. Data should be well structured, in manageable chunks.

Interaction design

In-browser prototyping. This stage allows for easy demonstration of what happens at set breakpoints.

Visual design

Branding, colour, typography, everything that's required for look and feel. Up to you if you choose PSDs or browser prototypes.

Styleguide and documentation

Styleguide that documents the design system as a reference, so the elements can be correctly implemented. Could take the form of a live, annotated prototype, even with code snippets if necessary.

Develop

Templating

It's down to business. You've got all the strategy, content, design and assets together, now you have to build it on HTML pages ready for testing. This is where your web standards come into play. Steve actually had this section down as "theme build" but I thought templating was a more appropriate heading.

CMS build

Your theme / template has to be ported onto a CMS, probably including the creation of lots of mini page modules.

Browser and device testing

Cross-browser / cross-device testing to check you're providing a coherent experience to many devices. Remember, not all browsers render HTML and CSS the same. This is OK. It's not about making it look near identical in every browser, it's about creating accessible journeys on all devices.

Deploy

Content migration

A website without content is a black hole of sadness. Define the scope of the content migration phase depending on the discovery / audit phases.

User acceptance testing

UAT helps confirm the objectives and requirements defined early in the project. It's like moving into a new house; this is the learning how everything works and getting comfortable with living here.

Documentation and training

Document things. Share processes. Understand how things will live in the system and write it down. Essentially a potential handover. Document all markup as well as admin functions.

Launch plan and release

Archive current website. Prepare new website for release. One last quality checklist. Go through a publication checklist, check meta data and title tags etc. Set up all analytics.

Start of operational plan

For many people the website would be alive in some form for a while now, but only now does the website really come to life on its own.

A responsive process is a responsible process

Responsive techniques can be tricky, but if we approach it content first the whole design can be simpler than what we're used to. Responsive is all about the content. It's about rethinking content creation, and getting unification from fragmentation.

The first website ever built is fluid, because the web has always been fluid. Make things easy for future devices, and accessible to all. Create once, publish everywhere. A responsive process is a responsible process.