This article originally appeared in the inaugural edition of Scroll magazine in September 2008. Reprinted below.
“You cannot develop a good solution for someone without empathising with that person. Maybe you know the facts. For example, a customer needs to be able to transfer their money from account to account. But why is that person transferring those funds?”
Intelligence vs. Understanding
A hummingbird lands on the ground outside your window and sits there, still. Then she flops over, struggles, and sits upright again. This is so unlike hummingbirds that you react: what’s wrong? Are you okay? Can I help you? You can feel your reaction: your heart might beat a little faster and your eyes might get a bit misty. You think about the things a hummingbird might need to stay healthy: nectar, water, warmth … what else? Since you’re at your computer, you do a quick Google search to see if you can learn a bit more about helping this tiny bird outside your window. Then there’s a movement at the corner of you eye and you look over just in time to see the hummingbird fly off. Again, a palpable feeling engulfs your body: relief, relaxing of muscles. You turn back to your computer able to focus on work again.
There’s a new message in your inbox. It’s your boss sending you the requirements document for the new product. Next Monday is the start of the project. You open the document and flip through it, trying to get a sense of the structure of the information, seeing how everything is organized. There’s a chapter that catches your eye about the end customer. You read the first paragraph, curious about the general nature of the problem. The customer is someone contributing to a superannuation fund to save for their retirement. The customer needs to know rate of financial gain over the years to calculate how much they will end up with by age 65. The customer needs to be able to choose different funds which have different rates of return, and the customer needs to be able to move their money from fund to fund as rates of return change. You move on to another section of the document, then look up from your computer and think about getting a cup of tea.
Where’s the Empathy?
These two events, the humming bird and the requirements document, couldn’t be more different. And yet, they should be the same. I believe that you cannot develop a good solution for someone without empathizing with that person, without feeling something about their situation. Sure, you know that the customer needs to be able to switch their money from fund to fund, so you could create an application that has three fields to specify the fund to transfer from, the fund to transfer to, and the amount. But why is she transferring those funds? What variables govern her decision to transfer funds? What’s going on in her life? If you knew the customer’s brother just told her to get out of the high risk fund, could you support her better than just those three fields? Is there a calculation to help her decide how much of her funds to transfer out, and how much to leave, based on fees she might incur and losses she might take if she stays in the one fund? Is there historic data you could show her that might give her confidence that a downturn is always followed by an upturn in the market? What else does she need to know? How can you help her?
There is a difference between reading the intelligence about what a customer needs and understanding what is driving her. Rather than the basic needs, distilled down to hollow necessities through the process of writing the requirements document, you need to understand the richer set of ingredients that go into making a customer need to transfer funds. With this understanding, this empathy, you can design a richer set of tools that support the customer better than just three fields to transfer funds.
How do you find out what goes on inside a customer’s mind, if all you get is a requirements document? Easy: ask the customers to tell you.
Make a Connection
What I mean by asking customers is not the same as what organizations have done for the past decades. Do not ask them what they want. Ask them what they are trying to get done and why. Connect with them. Try on their life for a bit; walk in their shoes for a mile.
Forget for a minute that you are a designer and that you have this mechanism inside of you that insists on finding a fix for a problem. Turn off that mechanism if you can. Let go of your product and what you were hired to do, and just empathize. After you have a deep understanding of the customer’s world, then you can fire up your brain and solve problems. But not until you have walked in their world and developed an understanding of it.
A listening session is the best process for this. Observation is helpful and always welcome if there are time and resources. However, to get to the reasons behind someone’s actions, you will need to ask them about it. You need to interact with a customer to discover this. Follow the time-honored technique also referred to as “non-directed interviewing.” Let the customer dictate the topics, the vocabulary, and the direction in which the conversation meanders. Avoid writing any of your questions down in advance, since that usually leads to recitation and a hackneyed listening technique. If you must make a list of topics to remember, write them as one- or two-noun prompts to remind you, in no particular order. Listening sessions are not easy to conduct. You’ll need some practice and a few guidelines.
Years ago I was sitting in a session about storytelling by Kevin Brooks, and he said something that caused a cascade in my head. He said, “Most people don’t listen to what someone is saying in a conversation because they’re too busy looking for a place to interject what they want to say about a topic.” A mortified smile crept across my face. From that day forward, I have practiced focusing on what my friends are saying. I try putting my own responding stories on hold or never even telling them. I try to exclusively follow the folds and courses of my friend’s story. I try to see things from their eyes and ask questions to extract a richer understanding.
Part of my professional life involves doing this. At work, I listen to people describe what they are doing then coax out an explanation of underlying motivations. The most rewarding conversations stray into new territory, and my participant gets to think their intentions through in real-time and explain them to me. It’s very satisfying for both of us, because new understanding blooms and we get a little buzz from discovering it. For example, during a listening session in Melbourne, a woman kept telling us that she wanted to ensure she wouldn’t have to worry about how she was spending money while in retirement. I asked her why several times, and at the end, she said, “You know, I think I feel this way because I watched my parents worry and make sacrifices all the time. I don’t want to be in that position again.” It was something she hadn’t enunciated before, even to herself. After saying it, she laughed and told us how that made so much sense to her now.
Look for Emotional Markers
In Paul Ekman’s book Emotions Revealed, he explains that anger is the response to interference. In a product setting, anger shows up as a simmering feeling of upset, and from there, often, to the sowing of disgruntled complaints in sympathetic ears. This kind of stuff shows up in the models I draw from research all the time, and it is important.
While in conversation with a person, prick up your ears if you sense frustration. This is a marker that something is interfering with the customer, keeping her from achieving what she wants to get done. Dig in here; explore what is causing this and, more importantly, explore her reaction, why it goes against her habits or beliefs, and all the things she does to work around it. Capture the upset feelings and the extra steps in a mental model diagram.
When you are reviewing the research model for areas to work on, these areas of emotion will be rich veins to mine. For example, several times “distrust salesperson” has appeared in research models I’ve created of potential customers. These potential customers went to great lengths to contact a technical rep whom they trusted to tell them the honest truth about how well a product might work in their unique set of constraints. The potential customers also sought out other people who had purchased the product to ask them what problems they ran into, or if the product was a poor fit in any way. What I suggested in these situations was that the organization change the way they sold products. I made the appalling recommendation that they get rid of sales people and hire more technical reps instead, as well as sponsor user groups and advertise their presence to potential customers as a source of people to contact about the product. As you might guess, these suggestions got nowhere. But given the right timing and the right set of people who are willing to see the opportunity for what it is, I predict this suggestion will increase sales by a respectable amount.
Understanding Can Guide Strategic Decisions
A deep understanding of a customer’s world gives you a wealth of possibilities, an amazing breadth of ideas to support them. The more you can think and feel like a customer, the better you can imagine what services to offer them. Replace the chapter about customers in the requirements document with a rich model of their world, and your organization will be on a new path to success.