This was written as part of the rough draft for Deploy Empathy, a practical guide to interviewing customers.
Like it? Order the book:
Consider the following scenario.
You go to stay at a friend’s house in a town you’ve never been to. Service is spotty, so you ask them how to get to the grocery store. They tell you to take two rights and a left, and you nod and say okay.
Consider another scenario:
Your spouse has a friend visiting. You overhear them tell the person to take the second right, two rights, and a left. You interject and say that the easier and faster route is to take the first right, go straight, then left.
What’s the difference?
In the first scenario, you accept what they say without questioning. In the second, you brought your own experiences and perspective into the mix. You corrected – maybe gently, depending on tone of voice – inferring that your perspective is the right one, even if that’s the route your spouse takes to the grocery store every time.
(Now, you might think it’s rude to interject in this scenario and wouldn’t do it yourself. Let’s leave that aside.)
The idea is:
Everyone is an expert in their own experience, even if it isn’t factually correct.
Our goal in an interview is to learn how they see the world. It is not to help them be right, or share our own version of what is right.
In order to make intuitive products, we need to match the user’s version of a process, and we can only learn that by asking them about their process and accepting it unquestioningly.
Now let’s think about this in a context of a user interview, one you might encounter.
Let’s say someone is telling you how they built their website.
You: “What tools did you use to build your website?”
User: “I used Laravel for the front-end and Tailwind for the backend.”
If you’re a developer, you’re probably jumping out of your skin right now at how wrong this is.
But we can’t correct them, because that would shatter the sense of safety we’re trying to build in the interview.
To follow up, we might say:
You: What was it like to use Laravel for the front-end and Tailwind for the backend?
Or they might go into their explanation, and we learn why they have confused these. Maybe they meant they started with Laravel first. Or maybe they genuinely mix up front-end and back-end. If we’re, say, a programming course creator interviewing novice developers, this is incredibly helpful information to us so we can learn that this is an area we need to focus on more.
When someone says something that is wrong, we need to say to ourselves, “Okay, that was wrong. How can I gently figure out how they came to understand it like that?”
Maybe it means digging into sources they used, or the speed at which they’ve acquired this knowledge, or the length of time since they’ve worked with this information. We all make errors, or believe things that are wrong or incomplete despite our best intentions, and we have valid internal reasons for why those things happened. Even if the output ends up being wrong. Once we discover an error in our thinking, we might work through why it happened from an understanding perspective. We need to grant other people this grace.
Let’s take a less extreme example.
You’re talking to a new user of your product – let’s say it’s that same programming course. The price of your course is $299.
User: When I saw the price was $399, I was a little nervous, but I decided it was worth the investment.
Do we correct them?
No. We roll with it, and keep going. We dig into the reservations they had around the investment in general, like:
You: Can you tell me more about what made you nervous about it?
What we can do – in situations like this where the facts matter – is email them later. The next day, after we’ve sent our thank-you note, we can send a clarification, like:
Thanks again for taking the time to talk to me the other day. I was just reviewing my notes, and I saw at one point you said you paid $399 for the course. I just checked, and you paid $299. [It looks like you had a $100 off coupon for taking a previous class.] I’ve attached the receipt here.
But think hard before you send an email like this, and only do it if it really genuinely matters and makes a difference for them. In this scenario, someone might have a training budget from their employer, and that $100 could make a difference to the person.
But if it doesn’t make a difference to the person, don’t correct them afterwards.
I can’t tell you how many times people have made errors in interviews I’ve conducted. Everything from factual errors about the age when Americans are required to take distributions from their retirement accounts to mispronouncing the company name. When I worked for The Motley Fool, we had people call it “Motley Crue” all the time – more often than you might believe.
When this happens, I remind myself of the small general store in the center of the town I grew up in. When I was a kid, the owner of the store was called Wayne, and the store was technically called Wayne’s. But the previous owner was named Jack, so most people, including me, called it Jack’s… even though I wasn’t even alive when Jack owned it.
It isn’t factually correct, but it’s my experience, and it feels right to me. It serves a function: it makes me feel more connected to my hometown and its history. No matter what the factual truth is, that experience is valid. And that is what matters in this context.
Everyone is the expert of their own experience.
So no matter what, we cannot correct people. Even when they make glaring errors, or say things that seem sub-optimal to us. This is their experience, and to correct them on even the smallest thing would break the rapport we’ve worked so hard to build in the interview.