Adaptive/Responsive Web Design - Don't Neglect The Users

What is responsive Web design (RWD)? You don't need me to tell you--there are hundreds if not thousands of articles on the Web, not to mention a few books. I've personally read about twenty some odd articles on it, as well as books/booklets. So far, this is my favorite primer, although one of the more thorough and up to date pieces can be found in Smashing's Mobile Book. I don't need to tell you who coined the term, nor that it was coined in 2010, as seems to be the custom in any piece on the subject. ;)

I also don't need to tell you that we're at (possibly--let's hope) the peak of the hype cycle for responsive Web design. And in fact, my intent is to add a little reality and grounding to the conversation to help us get as quickly as possible to the "plateau of productivity." Perhaps more to the point, I hope to offer some advice by way of caveats and considerations in regards to how responsive Web design relates to interaction design and user experience (UX).

"Earth Calling RWD, Come Back Down Here, RWD!"
I'm certainly not the first to attempt this. Just in November, Carin van Vuuren told executives (they're the only ones who read Forbes, right??) about "The Trouble With Using 'Responsive Design'," and one of my preferred puissant pedagogues, Luke Wroblewski, has written extensively about his trials with RWD (note that was written quite some time ago, early on in the hype cycle).

RWD is just a relatively recent, clever implementation technique to address the old problem identified in Liquid Layout, a pattern first catalogued by Jenifer Tidwell in her seminal work on UI patterns, Designing Interfaces (1st Edition). This came out of her research at MIT that began in 1997. As you can see in the examples for the pattern (and elsewhere if you look), people have been responsively adapting their designs for a very long time.

So why the hype now? Well, again, the formula for RWD articles will explain to you that the pressing need is due to the proliferation of non-desktop devices. There is a lot of truth to that, especially as "mobile" Web becomes more important than desktop.

However, as the pattern examples referenced above illustrate, the need for such adaptation has been with us longer. Even one RWD piece I read frankly asserted that we've all been living under a consensual delusion that we could safely design for fixed form factors. We all know that it's not reality, even (or especially) on windowed desktops. Further, we've had mobile for quite some time now, and I remember working with the early builds of ASP.NET's rather advanced control adapter technology well before it was released in 2006.

That "adapter" terminology is apropos for what it was/is. You'll see some folks disambiguate between "adaptive" and "responsive" design by emphasizing the latter is more active--it happens on the client, so someone who resizes a browser window will see the changes immediately, on the fly, while "adaptive" means when the pattern is applied elsewhere (such as on the server as in the ASP.NET control adapters or the server-side components alluded to by LukeW's multi-device article referenced above).

RWD Is More About Technology and Budget, Less About Users and Design
This distinction between "adaptive" and "responsive" illustrates quite well a key caveat that we all should keep in mind: responsive Web design is not particularly concerned with users. It is more concerned with technical details and rather unimportant distinctions--I mean, like, does it really matter to people if a design updates its layout immediately as you resize a window? How many people are even going to do that? How many of your users even can--after all, it's not possible on most non-desktop devices, which is purportedly the catalyst for RWD.

No, RWD is, as said above, an implementation technique. The special sauce that Ethan Marcotte (doh! I said I wouldn't mention him!) brought to the table was not the idea of responsive/adaptive design but the peculiar combination of it applied to Web design using flexible grids, flexible images/videos, and CSS media queries.

Many electrons have flown through the intertubes about RWD, and it is currently the talk of the town in Web design circles. But we need to keep this key thing in mind. RWD does very little to keep us focused on the people using our designs, which is really at the core of what makes a design good or bad. In fact, if these numbers are any indication, the focus on RWD by designers fascinated with the power of media queries may actually be hurting rather than helping users on mobile devices.

Let me be clear: I am not suggesting that applying the Liquid Layout pattern is not helpful. Nor am I arguing that RWD is inherently flawed in any way. On the contrary, where RWD can be a big win for users is chiefly when it makes applying the Liquid Layout pattern feasible--when users would not otherwise get any optimization for their mode of accessing your content due to budget/resource constraints. And let's be honest--this budgetary consideration is probably more than anything the driving factor in RWD's popularity.

Admittedly, there is some user consideration involved in RWD, but it is a bare minimum kind of consideration--ensuring some basic layout optimization for various devices and potentially addressing the multiple URL issue. But that hardly justifies the hype and, more importantly, neglects or obscures more important design considerations that can be impacted by pre-selecting RWD as a baseline for your design efforts.

The Advice
And that is the problem with hype peaks like this one--people start from the solution as an assumed baseline. If you understand design patterns, you'll know that implementations should be customized to fit the context, and that the context should qualify whether or not the pattern is even applied. Please, don't just blindly apply RWD as a solution to your next project. Before you choose it as a solution:

• Learn about the challenges and trade offs first.
• Consider hybrid approaches that leverage both client and server-side.
• If you're designing an app (that is, your solution is activity oriented rather than content-consumption oriented--a.k.a., a "site"), consider if it is even appropriate at all, or if it wouldn't still be more appropriate to directly optimize for target devices or device classes (phones, tablets, TVs, desktops).
• Design mobile first, even if you're going with RWD.

Whatever you do, don't get so caught up with the hype or fascination with new implementation techniques such that you give more importance to them than to your actual users:

• Don't neglect design research, which helps you to know if RWD is the best solution.
• Don't neglect sketching, interaction prototyping, and testing with users first--to find the best design(s) for your known users, devices, and context.
• Don't fall into the trap of imagining that your design is "for anybody" so you have to design it "for everybody" on "every device," because this usually equates to designing it for you (the imagined, ambiguous user in your head) on your devices (whatever devices you happen to have access to).

This last caveat is perhaps the most dangerous siren to avoid in relation to RWD, because it sings to you so soothingly:

Come, dear designer. Stop thinking about specific devices. There are too many of them. You cannot possibly anticipate all of the devices that will access your content. Perhaps, you cannot even know your users.

Thus it beckons you to a kind of user agnosticism.

And if you start from thinking you can't know your users, then you easily fall into the we-shouldn't-even-try-to-know rut. And if you don't know your users because you didn't do research, then whom will you design for? And if you don't know whom to design for, then whom will you test your designs with? And if you don't know whom to test your designs with, then how will you know if it is a good design or not?

...

Ahh! Forget all that! This media query stuff is cool! RWD FTW!