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:
- 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.
- 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?
- 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.
- 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!
- 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.
