User Point of View? Yes, But…

An earlier post talked about the importance of designers understanding the user’s point of view. There is a caveat, however, illustrated in a quote often attributed to Henry Ford: “If I had asked my customers what they wanted, they would have said a faster horse.” While users’ needs are real and important, the truth is that we as users often aren’t able to articulate what we want. Beyond that, we may not know what’s possible, so we don’t know what to ask for. Finally, we may ask for things we think we want, only to find out we really don’t.

I use a web site that includes a custom directory of people I interact with on the site. The directory is a single page listing all names, and until recently, names were listed in the order in which they were added. Over time, my directory has grown to be quite lengthy (over 400 names) and finding a particular individual could be a hassle.

Other users apparently had the same concerns, because on the support forums more than one user requested the ability to sort the directory by the various columns on the page: name, date added, etc.

The site owners acted on the feedback and put new sort functionality in place—only to have users give negative feedback about it! After using it for a short time, I realized why: sorting really wasn’t that helpful for finding people in my list. What I should have asked for was filtering: the ability to type in a name, for example, and have only matches show up. But I didn’t realize that when I gave my initial feedback, and apparently neither did other users nor the site owners.

Jakob Nielsen summed it up well in his ironically-titled Alertbox article on this topic: “First Rule of Usability? Don’t Listen to Users.” His article includes these “basic rules of usability”:

  • Watch what people actually do.
  • Do not believe what people say they do.
  • Definitely don’t believe what people predict they may do in the future.

Following these “rules” gives designers more more accurate feedback so we can meet our users’ actual needs rather than what they say they need, which may not be the case at all.

Getting to the Right Forest, Part 2

In The Design of Everyday Things, Don Norman shares the humorous anecdote of Alice, who was driving with her friend Sally. Alice noticed that the rearview mirror wasn’t adjusted correctly on the passenger side, so she asked Sally to adjust it—or at least she meant to. What she actually said to Sally was, “Please adjust the window.”

Sally was puzzled and tried to get Alice to explain exactly what she wanted done with the window. Alice, on the other hand, couldn’t understand why Sally was having a problem responding to such a simple request. Alice’s solution was to repeat the erroneous request, louder and louder each time.

Not surprisingly, Alice’s best efforts didn’t solve the problem because she didn’t realize what the problem was.

Misdiagnosing the problem is a common human failing. But why does it happen? In my own experience, there are two main reasons. First, we have a tendency to be blinded by our own assumptions, our own world-view. Sometimes we realize we are making assumptions, but they seem so obvious that we don’t feel the need to question them. Other times, we aren’t even aware of the assumptions we’re making. Alice assumed she was communicating clearly. It took some time before she realized that she held this assumption, and that it was in fact untrue.

The second reason, easier to see, but perhaps just as hard to address, is that we don’t do the hard work of gathering data and thinking through the problem. Sometimes when I’m coding, I’ll be stumped by a tricky problem. I’ll try everything I can to figure it out—or so it seems. Finally, I’ll decide to post a question to a forum or help group, which of course requires a clear explanation of the problem and what I’ve tried so far. And more than once, I’ve discovered the solution to my problem in the very act of trying to explain it to someone else. I believed I’d thought through the problem and exhausted all my options, but I really hadn’t.

Thoroughly examining a problem can seem tedious and time-consuming, but it’s not nearly as time-consuming as repairing the mistakes that virtually always result from misdiagnosis.

So how can we avoid these traps and increase our likelihood of correctly pinpointing whatever problem we’re dealing with? Here are some suggestions:

  1. Get as close as you can to the problem. If possible, observe it as it happens. Don’t rely on someone else’s account or circumstantial evidence. See it for yourself.
  2. Ask questions. Is it really a problem? What led to it? Why do we need to solve it? What will happen if we don’t? What are our options? What are the consequences of each one? What would we do if money and time were no object?
  3. Write out the problem as a way of thinking it through. It may help to write as if you’re explaining the problem to a trusted friend or colleague. Chances are good that you’ll experience the same thing I did: the very act of writing out the problem will open your eyes to new information about the problem and potential solutions.
  4. Diagram the problem. In the software requirements course I took at Red Rock Research, we learned how to sketch use cases, complete with computers, systems, actors, and actions. What an eyeopener it was to make myself think through a design problem by sketching all the components and their interaction with each other!
  5. Collaborate. Others will likely have a different take on the problem and different insights into it. Not only that, when you get a group of people together who want to make a good faith effort to solve the problem, the ideas and insights of the group will feed off each other. I saw this repeatedly when I led a team of very talented, creative, and ego-free technical writers. As we brainstormed together, the insights and solutions we came up with were better than any of us could have come up with alone. The whole really was greater than the sum of the parts.

If addressing problems is a major focus of good design, then we can’t do better than to identify the right problems.

Getting to the Right Forest, Part 1

Usable design is both about solving and preventing problems. You might think it would go without saying that we want to be solving the right problems. But it’s not always as easy as it sounds.

Some time ago I worked at a place where the intranet search had a poor reputation. Results were all over the place, often with little or no apparent relevance to the search terms entered. I’d estimate that close to 50% of the time I couldn’t find what I was searching for, even though I knew it existed and that the specific search terms I’d used appeared on the page. Eventually I’d find the page by digging up an old email with the link or asking another employee.

Employees complained about the search, and the intranet engineers acknowledged the problem. Then one day I was surprised to hear one of the engineers talk about the need to make the search “fuzzier,” presumably so it would return more results. I remember thinking to myself, I don’t search to be fuzzier; I need it to be more focused! In other words, the problem wasn’t that I was getting too few results; I was getting the wrong results.

Here’s another example. One of my favorite sites beta-tested an elegant and powerful search form. It was in a narrow banner at the top of the page, and it offered flexible options that made it simple to run a complex search. Not only that, the search form stayed unobtrusive but visible as I continued to refine my results. I never had better search results than with that interface.

Then, for reasons that puzzle me to this day, the user-friendly beta design was scrapped and a less user-friendly one rolled into production. The new design dropped some of the most useful features of the beta; in addition, the search form was moved to a panel on the left of the screen. Even with some of the most useful features removed, the search panel was so long that it went “below the fold” on many monitors, making it necessary to scroll down to see the Search button. And because it was necessary to scroll down to initiate the search, results were loaded into the scrolled-down page so users had to manually scroll up to the top of the results.

Users complained about the new design, and soon an “improvement” was put in place: When the user clicked the Search button, the web page auto-scrolled to the top of the page.

Once again, the problem had been misdiagnosed. Having to scroll up after searching was only a symptom of deeper problems with the new interface.

In her thought-provoking blog post How Reframing a Problem Unlocks Innovation, Tina Seelig shares a quote attributed to Albert Einstein:

If I had an hour to solve a problem and my life depended on the solution, I would spend the first fifty-five minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes.

Realizing there is a problem is a great first step, but it’s not enough. We need to be sure we’re not chopping down trees in the proverbial “wrong forest.” We’ve got to identify the problem correctly before we can solve it. How to do that is a subject for another blog post.

Microcopy and Disaster Avoidance

If you visited my blog over the last few days, you probably noticed it was down for a while. There’s a usability story behind that.

Last Monday I spent about four hours on a blog post, complete with complementary screen shots. I posted it and all was well, until I noticed that I needed to make a slight edit. I tried to log back in to make the changes, but I couldn’t. I kept getting this error message:

Now as much as I’d love to think that millions of people find value in my blog and were hitting it all at once, that seemed pretty unlikely. So I tried a number of typical troubleshooting strategies, all to no avail. Finally, because the problems started shortly after I upgraded my version of WordPress, I decided to uninstall and reinstall it.

That’s when things got interesting.

I’d installed WordPress using a simple WordPress utility page offered by my ISP, so I went there for the uninstall. On that screen, I was duly warned:

This tool can remove WordPress from your hosting account, or remove the installation from our records. These actions are not reversible!

[Uninstalling] will permanently delete this installation. This includes any files installed, as well as any database tables. Additional themes, plugins, modules, cache files, etc will be left behind.

I’d done enough uninstalls and reinstalls of various products to know that there was a good chance something would go wrong. So I carefully downloaded a copy of my blog site from the server to my hard drive. Then I uninstalled WordPress, reinstalled it, and checked my site. All my blog posts were completely gone.

No problem, right? After all, I’d suspected things wouldn’t go smoothly. So I went to my backup. Aha, there were the post folders, all neatly organized by month and year. I opened them up to start retrieving the lost posts—nothing. The folders were all completely empty.

At this point, I started to get concerned. How was it possible to have a complete backup of my site with no blog posts? Googling brought up an answer I definitely didn’t want: the actual text of my blog posts had been stored in a database table, which had been deleted along with my WordPress installation. Who knew?

Not me. Just to be clear, I have a pretty strong technical background. I’ve worked for IT organizations in various companies and managed web sites. But using WordPress was a new experience for me, and my assumption that content was stored in HTML files turned out to be false.

Fortunately, the story has a happy ending, as you can see from my blog (since almost all my old posts are back). Despite the warning that the uninstall was not reversible, I knew from experience that my ISP probably did have a backup of the database table. I contacted them and they were able to restore all but my last post, which had only existed for a few hours and wasn’t included in the timed backups. (Here’s a shoutout for the great help I received from Dot5hosting to get my blog restored!)

So there’s a lesson here, and it has to do with microcopy. I suspect that the average WordPress blogger is like I was and doesn’t realize blog posts are stored in a database table. That being the case, the following revised microcopy could help others avoid the fiasco I just experienced:

[Uninstalling] will permanently delete this installation. This includes any files you have installed; it also includes all content you have added, which is stored in MySQL database tables. (For instructions on backing up your database tables, click here.) Additional themes, plugins, modules, cache files, etc will be left behind.

There’s a feedback link on the WordPress utility page mentioned above. I think I’ll send them a link to this blog post. If it spares someone else the “adventure” I went through, that would be a good thing!

 

Beyond Fad to Functionality: Hop Off the Carousel

Someone at work asked a group of colleagues to check out a new beta web site. The home page featured one of those trendy, large carousels that took up about half the space “above-the-fold” on my large monitor.

“Looks great!” a couple of people quickly commented. And the image on the carousel was lovely. But I found myself wondering if anyone had thought about how the carousel affected user experience, rather than how pretty the picture was.

Then another colleague raised the same concern. As the discussion went forward, a number of issues surfaced from our own experience:

  • Interference with user goals. When users visit a site, they usually go for a specific purpose. Chances are good that the carousel content will have nothing to do with that purpose, so the carousel can make it harder for users to accomplish their goals.
  • Interference with communication. In addition, carousels typically take up a large chunk of screen real estate. In doing so, they push other content below the fold or even off the screen, making it harder for users to find information they need.
  • Quick obsolescence. Carousels have a short shelf-life. Once users cycle through the images (if they have the patience for it) the carousel becomes old news.
  • User tune-out. More likely, users don’t cycle through the images. So there’s a good chance they won’t see content the site owner thinks they will see.

That got me thinking—these carousels seem to be everywhere. So was I missing something? Or was this another example of a trend being adopted because it “looks cool” and “everyone’s doing it” without considering its impact on usability?

I did a little digging and found this telling post on conversionxl.com. It turns out that extensive usability tests concluded pretty much the same thing: carousels are ineffective. As one UX advocate, Lee Duddell, humorously noted:

Carousels are effective at being able to tell people in Marketing/Senior Management that their latest idea is now on the Home Page.

They are next to useless for users and often “skipped” because they look like advertisements. Hence they are a good technique for getting useless information on a Home Page (see first sentence of this post).

In summary, use them to put content that users will ignore on your Home Page. Or, if you prefer, don’t use them. Ever.

‘Nuff said.

The Value of Realistic Experience #2: Lessons Learned from a Software Purchase

Our business team was evaluating several options for a major software purchase. We’d done our due diligence and had a detailed checklist of all our requirements. We rated each potential purchase against our checklist and the final choice seemed clear. So we made the purchase.

Then we started using the software. It turned out to be one of the most troublesome applications I’ve ever used. Tasks that should have been simple were unnecessarily complex (I shared an example in this post). Errors were frequent and error messages were obscurely worded (e.g., “Object reference not set to an instance of an object”). Features that were supposedly included actually required a fair amount of programming—by our programmers, not the vendor’s—in order to work.

We learned a valuable lesson from this experience: you can’t expect to evaluate usability of software with checklist—especially if you’re getting your answers from the company’s marketing brochures or sales representatives. When you’re evaluating usable design, there’s no substitute for hands-on, real-life experience.

Of Choice and Forgiveness

It was five minutes before my meeting with a colleague (on usability, in fact!), and I was shutting down my laptop to head over to the meeting room. Earlier in the day I’d noticed that little exclamation point on my Windows Shutdown button, indicating that updates would be installed when I shut down. However, in my rush to get to the meeting my hand went on autopilot and I clicked the Shutdown button before I remembered the updates.

18 updates this time. Of all the days. Well, I thought to myself, hopefully they’ll be fast.

They weren’t.

20 minutes later, I finally made it to my meeting. (Fortunately, my Android tablet doesn’t have these types of usability issues, so I got a message to my colleague about the delay.) Ah, the irony: poor usability got in the way of my getting to my usability meeting!

Two key usability principles were violated in this experience. The first is that good design gives the user a choice when a course of action could have negative consequences. Windows should have told me approximately how long the updates would take to install, and then let me choose whether or not to install the updates at that time.

The second is that good design is forgiving. Errors should be easy to correct. I hadn’t meant to start the update process, but once I did, there was no way to cancel or pause the updates—only the ominous warning not to shut off my machine. (I learned the hard way that the warning is valid. Once a similar update was making me late for a critical meeting where I was presenting. In desperation I shut the machine off anyway, and it was never the same afterward.)

I’m sure the person who designed the interface and process thought they were justified in not giving me a choice of when to install the updates. After all, updates are good, and people shouldn’t delay installing them. Reasonable assumptions, right?

Not for me that day.

Usable design doesn’t impose assumptions on users; instead, it gives them the ability to make choices and recover from those choices when necessary.

The Value of Realistic Experience, or Lessons Learned from Herbal Tea

Insomnia is a frequent challenge for me, so I was interested when a friend told me about one of those herbal teas that is supposed to help one relax and fall asleep more easily. Hoping for the best, I drank a cup a little before bedtime—only to be awakened some time later with an extremely full bladder, more so than should have resulted from a small cup of tea near bedtime.

I decided to do a little checking on the ingredients. As expected, I found herbs known to promote relaxation and sleep. Then I found something I definitely wouldn’t have expected. One of the ingredients was a diuretic. Sleep promoter and diuretic: not a good combination!

Did the people who created this herb tea never try drinking it themselves? No, I’m sure they did—but probably during the day time, and probably only in small spoonfuls. In other words, they tested their design for a new herb tea in unrealistic circumstances, circumstances which did not reflect the users’ reality. In doing so, they missed a major problem—a deal breaker, in fact. (I never bought that tea again!)

A design may look good on paper or on the screen. Without trying it in a realistic scenario, users may even tell you it would work. But you never know a design really works until you’ve proven it in the crucible of realistic experience.

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