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.

Why Else We Design: Of Fences and Ambulances

There’s a poem written in the late 1800s by Joseph Malins about townspeople living near the edge of a cliff. (Googling brings up a number of different versions). Because people kept falling over the edge, the citizens decided something had to be done. Two solutions were put forth: build a fence at the top of the cliff, or put an ambulance at the bottom of the valley.

In the poem, the vote came out in favor of the ambulance. After all, the slip over the cliff only might happen. But once someone falls, well, there’s real damage to take care of.

As crazy as it sounds, in real life we see examples of this type of thinking all around us. We see it when products are developed without thoughtful design. We see it when products are released without adequate testing. We see it when software offers us choices with no indication that one might be wrong—until we get an error message after choosing the wrong option. And the cost of correcting a mistake is virtually always higher than preventing it—often exponentially.

In an earlier post, I asserted that design is about solving problems. That’s true, but I think it goes further. Good design makes the right path clear and minimizes the chances of going down the wrong path. In other words, good design stops problems from happening in the first place.

Design Bloopers #2: Tablet Power Management

I love my Evo tablet—it has revolutionized the way I manage my life. Like most tablet owners, I try to maximize battery life. One of the main ways I do so is by keeping the screen on its dimmest setting when I’m indoors.

But my tablet has an odd quirk: when it alerts me that the battery level has reached critical, it simultaneously adjusts the screen brightness to the highest setting! At the very point when my tablet most needs to conserve battery power, the tablet changes my setting to drain the battery even more quickly.

Was this intentional? I doubt it. I can’t imagine a developer coding a battery alert to include a power drain. So it was probably caused by a unexpected line of code somewhere. But once again, it points to the importance of testing designs in realistic scenarios to make sure they work as expected and are free of glitches. User testing adds to the cost of the project; but failing to do user testing costs even more.

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.

Making the Miracle Happen

One of my favorite cartoons in the world is this one by Sidney Harris. A scientist stands at a blackboard with his colleague. On the board is a complex equation, except at step two, which consists of this simple statement: “Then a miracle occurs.” His colleague responds, “I think you should be more explicit here in step two.”

Most of us have probably found ourselves in the place of the first scientist. Our tendency as human beings to gloss over tasks that are time-consuming and tedious.

This is true in design as in almost every other endeavor. Maybe we get tired or run out of time, but whatever the reason, we skimp on the detailed planning required for a good design. We tell ourselves that somehow it will all work out. Instead of following the old adage “measure twice, cut once,” we measure haphazardly and end up cutting and re-cutting many times. We might think we’re saving time, but we really aren’t—if we don’t have time to plan our design thoughtfully, how do we think we’ll find the time to rework it?

There’s no secret to the miracle: it happens when we pay the price to get to the necessary level of detail for a bullet-proof design.