Intelligence vs Understanding
Written byIndi Young. 5 comments
Solving problems requires more than brainpower and a design fix. We need to feel our customer’s pain to fully understand what they need. So throw off your thongs and get ready to walk a mile in your client’s shoes.
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 your 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 organised. 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. They need 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 that have different rates of return and also 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 hummingbird 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 empathising 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 are they transferring those funds? What variables govern their decision to transfer funds? What’s going on in their life? If you knew the customer’s brother just told them to get out of the high-risk fund, could you support them better than just those three fields? Is there a calculation to help them decide how much of their funds to transfer out, and how much to leave, based on fees they might incur and losses they might take if they stay in the one fund? Is there historic data you could show them that might give them confidence that a downturn is always followed by an upturn in the market? What else do they need to know? How can you help them?
There is a difference between reading the intelligence about what a customer needs and understanding what is driving them. 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 organisations 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 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 empathise. 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.
Interviewing is the best process for this. Observation is also helpful and always welcome if there is 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-honoured technique called 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 interview 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. Non-directed interviews are not easy to conduct. You’ll need some practice and a few guidelines.
Last year 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 the topic.” A mortified smile crept across my face. From that day forward, I have consciously focused on what my friends are saying, putting my own responding stories on hold, or never even telling them. Instead I follow the folds and courses of my friends’ stories. I try to see things from their eyes and ask questions to extract a richer understanding.
Part of my professional life involves doing this; I don’t know why I wasn’t applying it to my everyday life. 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 something through in real-time and explain it 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 an interview 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.” 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 business 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 all the time and it is important.
While in conversation with a customer, prick your ears up if you sense frustration. This is a marker that something is interfering with the customer, keeping them from achieving what they want to get done. Dig in here; explore what is causing this and, more importantly, explore their reaction, why it goes against their habits or beliefs and all the things they do to work around it.
Capture the upset feelings and the extra steps in a mental model. When you are reviewing the 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 models about the customers of an organisation. The 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 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 organisation change the way it sold products. I made the appalling recommendation that they get rid of salespeople 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 organisation will be on a new path to success.