3 Important Usability Challenges for Designing Web Apps

Thanks to Marco Dini for the Italian translation of this article.

A benefit of joining the Hertz #1 Gold Club is a simplified experience for reserving a rental car. As a member, the web site remembers your billing information, frequent flyer preferences, and frequent cities you travel to, eliminating time consuming steps from the reservation system. This enhances customer loyalty, since busy travelers can make a reservation in less than a minute.

Unfortunately, our testing shows club members coming to the site to book a reservation frequently miss the optimized experience. When they are focused on their potential reservation, such as getting a quick price quote, they are very tempted to fill out the reservation form presented on Hertz.com’s home page.

Yet, to take advantage of their club membership, the user has to skip the home page reservation form and, instead, log into the system. Logging-in, once the reservation process is started, requires restarting the entire reservation.

It’s clear, watching these frequent customers, that, for many of them, the flow of the application (log in first, then start the reservation,) is not the natural flow they’d like to use. If they are intent on starting the reservation, they’ll be stuck later on, when they realize their personal information isn’t pre=populating the fields.

Matching the user’s natural flow is just one challenge a web-based application developer needs to address during the design and development process. To help our clients, we’ve compiled a list of three challenges they’ll want to keep their eye on.

Challenge #1: Finding the Application

Some web-based applications are very lucky. They are the only function provided by the site, therefore, they are easy to find—usually right on the home page with nothing to hide behind.

Most applications, however, live within an ecosystem of other information and applications. For example, on your typical airline site, there could be dozens of self-service applications, from making a reservation to updating an itinerary to flight check-in to reward miles redemption. Some applications, such as checking flight status, may be used thousands of times each day. Other applications, such as requesting frequent flyer points for a missed flight segment, may only see a handful of users.

In addition to having many apps on the site, users also need to know what the application is called. Industry jargon and the propensity to brand everything can make it difficult for users to recognize their desired application.

A few years back, Disney.com offered customers a very cute Winnie-the-Pooh bear with a custom message embroidered on its belly, such as “Get Well Soon!” or “We Love You.” In usability tests, customers thought the product was adorable and several of our users wanted to purchase one. Unfortunately, many didn’t realize they needed to click the “Send a Pooh Gram” link to initiate the customization application. The link was cute, but not helpful for identifying the application.

To handle this challenge, we recommend clients regularly conduct usability tests of the site, to ensure users can find the elements of the entire application suite. Of course, they don’t want to say, “Find the Pooh Gram Application.” Instead, they’ll need to be resourceful, with tricks like showing the user a finished product, like the embroidered doll, and ask, “How would you order one of these for your niece?”

Another great resource for developers, to ensure they’ve covered the right terms, is to look at the search terms used, both by referring search engines and the site’s internal search function. By looking at the terms users enter, the team can get a good sense of the users’ own language.

Challenge #2: Setting Proper Preparation Expectations

A major airline recently ran a satisfaction survey of passengers. Upon leaving the aircraft, flight attendants handed each passenger a card directing them to airline’s site and offering a nice incentive for filling out the survey.

While many customers, interested in the incentive, started the survey, few finished, often stopping at a step requiring them to enter their ticket number (found on the boarding card stub). The survey users didn’t realize they’d need this information and couldn’t easily lay their hands on the stub when the site asked.

Many applications required the user bring something to the process, such as a customer number, a credit card, or a copy of their car title. When the application doesn’t warn users up front to gather this information, it surprises them during the process, often causing them to consider whether it’s worth the effort to continue. (This is compounded by their increased suspicion they’ll be surprised by more unidentified required information.)

In addition to needing information, users are often surprised by the application requiring more time than they’d originally planned. Sometimes, this is because the application goes into more detail than the user realized.

Users expecting a fast interaction suddenly are pressured because the application requires more time, which they may not have available. If the early application steps don’t set the proper expectations, a delightful experience can quickly become frustrating.

Again, usability testing can help here with designers paying careful attention to the expectations users form. Asking users what they think they’ll need, both for auxiliary information and time requirements, before they start the task, can help see if expectations are clear.

Field studies are also useful to help identify the contexts of use. A team might discover, for example, that necessary receipts are unavailable because the user has already turned them in for reimbursement, requiring another validation method, such as online lookup.

Challenge #3: Matching the User’s Flow

Hertz.com isn’t the only one who has flow issues. Years ago, we were testing customers shopping on BestBuy.com. Most shoppers in our study studiously found their way through the checkout process to purchase their desired products, very happy with the entire shopping process.

However, a few Best Buy customers got to the very last step, where they site summarized the pending purchase and strongly recommended they print out a copy for their records. These users, feeling the recommendation made sense, complied and printed out the summary, complete with the order number.

Unfortunately for these shoppers, they weren’t done with the order yet—and didn’t realize it. They’d thought, since they printed out a summary with an order number, the order had been placed. However, the application still had one more step, requiring the user to press a “Continue” button to actually enter the order into the fulfillment system.

These shoppers, with their “receipt” in hand, prematurely ended the checkout process, having never placed their order. Weeks later, when we followed up, they were very disappointed with Best Buy, having never received their order. Several told us they’d called customer support, who disavowed any knowledge of the order. While technically correct, this frustrated the users inexplicably—after all, they had the printed receipt! (Of course, upon our discovery of the problem, the talented folks at BestBuy.com fixed this problem with an improved checkout process and were rewarded with a dramatic increase in sales.)

We discover flow problems like these by watching users interact with the application. We look to see if users fight the natural flow of the application, because it doesn’t match their expectations or needs. This helps us understand how users may perceive the flow different from the design team, and can give us insight in how to attain meaningful improvements.