“You can observe a lot just by watching”

As Yogi Berra famously commented, “You can observe a lot just by watching.” Obvious? Sure. Easily ignored? That too, unless we make it a point to observe.

To illustrate with three of my favorite user experience examples:

Example 1

For the past few months, I’ve been enjoying an online course in Human-Computer Interaction offered by Coursera and taught by Stanford Associate Professor Scott Klemmer. In one session, he talked about Expedia’s experience with a problematic web page design. Their web analytics showed that a significant portion of users would click the Buy Now button, obviously intending to make a purchase, but then wouldn’t go through with it.

They were puzzled until they focused on the user experience. A confusing design led users to put their bank information in the wrong field—and then, of course, the transaction failed. Once the problem was fixed, Expedia calculated that they realized an additional $12 million in profit that year.

Example 2

With identify theft prevalent in cyberspace, password security is getting a lot of attention. You’ve probably been to sites that measure the strength of your password as you’re setting up a new account. You’d think that would be motivating to most people… but Associate Professor Anthony Vance of BYU conducted research that showed it wasn’t; in fact, it had no more effect on password strength than static text.

So what does motivate users to create stronger passwords? Paying attention to user behavior revealed this interesting insight: the most effective motivator was an interactive interface that evaluates the password and shows roughly how long it would take a hacker to crack. (The research is described here. Professor Vance’s findings were presented at an IT conference I attended and to my knowledge haven’t been published online.)

Example 3

Paul Howe and his colleagues came up with what they thought was a really cool idea: allow people making online purchases to tell their friends via social media. So they created a realistic mockup and did user testing. Were they ever glad they did: most of their users hated it. So after minimal time and expenditure they abandoned the idea.

Several of their competitors had the same idea, which they apparently developed without actually testing with users. Some months and a boatload of money later, they also conceded that it wasn’t such a good idea after all. Paul determined that their user testing probably saved them 9 months of work and around $2 million.

In each of these examples, paying attention to users revealed behavior that was surprising to the designers, and which they wouldn’t have known about otherwise. Yogi Berra was right—you can observe a lot just by watching! The trick is actually doing it.

Design Bloopers #1 — Email Attachments

Lately I’ve had reason to ask, “Is it just really hard to design a good user experience when saving email attachments?” Here’s how the process works on AOL:

  1. I receive an email with an attachment. At the bottom is a Download button, so I click it and download the attachment.
  2. I also want to save the text of the email to my hard drive, so I click Save. I get the following dialog box:

  3. Okay, it would have been nice if they realized that I just downloaded the attachment. Or maybe I really didn’t— otherwise, why would they be asking me again?

    So I click Yes and get this dialog box:

    It’s not just AOL. The other day at work I received an attachment in Outlook. I opened the document and made some changes, then tried to close the email.

    “Do you want to save the attachment?” Outlook asked me. I clicked Yes.

    Responded Outlook: “You cannot save this attachment because it is read-only.”

    Humor aside, the issue isn’t that it’s hard to design a good user experience for email attachments. The issue is that user observation or testing can prevent design failures like these, along with an illogical and even frustrating user experience.

The Low Cost of High Usability

Usability is sometimes seen as one of those “soft” qualities, nice to have, but hard to define and harder to measure. And when something is hard to measure, it’s hard to justify the cost of implementation. Maybe that’s why usability is often considered (if at all) only in the later stages of development, and sometimes only after a product has been released. But at that point, it’s costly and sometimes impossible to make any meaningful usability improvements.

So, how do we “sell” usability? An article in the STC journal Technical Communication (vol. 50, No. 4) suggests one way to quantify the cost-savings. Consider this scenario in which data entry staff are required to enter product information in the screen of an inventory tracking application. Let’s suppose…

  • The average time to complete the screen for one product is 5 minutes.
  • The screen is used 3 times per day by 5,000 employees paid $15.00 per hour.

Given these assumptions, the daily cost to the business is $18,750 ($1.25 cost of 1 entry x 3 daily entries x 5,000 employees). It adds up!

Now, suppose we shorten the process by just 1 minute through better usability:

  • The daily cost to the business drops to $15,000.
  • The savings per day is $3,750.
  • The savings in just 1 month is $75,000.

The savings continue adding up as long as the screen is used. Factor in fewer support calls and the savings multiply even more.

Bottom line: usability impacts the bottom line!

Kudos to Adobe: Great User Experience

I went to Adobe’s site to update Flash, and I’m impressed. Their page knew I was using Mozilla Firefox, and I was presented with Firefox screen shots to guide installation. No “if you are using such-and-such a browser” choices to wade through. Adobe removed the clutter so I could focus on the task at hand.

Now that’s thoughtful, user-centric design.