Switch - Chip Heath [45]
• Motivate the Elephant. 1. Find the feeling. At Microsoft, the developers were invited to visit the usability testing lab. There, from behind a one-way mirror, they could watch real users struggling with their programs. It made all the difference. The test lab manager says that when developers see a user live, “Twenty ideas just immediately come to mind. First of all, you immediately empathize with the person. The usual nonsense answers—‘Well, they can just look in the manual if they don’t know how to use it,’ or ‘My idea is brilliant; you just found six stupid people’ … that kind of stuff just goes out the door.” 2. Grow your people. Developers may worry that, if their code needs revising, it reflects negatively on their abilities. (We’ll talk about more about this in Chapter 7, the section on the “fixed mindset.”) We should stress that the test of a great developer isn’t the quality of his or her first-draft code; it’s how well the developer codes around the inevitable roadblocks. We should make an effort to praise ingenious solutions to customers’ problems.
• Shape the Path. 1. Build habits. Is the customer feedback coming at the most convenient time in the code development cycle? Developers have routines that work for them. Can we make an effort to snap the user-testing onto an existing routine, so we’re not complicating the Path? 2. Tweak the environment. At many companies, programmers are given the best computers. This practice is great for productivity but lousy for customer empathy. One manager says that every time his developers use machines a generation ahead of their customers’ equipment, the software they create has usability problems. Why? Because the developers have no intuition about how slowly the software is running for typical end users. Solution: Require developers to program on the same machines customers use. (This is another Path solution that has been pursued by Microsoft.)
4.
When people push for change and it doesn’t happen, they often chalk it up to a lack of understanding. A mom grouses, “If my daughter just understood that her driving habits are dangerous, she’d change.” A scientist says, “If we could just get Congress to understand the dangers of global warming, they’d surely take legislative action.”
But when people fail to change, it’s not usually because of an understanding problem. Smokers understand that cigarettes are unhealthy, but they don’t quit. American automakers in the early twenty-first century knew they were too dependent on the sales of SUVs and trucks (and thus on low oil prices), but they didn’t innovate.
At some level, we understand this tension. We know there’s a difference between knowing how to act and being motivated to act. But when it comes time to change the behavior of other people, our first instinct is to teach them something. Smoking is really unhealthy! Your chemotherapy medicine is really important! We speak to the Rider when we should be speaking to the Elephant.
This realization—that we can make an impeccably rational case for change and people still won’t change—is pretty frustrating. Why did Robyn Waters need to go through all the trouble of staging demos for her colleagues at Target? Shouldn’t the logic of design innovation have been compelling enough on its own?
Why can’t we simply think our way into new behavior? The answer is that, in some cases, we really can’t trust our own thinking.
5.
As you watch, a stranger walks into a room and sits down behind a table. He picks up a piece of paper and reads aloud a generic-sounding weather report: “Tomorrow, we’ll see highs in the upper 80s with an overnight low of 53….” He completes his “report” in about 90 seconds and walks out of