Responsive UX: Taking Responsive Design a Step Further
For the last year, the concept of responsive design has been a hot, hot topic in the design and front-end community. With the rapid growth of smart phones and tablets, websites must now accommodate an array of gizmos, and responsive design offers an attractive solution: build a single site that’s capable of responding to device attributes like screen size and orientation in order to present the user with an experience customized for their device.
In practice, responsive design is focused primarily on screen size. You establish a set of screen types (mobile, iPad, small desktop, large desktop) and use CSS3 Media Queries to target different styles. What you end up with is a single layout that can adapt itself on the fly to a range of devices.
But are there things besides screen size we can respond to and things besides layout that we can modify?
Most designers and anyone who works in UX should be familiar with the idea of user personas. By grouping user goals and behavior into defined types (personas), designers can home in on and optimize for predicted user needs. This concept of establishing a set of user types is not unlike the concept of establishing standard screen types in responsive design.
From what I’ve read, the UX literature is rich with instruction on how to define user personas and how to present them to the business. But I’ve seen very little on implementation, on what you’re actually supposed to do with the personas. Often it seems the persona definitions do not make the leap from the research phase to the design phase and we end up with one-size-fits-all sites.
Responsive UX and Personas as Visit Types
To respond on the web, we need some sort of indicator and we need a means of detection. Responsive design achieves the former with screen size and the latter with media queries. Unfortunately/Fortunately, we don’t have a means of directly detecting user demographics or personal goals.
What we do have is the ability to identify the traffic source for each visitor, either through HTTP referrer or URL query parameters. This information can tell us a lot about what individual users are looking for. It can help us create a user experience that responds to specific user needs.
Note that we gain a few things by basing our user type definitions on the visit. First and foremost, we have information about the user we can actually act on. Secondly, we can allow for the fact that the same user can visit the same site multiple times with different goals. Example: when I visit the New York Times website Sunday afternoon on my iPad I’m a different user than when I visit it in the office Monday morning via a Google search.
So what are some of the things we can infer about a visit from the traffic source? What sort of “visit types” can we identify?
- General Search Traffic
Users on a mission, with a specific, stated goal.
- Branded Search Traffic
Users seeking out the brand (e.g., users searching for “The Economist”). On media sites, Branded traffic visitors tend to demonstrate unique behavior patterns. More pages per visit (depth), more time on site (engagement), and more visits per visitor (loyalty).
- Social Media Referring Traffic
Users arriving from Twitter, Facebook, LinkedIn, etc. This may not tell us much about the user’s goals for the visit but it does give us useful information about the user.
- Email Newsletter Traffic
Visits by regular subscribers from a known source.
These are just some of the possible types we could define. The overall idea is to extract whatever information we can from the traffic source to try and identify anonymous traffic.
The notion of parsing the referrer and displaying some sort of custom welcome message is nothing new. You see it sometimes with search traffic, where a site you find through search results will echo back the phrase you searched for. But in most of the cases I’ve seen, it’s done as a gimmick, an effect.
What I’m proposing is a systematic approach that classifies anonymous traffic into types and then customizes the user experience for each type in order to help users achieve their goals.
To be clear, I’m not suggesting that a user arriving via Google should get an entirely different experience than a user coming from Twitter. What I have in mind are subtle optimizations, things users may not necessarily notice.
Both of these examples are imagined in the context of a site that produces editorial content, a “media site”. While I can see these concepts applied to a range of sites, I think content-heavy sites are the most relevant and the ones that would gain the most from these extra efforts.
A user who finds your site through Google is, generally speaking, in pursuit of a specific goal and is likely to face a decision fork shortly after arrival. Either (a) he found what he was looking for and is ready to move on to something else, or (b) he did not find what he was looking for and has to continue his search, mostly likely by going back to Google.
Of the two scenarios, (b) is the easier one to optimize for because the user’s goal, which he has already exposed, has not changed. At that point your goal is to encourage him to continue his search not on Google but on your site. Maybe you have 20 articles on the subject and our user just happened to stumble upon the wrong one.
To address this we could build a module whose sole purpose is to extend a search. It could pluck out the inbound search keywords and offer a link to re-execute the search on our site. It could offer links to list pages associated with whatever topics or terms the article is tagged with. And maybe it includes a social element, links to recent comments or forum discussion around the keywords.
We’d place this in a prominent spot — top of the sidebar — and it would only display for users arriving via search. And we could filter our branded search traffic, perhaps presenting those users with a different custom module.
Some of the sites I work with see a large percentage of their traffic come from email newsletters. These are daily or weekly newsletters that contain between 5 and 10 stories each. Given the volume of visits credited to this particular traffic source, it’s a perfect visit case to optimize. Even a slight improvement could yield significant increases in key metrics.
As it is now, a user clicks on a story in an email and ends up on the site. If he wants to read another article from the newsletter, he has to go back to his email client and click through to the site again. Wouldn’t it be better if we could offer the user a list of the newsletter’s articles directly on the article page?
In this case we could build a module that displays a mini table of contents next to the article, giving the user one-click access to the entire contents of the newsletter. To ensure that only users arriving via the email — users for whom the newsletter collection is meaningful — would see it, we could trigger the module by inserting a unique query parameter in all of the email URLs.
Again, the purpose of this strategy is to better serve anonymous visitors by trying to derive what we can about their motives. If your site is based on membership or if you’re tracking behavior for behavioral targeting, you may have other and more reliable data to work with.
At a higher level, this is just about being as responsive as possible, being responsive to any information we can get our hands on. I’m not sure what you call it — Responsive UX is the only thing that comes to mind — but as long as we’re acting on meaningful information and as long as the effort required to respond is practical, I think we’re doing both our users and ourselves a service.
Over the next few months I’m planning to put some of these ideas into practice. The first step is to test one or two implementations to measure the impact. If results are positive, the next steps would be to establish a set of visit types, define custom opportunities for each, and work out the technical side to make sure we have clean, standard logic for detecting and routing the visits. I’ll be sure to write a follow-up post once the results are in.