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!

 

The Problem of Proximity

I admit it: As a designer, I’ve occasionally indulged in the fantasy that users carefully (and appreciatively, of course) examine the interfaces I’ve created as they use them. Doing this, they see the logic of the design and are able to complete their tasks without error.

But my own experience using screens designed by others gives me a reality check. When I use a screen, I don’t have the desire or time to analyze it. Instead, I make quick judgments about features and functions based on their context, perhaps looking for key words like “Submit” or “Delete.” I want to complete my task without a hassle and move on.

Lately, though, I’ve used some interfaces that involved a bit of hassle. As I reflected on these experiences, I found a common theme: two elements placed in close proximity made it easy, even likely, for me to make a mistake.

Bait and Switch

When similar elements are placed near each other, it can be too easy to choose the one you don’t really want. For example, the browser image below shows that the x to close a tab is right next to the + to open a new one. It’s inconvenient to open a new tab you don’t want, but it’s worse to close one you didn’t want to close.

close tab and start tab next to each other

AOL’s desktop application has a similar issue with its email inbox. The button to delete an email is right above the link to view recently deleted email. More than once I’ve clicked the Delete button when I just wanted to view deleted mail. (At least when I do that, I can view the email I hadn’t meant to delete, once I click the right element!)

aol delete elements

To solve the problem, it isn’t enough to use different element types (such as a button vs. a link, as on the AOL screen). The better solution is to place the elements far enough apart that the user isn’t likely to click one when they meant to click the other.

Here’s an example. I designed an order fulfillment screen which had a button for saving an order and another for clearing the order form. I didn’t want users to experience the frustration of erasing data they’d meant to save, so I placed the Clear Form button on the opposite side of the screen from the Save Order button, rather than the typical position next to it:

order entry form with save and reset buttons far apart

With this placement, it’s likely that the user will only choose to clear the form intentionally, not by accident.

Hover to Hide

I enjoy family history, so I often visit genealogy web sites. Two of them use hovering where it’s likely to interfere with the task I want to do.

One site offers a History dropdown list which I use frequently. Right above it is a user dropdown menu which is activated by hovering over my logon name.

family history user and history menus

If I overshoot the History menu by even a pixel or two, I accidentally activate the user menu instead, which hides the History menu I’d intended to display:

user menu hiding history menu

Ironically, a more user-friendly approach appears right on the web site: both the Church Websites and History menus are activated by clicking, not hovering, so it’s much less likely they’ll get in the way when I don’t want them.

Here’s an example from a different site. After I run a search and then open one of the results, an All Results link appears at the top of the screen, making it easy to return to the results list:

all results link under menu bar

As you’d imagine, I use this link all the time. But if I overshoot it, I activate the Family Trees menu, which hides most of the link I wanted:

all results link hidden

As a user, I appreciate it when an interface makes it easy for me to make the choice I want, without other things getting in the way.

Making Me Think (Nod to Steve Krug)

Finally, here are several examples of potential confusion due to unclear placement of text. The screen below shows birth information for someone in my family tree. Notice the Sources and Tag options near the bottom of the image. When elements are placed next to each other and separated by a vertical line, they are typically choices on a menu. I assume that if I click Sources, I’ll be able to take some action related to sources; if I click Tag, I’ll be able to do something with tags.

However, this screen breaks with convention: Although Tag functions as I expect, Sources is actually a heading for any sources that may appear below (particularly confusing in cases where no sources appear).

example of unclear placement of text

Here’s another example from a dialog box which allows me to add a link to an email:

example of confusing text on link screen

At first glance, Test this Link appears to refer to the email address, since it’s (sort of) across from it; it’s actually a little lower than the email address, and it’s even farther away from the URL box. But when I click it, it becomes obvious that it refers to the URL box.

Okay, so neither screen is too hard to figure out with a few seconds of thought and experimentation. But shouldn’t UI text be clear without my having to puzzle over it, even briefly?

Here’s a simple change that makes the dialog box above more clear:

The proximity of elements to each other matters. It can enhance the user’s experience or interfere with it. It’s worth a designer’s attention.