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.

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.

Why We Design

Some time ago I used a web application that underwent a major redesign. The new design was beautiful–far more artistic than the old design. Unfortunately, the redesign also removed some of the most useful features of the application, in addition to making other features harder to use. Forums were buzzing frustrated users who were finding it difficult to do their work.

I remember hearing one of the designers on the application speak at a conference. Afterward, I came away a sense of why the design seemed to have floundered. For him, the main purpose of design was to create something visually appealing. User experience seemed, if not secondary, at least satisfied by an exceptional visual design.

On another occasion (it might have been the same conference), I remember hearing someone say that design is communication. That seemed accurate, and certainly better than focusing only on aesthetics, but it still didn’t go far enough.

Later, I came across these two quotes which capture for me the essential purpose of design:

Design is not solely about making things aesthetically pleasing, although that is part of it. Design, at its core, is about solving problems. And whatever that problem is—from squeezing oranges to running faster to communicating effectively—designers strive to help their users solve their dilemma in the most convenient, simple, and elegant way. Essentially, designers focus on the experience, making it as beautiful and memorable as possible. (Nancy Duarte, slide:ology.)

[Design] comes to grips with the very essence of a problem and proceeds to develop a solution organically, from the inside out, as opposed to “styling,” which concerns itself largely with the distinctive mode of presentation or with the externals of a given situation. The design activity is based upon an understanding of the intrinsic principle of a given problem and its solution. (Hugh De Pree, quoted by Roger Martin in The Design of Business: Why Design Thinking is the Next Competitive Advantage.)

Solving problems. At the heart of it, that’s why we design!