Availability in the Cross-Channel User Experience

by Nielsen Norman Group on March 16, 2014

Summary: Don’t limit common activities to a few channels. Identify and support users’ top tasks on all channels and strive to make secondary tasks available.

Users can interact with an organization through a variety of channels, and they may choose one channel over another due to preference or convenience at any given time. For this reason, we can’t limit certain tasks and activities to specific channels. Instead, we must assume that users might want to complete top tasks on any channel and we must make these common activities available on all channels.

Our user research on Cross-Channel UX identified 4 key elements of a usable cross-channel experience:

This article discusses why availability—that is, supporting user tasks across channels—is important for cross-channel user experience.

The Importance of Availability

Users expect to be able to complete a desired task in the channel of their choice. When they reach a dead end, they become frustrated.

When a task can’t be completed on the preferred channel, users must move to another channel. Switching channels is time consuming and inconvenient. (This assumes that users bother trying another channel beyond their initial preference. Sometimes users might make the erroneous assumption that “if it doesn’t work in channel A, it’s not going to work in channel B either.”)

If the channel they shift to provides a different experience than previous interactions with the organization, users must complete the task using an unfamiliar design. This lack of continuity creates unnecessary work for users and damages the brand.

Identifying and Accommodating Users’ Top Tasks

In order to determine the common tasks that need omnichannel support, organizations must invest in user research. Both qualitative (field research, usability testing, focus groups) and quantitative user research (web analytics, conversion rates, etc.) allow designers to identify what people typically do (and don’t do) in each channel.

Quantitative research provides insight on what people do, but it doesn’t help researchers understand why they do it or what they want to do but aren’t able to because the channel does not support the task. Qualitative research will answer these questions.

For example, quantitative research may tell you how many people download a smartphone app and log in to their account. However, quantitative research won’t tell you that some people don’t log in to the app, because they can’t remember their usernames and passwords, and they cannot recover or reset their credentials within the app.

Qualitative research, such as a field study, a diary study, or even a lab-based usability study can give designers this insight. (Indeed, we observe forgotten passwords or other login info in almost all of our usability testing sessions.) Thus, there’s no doubt that password recovery is a common task on all channels.

As shown below, the Spotify mobile app doesn’t offer username- and password-recovery functionality. The only way to recover or reset a Spotify password is to go to the website or use the desktop or tablet application. In contrast, the American Express mobile app allows users to recover forgotten login details by selecting the Forgot User ID and Password link below the login fields.

Recovering a username or password is a common task for any site or service. The American Express mobile app supports this task, but the Spotify app does not—requiring users to turn to a different channel.

As another example, Netflix does not allow users to access their DVD queue within the tablet or mobile app. Instead, users must go to the website. Users likely want to manage their queue from any channel, so limiting this activity to the website restricts users from engaging with the service on the channel of their choice.

Common Tasks Aren’t Supported On All Channels

There are times when it does not make sense to allow users to complete every common task on every channel. In such instances, prioritization is important to ensure that users have experience appropriate for the channel. There are two main reasons why all common tasks may not be supported on every channel:

  1. The experience would be severely degraded. Each channel has strengths and weaknesses, and the experience should be optimized for the channel. Some interactions are too complex for some channels. For example, allowing users to search listings within the smartwatch eBay app would be too cumbersome—the interaction cost would be too high. This interaction is more suitable for a larger screen.
  2. It’s a top task on some channels, but not all channels. Some activities are typically completed on specific channels, and users don’t need the tasks supported or prioritized on all channels.

The issues listed above should be thoughtfully considered in a discussion about which tasks to support on which channels. Don’t take these issues as an excuse for not providing functionality on a channel. Don’t say “it’s too hard” to support an activity in order to avoid including it. Let’s face it: Allowing users to complete any task on any channel is a lot of work. It’s expensive to develop and support, and it’s challenging to get internal buy-in and cooperation.

It is important that teams understand the impact on the experience when tasks aren’t available and that they help users through the transition to another channel that does support the desired activity.

Transitioning Users to Another Channel For a Better Experience

As discussed above, some tasks should not be  supported on a channel because the experience would be very poor. If the interaction would be too difficult or would require too much user effort, users should be given the choice to smoothly shift to a channel better suited for the task.

For example, it would be a lot of work to read an email on a smartwatch. (And research has shown that comprehension rates suffer on smaller screens.) It makes more sense to shift this task to a larger screen. The Samsung smartwatch email app allows users to read the subject line and the first few words of the email, and then users can touch a button on the screen to continue reading the message on the associated phone.

The email app on the Samsung smartwatch displays the subject line and a button to view the rest of the email on the associated device.

Supporting Tasks that Are Common on Other Channels

Some activities aren’t carried out on every channel: they may only be typically done on just a few channels. In these instances, it’s essential to provide a transition to the channel that supports those activities.

For example, people using Uber (an on-demand car service) can request to be picked up via the mobile app, the mobile website, or by text message, but not through Uber’s desktop site. Presumably Uber has done some user research and has determined that people use its service when they are on the go. However, the desktop site provides links to download the app, navigate to the mobile site, or send a text message to request a ride, thus supporting a transition to these different channels.

Uber’s desktop site doesn’t support the task of requesting a ride, because people aren’t usually in front of a laptop or computer when they need to get from one destination to another. (This page could be improved by including information on where to send a text message.)

In the Uber example, users can navigate to the appropriate app store to download the app. While this is a nice way to transition people to a different channel, Audiobooks.com has designed a smoother experience by advertising its mobile app on the desktop website. The site allows users to email a link to the app to themselves, making it easier to quickly access the app in an app store.. Rather than forcing the user to start from scratch from a mobile device, the site provides a shortcut for users. Once they get the email on their smartphone, they are only required to click twice (once in the email and once within the app store) to get the app.

Audiobooks.com offers users the option to email themselves a link to download the mobile app. Users can click the download link within the smartphone email app(instead of searching in an app store) to quickly download the app on their phone.

Secondary and Lower-Priority Tasks

Lower-priority tasks are those activities that users complete within a channel, but not very often. Organizations should work towards supporting these secondary tasks. In the meantime, if users attempt to complete the task on an unsupported channel, offer information about the channel where they can finish the activity.

For example, a user engaged with a chat representative on the Rite Aid website when he needed to update the phone number associated with his rewards account. The chat agent could not complete his request, but she provided a toll-free phone number so the user could reach out to a customer-support representative that could update his account. This is a good fallback solution until this activity will be supported via online chat. Even better, the chat representative could have provided a URL to the account section of the site so the user could make the change himself.

Updating account information is likely a secondary or lower-priority task for Rite Aid users who engage with the organization through chat. Although this task wasn’t supported on the chat channel, users were directed to a different channel (phone or website) where they could complete it.

The Rite Aid chat agent couldn’t change the phone number associated with a customer’s rewards account, but she provided a toll-free number so the user could access someone who could.

Call Attention to New Features or Functionality If They Support Common Tasks

When new features or functionality that support a common task are first launched, be sure to call attention to them. If users can now complete a top task on a channel, an email or homepage promotion might be appropriate. Or, if users can now complete a lower-priority task on a channel, a more subtle announcement is suitable.

For example, when JetBlue enabled mobile customers to pull up their boarding pass on their phone (instead of printing the pass or visiting the ticket counter), the company sent out an email. This is a top task that users would like to complete using their mobile phones, so it was appropriate to send an announcement via email.

A JetBlue email promoted a new feature available via the mobile application: boarding passes.

On the other hand, when Yelp allowed users to write reviews via its mobile app, it announced this new feature by showing a message when mobile-app users viewed the details of a business. This is appropriate, because writing reviews is likely a “nice to have” feature that supports a lower-priority task for most users. (Many more people read reviews than write reviews.) Top tasks would be looking at average review ratings and reading rating details, which users can also do within the app.

The Yelp app mentioned a new feature when a user viewed details about a nearby Jamba Juice.

Available: 1 of 4 Recommended Cross-Channel Characteristics

As people continue to engage with a multitude of channels and devices, it’s important that companies don’t inconvenience them by limiting what they can do within each channel. Top tasks should be supported across all channels, and organizations should work towards accommodating secondary or lower-priority activities. In the meantime, provide seamless transitions to other channels when users attempt a task within a channel that isn’t optimal or doesn’t support the activity.

In addition to being available, cross-channel experiences must be consistent, seamless and optimized for the channel. Our full day course on Omnichannel Journeys and Customer Experience discusses these recommended characteristics further.

Share this article: Twitter | LinkedIn | Google+ | Email