Responsive Web Design Is Not a Feature

Do you remember the “Web 2.0 days?” I know that you have tried hard to erase that from your memory, but it was still a critical time in the maturation of our industry. Beyond the empty buzz words, it encapsulated an effort to build web applications and not just web sites. The “Web 2.0” days were exciting for a while, but eventually like all grass-roots ideas, people who do not quite understand them get a hold of them and contort them. It started with teams asking how to leverage technologies like Ajax and other graphic design trends to build amazing experiences. Then I noticed clients would come and put in requirements like: “Site needs to have a ‘Web 2.0 approach’.” All of the sudden, our once exciting changes were being twisted by a hollow simplification. All of the sudden, “Web 2.0” site catalogs sprung up that showed how much of a caricature of itself it had become.

As the title gives away, I think the same is beginning to happen to responsive web design. What I want to lay out for you is a thesis and a warning as well as some steps to mitigate this transformation. The good news is that education and clarity can cure many errors in our industry, and that is what I want to leave you with today.

The Definition Problem

Like the aforementioned “Web 2.0,” responsive web design (RWD) is going through a bit of an identity crisis. When Ethan Marcotte forever codified a technical definition of RWD, he forever changed our industry. I am grateful for the work Ethan did years ago, but now it is clear that the revolution caused by the technical aspects of RWD has made the previous technical definition alone insufficient (for the record, I agree with Ethan that without those components I prefer calling it an “adaptive layout”).

RWD certainly does include flexible media and media queries and is best used with a fluid grid. The problem is that this definition has to include at least this but now needs much more. Think of the questions that RWD has forced us to ask:

• How do I need to restructure my entire design approach around RWD?
• Should I continue making design comps the way we have for years?
• Do we need a more “design system” approach to projects?
• How do we communicate the value proposition of RWD in a way that’s clear?

These questions are not small questions—they are a fundamental reframing of our industry, and I’m grateful that it is happening. The problem is that if we continue to hold onto a purely technical definition of RWD it fails to encapsulate the myriad of other benefits in disciplines like content strategy, information architecture, graphic design, and the like. In fact, I would go so far to say that if someone came to me and said, “my site has fluid grids, media queries, and flexible media,” I’d respond with, “that’s cool, but so what?” I want to know how these technical approaches have shaped the entire creation of the site, not just that the pages responds to media queries.  Lyza Danger Gardner and Jason Grigsby have helpful discussions of the topic, and both of them gravitate to defining RWD as characteristics of the implementation. For me, it needs a bit more to include process implications.

Karen McGrane wrote a wonderful article where she addresses the insufficiency of RWD alone to make true change:

So how should we define RWD? That’s beyond the scope of our inquiry here, and I’m sure there are much smarter people with better answers to that question. I will say it needs both a process and a technical component that then encapsulates implementation characteristics (device independence, future friendly, accessible, etc.). Perhaps a single definition of such a massive idea cannot be summarized in such a succinct way as we would like. This puts an even greater need for comprehensive education.

Based on this definition problem, I want to demonstrate how its confusion can affect us as designers. If we have a hard time defining RWD, what hope does a marketing or sales person completely abstracted from this understanding have? Let’s look at two major areas where I see the “Web 2.0” error I mentioned above creeping into our industry for both the product and the consulting areas of our industry concerning RWD.

Responsive Web Design as a Product Selling Point

I’m starting to see more and more products mentioning as a feature that it was designed “responsively.” Often times, it ends there. You might occasionally see something like, “The [product] was designed responsively to look great on mobile devices!” Well yes, that is certainly one benefit but not the core one. As I alluded to earlier, I think the biggest benefits of RWD and sister approaches like mobile-first design are changes in content strategy, information architecture, process, and so on. Certainly device independence is important, but it is not the only or even most important benefit. A “device agnostic” site with terrible content and wayfinding is still a terrible site.

I’m not going to call out any particular product, but let’s just look at an area with which several of you may be familiar with: “Pro” themes. Just go to a site like Theme Forest and you can filter on “responsive.” A lot of these themes list RWD as a bullet point feature. Beyond the fact that most of these theme’s technical implementation of RWD is laughable at best, it highlights the problem that people are looking to “check” a requirements box.

If you’re thinking ahead of me about the value of selling benefits over features, you would be right. I am much more interested in how your product used RWD to solve problems and provide tangible benefits. How was your product’s content strategy altered by a responsive (and hopefully mobile-first) approach? How did these technical advances change the way you thought about design? Answers to these questions are glaringly absent, and I think it’s because many of them use and think about RWD in a myopic way.

Responsive Web Design as a Project Plan Item

I personally do not spend much time in a pure product design mode (in the external selling sense). The vast majority of the time I spend working is for clients on specific projects. I have noticed that recently more and more clients are coming into projects with requirements like, “the intranet must be responsive.” Well, first of all, doing requirements definition like that completely skirts the role of proper UX research where we can frame a problem and generate solutions. Clients are buying into the thought that RWD handles the “mobile problem.” More often than not, these clients talk about “mobile” in device specific terms, and this is where you get dreaded and completely misguided requirements like “the site must look good on iPhones and iPads.” No wonder many designers end up with 320px/768px media query breakpoints (the new iPhones show the folly of that approach).

I also now get asked questions like this: “How long will it take to make this page/site responsive?” That is symptomatic of an understanding of RWD that misunderstands the benefits I mentioned earlier in disciplines like content strategy. Worse yet, often times I’m forced to make these estimates long before we even understand what, if any, problem RWD seeks to solve for the client!

If you are in a consulting company and your project plans have RWD as a line item—you’re doing it wrong. It’s better to structure your plan to educate clients about how RWD changes everything that you do. Sure, there should be time allotted for implementing the technical aspects of RWD, but the problem is when we conflate its importance to equal the total value of RWD.

Mitigating the Problem

Perhaps at this point you think I am right on point, or I have made a mountain out of a molehill. Regardless of your stance on that, we can agree that the only way to solve this problem (and many like it) is through clear, intentional communication with clients and our product base.

If you are developing products, be clear just how RWD changed everything about your approach. I’m not against saying that your site has “device independence” (as long as you avoid those dreaded device specific media queries), just don’t stop there. Be clear in how your products brings benefits for clients in a holistic way. This is a far more convincing and effective way to communicate the RWD value proposition for your client.

If you are in consulting, the same challenge remains, but you have to handle it a bit more proactively. You have to clearly communicate how RWD will change the entire process. At first, clients show hesitation about content-priority wireframes, rapid prototyping, and creating design systems; but if you are clear how these deliver value and connect the dots and not allow them to exist in isolation your client will be convinced by your intentionality and precision.

Another challenge exists for designers in consulting firms: your non-technical management. Most of the time these are the people that are out selling the firm, and if they talk about RWD in a different way than you did it will appear disjointed. In addition to educating your clients, now there is an additional need to educate your management to sell RWD effectively. There are many ways to do this: provide clear write ups of how you want to talk about and sell RWD, become an active part of the sales process, and regularly engage your management in education sessions.

Conclusion

I hope the contents of the article help to think about how we enter into the future maturation of our industry. I know the opinions might not resonate with every designer, but my hope in writing is that we become more committed to clearly communicating what we provide regardless of the methodology. We all care about the future of our industry, and we must continue to be diligent about educating each other and also those outside of our speciality.