"Responsive design"

I have just been asked for my view on responsive design, and whether it's the appropriate term to be using in discussions with clients. We are, amusingly yet unsurprisingly, a profession that spends a lot of time on definitions, perhaps too long...but the reality is that there are people with little technical knowledge but a lot of wallet, and they need to know if their boxes are being ticked. Encompassing definitions both help and hinder this.

Take "Responsive Design". Like "HTML5" which actually refers to modern web technologies, encompassing (but not limited to) javascript and CSS3 techniques, "Responsive Design" is not something we talk about in it's literal meaning, but its grouping of a set of techniques and ideals to deliver the right content in the right environment at the right time. Essentially, we usually use the term when talking about a service we are offering as part of a build, not as a technique. You can argue until the cows go home about whether someone's work involves "responsive design" or if it's just adaptive, or neither(!), and maybe you'll feel clever for a little while at nailing the specifics, but it is ultimately a futile exercise.

The problems with these definitions come when we're trying to sell this "service" to others, what they expect from it, and what we think they want when they ask for it. The customer doesn't care about what set of work practices you've used, and what you choose to call them, they only care that their product/system works.

Getting confused

Maybe you have heard this recently...

I want our new site to be responsive, can you use responsive design?

Or perhaps the client is taking your lead instead...

We are going to create a new site for you, and use the latest responsive design techniques

Leaving it like this is fraught with danger. How much do they really know about the techniques involved? Are they aware that "responsive design" as a service we are selling could be more than just making the text size go bigger, and the width go smaller, when you view the page on a mobile? When they ask for "responsive design" as a service, are we going to be quick to assume that they only want this and not a wider strategy for delivering their content on multiple devices in the best way for the customer?

The key to avoiding this is, obviously, to not simply rest on perceived definitions. Even if you think your definition is right, it doesn't mean others have the same views.

What does a "responsive design" service encompass?

It's actually made up of 4 distinct areas of practice which I would simply call good system design.

1. Content strategy design
2. Contextual design
3. Accessibile design
4. Responsive design

Content Strategy Design

For me the first thing that allows your system to be responsive is your content strategy. When you're putting something on your system, are you aware of it's limitations in different environments and different devices? Can it easily be taken to be used in a text message if appropriate as it can be to be put on a website for large desktop users?

Take the humble image. Most people will just upload a single image to put on a page. However is this image ready for use in high resolution devices? What about on pages where there is an abundance of space due to large window sizes? How is the meta data for that image stored so that it can be used in a text message if needs be?

Then there is the (text/html) content itself. While I would advocate simply having short and sweet content for each area of the system you're populating, there may be additional supplementary content that can enhance the current view. Without the right information architecture, and the right mentality behind adding content in a reusable manner, you may well find that any of your attempts at layout alteration, or alternate designs for alternate devices, will just be impossible.

For example: your standard Wordpress site allows users to dump their content in one big text box. It tends to do rather well in compartmentalizing some other content...you can upload a "thumbnail" or featured image, and you can associate custom content in a "key = value" way, but the default and prominent way of adding information is to use the big area for it all. This leads to pages that are unresponsive to changes in the size of the browser. Wordpress is a blunt instrument in the world of content management, though it is a model followed and preceded by many, but it highlights that sometimes we constrain our ability to be "responsive" the moment we choose our delivery system.

If we're being responsive we need to have the practices in place to use our content, and link our content together, in dynamic ways.

Contextual Design

You may have hit a website that looks very different on your phone, with a big link saying "view our main site" underneath. When this is done properly, it is contextual design in action, at it's simplest. While the methods of getting there are a subject of debate (browser sniffing, OMG!), the idea that what you will want to see in one context is different from another is important in your system being "responsive".

Look at an app like TripAdvisor, versus their website. The system is tailored around finding and making reviews, and at first glance the app isn't too different. However look a bit closer and you'll see that on the desktop website tripadvisor has a feeling of a system ready to help you plan a trip. It has prominent options to book flights, hotels, etc. It also lists everything in order of just how well others have rated it.

The app takes a different approach, still you look for reviews but the trip planning takes a back seat. Your current location is the default search choice, and everything is ranked by how far away it is from you now. Go in to details about a specific place and a prominent call to action is a tool to literally point you in the direction of the location and tell you how far you are away.

TripAdvisor have recognised that while everything is driven off of the same content, what content is relevant, and how you interact with the content depends on your situation, or context. Part of being "responsive" is understanding when simply amending the layout isn't enough, and that a different experience has to be offered. This doesn't mean abandoning the same functionality, just realigning priorities.

If we're being responsive, then we have to react to the environment that we know, or can reasonably assume, people reside in at the time they access the system.

Accessibile Design

Sometimes overlooked, but accessibility design may be one of the most important and ethical aspects of our design that we have to consider when thinking "responsively". Of course this means ensuring your system is navigable by those with sight issues, but it also means catering for those that have problem with their motor skills, or have cognitive disabilities.

There is, however, another area of accessibility...and that is catering for the disability of technological stagnation. Perhaps it could be described as legacy design, it is the practice of "progressive enhancement" that ensures that even those stuck on old computers, with old browsers, are able to get to the core experience or understanding of your system.

If we're being responsive, then we have to be responsive to the physical, mental and technological situation people are faced with.

Responsive Design

Finally there is the aspect that most will be familiar with, the actual layout on the page. Don't fight about whether it's "adaptive" or "responsive", these are just words. The only thing that matters is that your page works, regardless of what the size of the browser is, regardless of the resolution of the screen. If someone wants to do this by designing "steps" of layouts then that is ok, if someone wants to do it all be being fluid, that's also ok. The main thing is that the experience is going to be nice for the customer to use.

If this means hiding content that is useful on a desktop sized site, do it, the experience is key...just remember that load times and resource usage are just as important factors in someone's experience of your system as how it looks.

If we're being responsive, then the way the system looks has to be great in a way that never suggests "I should be viewing this on a different device/in a different browser size".

Edit: I've been asked a few times on Twitter about this, I would generally tend towards a fluid design thanks to the sheer number of resolutions and screen widths that can create a disjointed experience, or present wasted space. However within this fluid design you invariably need to use adaptive techniques to move elements around, hide elements, remove your grid structure, etc. This is why I say they are both part of the same parcel.

The caveats

Development is time and money, at the end of the day, and it's down to you to work out what is worth that time and money, and what isn't. If you know that you're only designing an iPhone app then considering the technological limitations of IE7 doesn't really factor. If you know that your site is one that doesn't have any IE6 users then feel free to severely limit the time you spend making it look perfect.

It's this reason why you need to be so careful with understanding what your client means when they bring the subject up, or that they understand what you mean when you bring it up. The difference in the length of time it can take to complete a project between the activity of simply adding some media queries in to a website template, and fully considering the design using all the elements above, is huge.

Stay flexible

I would suggest you work as close as possible to fulfill the above practices, whatever you want to call them yourself, the result will be a system that is responsive to future demands too. You may think that right now your system is constrained by certain facts, but facts can change...and boy can they change fast! Your iPhone only app can suddenly turn in to a web app as the client gets new information from their marketing teams, your user base can change away from the demographics that you tested your UX plans against (you did do some UX design too, right?)

If your system is inflexible to future change, if it isn't scalable, then you are creating a world of hurt for either yourself or your client at some point in the future. Follow good responsive design practices and you'll find that revisions to your system will be a breeze; making changes will become an act of bolting on new functionality, or simple tweaks to a template, instead of having to gut the system and start again!

This is what your client needs to understand when you start talking about responsive design, that you want to make a system that is responsive to variety in the marketplace now, to diversity of customers, and responsive to changes therein in the (near) future too.