Common mistakes in design thinking — Empathy
Getting to know your users should be easy, yet many of us slip up along the way. Why?
As we gain more experience in our field, we become susceptible to blind spots. We may formulate bad habits or take shortcuts without even noticing the implication of our actions.
In this five-part article series, we’ll dive deep into each stage of the Design Thinking process and discuss the most common mistakes I’ve seen people make throughout my nine years of building digital products.
Stage I: Empathy
The Nielsen Norman Group separates sympathy from empathy and defines empathy as “the ability to fully understand, mirror, then share another person’s expressions, needs, and motivations.”
It’s a critical first step in the process and important to get right so we solve the right problem for our users. Let’s see where most of us slip up.
Mistake #1: Leading context or interview questions
When doing discovery interviews or surveys, there’s a fine line between arming your interviewee with the necessary context versus giving them too much information. Where do we draw the line?
Let’s imagine we’re kicking off a discovery interview:
You: Thanks for taking time to speak with us about gaming. We’ve heard gamers over the age of 30 are quite busy and face many challenges with finding uninterrupted time to game – especially with other gamers their age. Our data shows that the typical gaming session for most gamers over the age of 30 is only 45 minutes! My team’s goal is to figure out how to design a game that 30+ year olds also want to play. Any questions before we begin?
Interviewee: Wow, 45 minutes? That feels short… I mean, I do have a full-time job and other responsibilities at my age so maybe that’s about right…
Does the interviewee know why we’re talking to them? Absolutely. But they also now know that other gamers their age are busy people who can only game for 45 minutes a day. They also know the type of game we’re trying to create – a game that those over the age of 30 would also want to play.
By sharing this extra data in the setup, we’ve introduced significant bias and pressured our interviewee to fit within the artificial lines we’ve drawn. We lose a sense of authenticity and our interviewee will likely filter or modify their responses based on the context we gave them. No bueno.
Instead, let’s remove bias and keep it simple:
You: Thanks for taking time to speak with us about gaming! We’re looking to learn about your gaming habits. This will help us create games that fit within your lifestyle and interests. There are no right or wrong answers here – please share as much information as you feel comfortable. Any questions?
Interviewee: Nope, sounds good!
We thank them for their time and briefly explain what we want to learn and why. Keep this high-level and neutral — they don’t need to know about our product roadmap! Lastly, we make them feel comfortable to share whatever information they feel comfortable sharing. That’s it!
Bonus tip! When possible I like to transition into the questions by showing vulnerability (e.g. “This is a space I’m less familiar with, so I’ll probably start out by asking some pretty basic questions…”) to make the interviewee feel confident and set the framing that I’m here to learn from them.
Mistake #2: Answering questions for users
We’re now getting to the meat of our interview questions…
You: How do you decide whether or not to purchase a new game?
<momentary pause>
You: Perhaps you look on gaming websites like IGN? Or check Reddit or YouTube to see what people are saying first?
Interviewee: Yeah, IGN can be helpful sometimes... and I guess I have watched reviews on YouTube.
For most of us, when speaking to someone there’s nothing more awkward than silence. After a momentary pause, we jump in to try and help, however, we end up projecting our own solutions onto our interviewee and ruin our ability to truly understand how they think!
Silence is a signal that our interviewee is processing information. Instead of seeing silence as awkward, use it as a tool to get more quality responses out of your interviews.
You: How do you decide whether or not to purchase a new game?
<momentary pause>
<seven seconds of awkward silence…>
You: Perhaps you can think back to the last game you purchased… what was that process like? Where did you start?
Interviewee: Well, I know this may seem a bit old fashioned, but there’s this arcade close to where I live that has a bunch of games from the 90s and I like…
Being comfortable with silence will take some practice. I like to count to seven in my head before nudging (seven seconds will feel like an eternity at first). When you do have to nudge, steer clear of any solutions – especially specific ones. Remember, you want to hear their ideas, not yours.
Mistake #3: Not diving deep enough
If you’re like me, you create an interview guide before jumping into interviews with users. Interview guides are necessary to give your interview structure and make sure you cover the most important topics with the time you have. I want to emphasize that it’s an interview guide, NOT an interview script.
You: How do you feel about games that allow you to play online with other players?
Interviewee: They’re OK, but nowadays I mostly play solo.
You: OK, and what are some of your favorite games from the past year? …
Often times real insights live two or more layers below the surface. From our example above, we know that our user prefers solo games, but we have no idea why. The empathy stage is all about understanding what makes your users tick. We can’t just stop at the first question and expect to understand everything from their motivations to their feelings – we need to dig deeper.
Let’s try that again:
Interviewee: They’re OK, but nowadays I mostly play solo.
You: And why is that?
Interviewee: I find it to be more relaxing.
You: Why is playing solo more relaxing for you?
Interviewee: Well… it sounds silly, but even though I enjoy playing games with other players, I’m embarrassed about other people hearing my voice. It makes me anxious. And it’s challenging for me to communicate quickly if I’m not speaking into a microphone… so I just avoid playing games that require communication with other players.
We would’ve missed out on this insight had we just moved on to the next question on our interview guide! After your interviewee responds, ask yourself “How well do I feel I actually understand why they said what they said?” and if there’s any doubt in your mind, it means it’s time to dig deeper with a “Tell me more about that…” or “That’s interesting! Can you please elaborate?”
Mistake #4: Adding bias when note taking
Let’s imagine we’re taking notes from the insight we gleaned from above and wrote…
Our notes: User doesn’t like to play online games with others because she doesn’t want players to hear her voice and typing takes too long. Add a feature that allows her to convert speech to text?
Uh oh! We’ve missed so much rich detail from her original response! What about how she feels? Or that she needs to communicate quickly to others? How does this impact her behavior or the types of games she plays? We don’t know, because all we’re left with is the notetaker’s interpretation of what the user said in the interview…
When jotting down notes, it’s important to be objective. Direct quotes are the gold standard because you receive information in your user’s words, not yours. If your interviewee grants permission, it’s always great to capture pictures, screenshots, lists, etc. to help bring your user’s story to life.
Another critical mistake when taking notes is that people will often mix in solution ideas next to raw interview data.
Feature that allows her to convert speech to text?
What’s that doing there? Interview notes are not the place to store product solutions. It’s OK to have solution ideas when talking to users, but make sure to write them down in a separate location to avoid introducing solution bias.
Your last interview is only as good as what you’re able to retain days, if not weeks or months, later so make sure to leave a trail that’s rich in data and tells your user’s story in an objective way.
Mistake #5: Asking customers what they want
You: We’re looking to make some improvements to our latest game, Battle Sketches. What do you want to see in the next version?
Interviewee: Umm… I don’t know… let me think…
<long awkward pause>
Interviewee: Oh, it’d be cool if I could… <insert super specific solution example>
Like the example above, sometimes we can be tempted to short circuit the discovery process and just ask the customer what they want. It sounds much simpler, right?
If I had asked people what they wanted, they would have said faster horses. — Henry Ford
Asking customers what they want can be detrimental to our discovery process in several ways.
- It boxes you into one solution.
- You risk not fully understanding the user’s motivation and therefor don’t get to the root of the problem.
- It’s too broad of a question and you’re likely to find everyone wants something different.
- It puts your user on the spot and you’re likely to get a sub-par answer that’s difficult to work with.
However, there’s a better way to phrase this type of question that will give you higher quality responses.
You: Imagine you’re currently playing Battle Sketches… What, if anything, would make you feel more excited to keep playing?
Interviewee: Well… I suppose after playing for a while the different game topics begin to get a little predictable which takes some of the surprise out of the guessing part of the game. It’d be awesome if we had more options there, or perhaps the players could come up with their own topic cards.
First, prime your interviewee so they can get into the right frame of mind (e.g. “Imagine you are using <feature/product>…”) Next, make sure your prompt isn’t too broad. Try to narrow it in on a specific goal (e.g. “What would make you feel more excited to keep playing?”). Lastly, limit the amount of “design work” required of them. Get rich data on the why behind their solution and stay high-level on the how — the latter is for you and your team to figure out!
Mistake #6: Acting on unvalidated problem statements
Let’s say one interviewee says:
I enjoy playing games that don’t require hours upon hours of time to see progress. It’s more fun for me to play games that are easy to pick up and put pack down.
Is this a validated problem? No, I’d argue that’s just one person’s experience. If you’re acting on one person’s opinion, you’re acting too early.
Let’s say we hear that same comment from another interviewee. What do we do then? Well… now things are getting interesting! It’s probably worth digging into that topic with future interviewees. We may want to form a hypothesis and add a question or two to our interview guide.
When you hear three or more people say the same thing, it’s highly likely that this sentiment is reflective of a large number of peoples’ experiences. Many people reading this might think, “But three people is such a small sample size! How can you trust that data?”
If three people mentioned the same comment in an unbiased interview… there’s likely something there. Just like how acting too soon to customer feedback can be an issue, the opposite — overanalyzing — can become an issue as well.
I find the sweet spot is between six to eight interviews because I can knock them all out in a couple of days and after five or six interviews I start to see plenty of patterns emerge. More than eight interviews and the data starts to become too much to synthesize efficiently. Don’t underestimate the power of small scale testing!
Closing thoughts
Understanding people can be downright tricky. Let’s face it – we humans are unpredictable. Nevertheless, armed with the wisdom of these six empathy mistakes, I’m confident you’ll be well on your way to unlocking rich insights and invaluable information about your users and their needs.
