Last month, we talked about the basics of the buzz-worthy industry trend, responsive design, and how fantastic it is. This month, after gads of discussing and brainstorming, we have an updated perspective on responsive design. Don’t get me wrong—it’s still fantastic. But it could be better. Here’s how.

Recapping Responsive
To recap from last month, responsive design basically just takes one uniform code on the back end and, using media queries, breakpoints, and fluid images, changes the layout of the interface to accommodate different screen sizes. It's really cool. It allows you to develop just one set of code for all form factors, and it lets you keep all the content from one form factor to the next indiscriminately.

Observe:

Where there are advantages, there will also be disadvantages. Responsive design is difficult, time-consuming, and costly. All valid concerns. But the major issue we've encountered is that responsive design has a tendency to disregard the goals of users as they pertain to different devices.

Revisiting Responsive
As we touched on in last month’s post, responsive design in its current state neglects the user’s device-specific goals. In layman’s terms, a user might—and often does—want to do different things on her desktop than she does on her smartphone.

Practically speaking, if I go to Gap.com on my desktop, I’m probably browsing for new jeans, and I’m probably buying them too. If I go to Gap.com on my smartphone, I’m likely trying to find the bricks-and-mortar store that’s closest to me, or access my store’s hours. In that case, I don’t want to sift through all of Gap.com’s content to get to the store locator on my smartphone; I want my smartphone to assume the store locator is one of my main goals, and make that a priority over other things like browsing for jeans.

So, what’s the solution? How do we reconcile the awesomeness of responsive design with the importance of user goals? Well, we’ve been brainstorming, and what we’ve come up with is behavior-driven responsive design. It’s still responsive design, but it’s based on what the user needs to accomplish rather than screen size.

What you see in the image above is an oversimplification of the ideas we’ve been throwing around here at Design For Use. The top part of the image (Site Content) is really the back end of your site. It contains all the content—whether it’s images, articles, functionality, etcetera—as well as all the code, including responsive design’s trademark media queries and breakpoints. The difference here lies in the checkboxes. These checkboxes essentially allow you to cherry-pick which content belongs on which devices—all based on screen size and, ultimately, the user's goal.

The bottom part of the image (User Interface) shows how the responsive design displays based on the conditions set up in the back end. To perpetuate the Gap.com example, imagine Content Item #1 is Gap.com’s search bar, while Content Item #4 is a link to Gap Inc’s “About Us” page. The search bar is going to be a major user goal across the board, no matter which device you’re on. Checking out Gap Inc’s “About Us” page, however, is likely going to be such a low priority or edge case for a smartphone user that it shouldn’t be there to disrupt the user experience at all.

Bottom Line

Understanding user needs, goals, and behaviors is crucial to executing a successful site/app/software/system. We can't neglect the user experience in favor of a shiny new product that is, admittedly, very cool. Instead, we should figure out how to make that shiny new product even cooler by integrating it with the user experience. Responsive design is almost there, but it has to work harder.

Read "Separate Mobile Website Vs. Responsive Website" by Smashing Magazine's Brad Frost for another perspective.

Published by Design For Use.