User Point of View: Elusive but Essential

Creating a hyperlink is one of the simplest things we do online:

  1. Select the text to be linked.
  2. Choose something like Add Hyperlink (usually via shortcut keys, a context menu, or a link icon).
  3. Type or paste in the target URL and save.

Pretty straightforward.

But there’s a way to make it harder, as I discovered when using an authoring/content management application. In this application, everything is stored in a database as a separate “object”: Documents are objects, pictures are objects, text fragments are objects, and yes, hyperlinks are objects. The hyperlink object has properties, such as the type of link (internal or external) and the link destination (internal document or external URL). This structural design makes sense in terms of content management and has some clear advantages.

In the application, the process of creating a hyperlink reflects this structural design. But as a result, it’s a lot more complex.

  1. Select the text to be linked.
  2. Choose Add Hyperlink. I get a list of names of hyperlink objects. Turns out I can’t just specify a destination; I have to use an existing hyperlink object or create a new one. Trouble is, it’s not apparent where any of them are pointing, so I can’t easily tell which one to use.
  3. Start opening hyperlink objects to try to find the right one:
    • If I find it, I close the object, then double-click to select it.
    • If I don’t find it, proceed to step 4.
  4. Click New to create a new hyperlink object.
  5. Name the object, specify the target document or URL, and save. The new object is now automatically attached as a hyperlink to the text selected in step 1.

Does this process make sense based on the underlying structure of the application? Absolutely. But as a user, do I care or even need to know about the underlying structure when creating a hyperlink? Not really; I just wanted to get the job done as quickly and easily as possible.

And here’s the thing that’s easy to lose sight of: the process did not have to reflect the underlying structure. It could have been handled behind the scenes like this:

  1. Select the text to be linked.
  2. Choose Add Hyperlink.
  3. Point to an existing internal document or type an external URL and save. Behind the scenes, the application checks to see if a hyperlink object already exists, based on the target I specify. If it does, the application uses it. If not, the application creates it.

As interface or process designers, it can be tricky to step out of our world and into the users’. It takes thought and observation to determine what matters to them. It can even be hard to give up a design that makes a lot of sense to us or to the software developers, but which doesn’t serve the users. And simplifying the process for users almost always requires more work on the back end. But the result is a more user-friendly, efficient design and process, and that pays big dividends on an ongoing basis.

“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.

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!