Transform
Published in

Transform

Top Product Pitfalls To Avoid — Empathy (Part 1 of 5)

Things can go wrong when we attempt to walk a mile in their shoes.
Things can go wrong when we attempt to walk a mile in their shoes.

Intro — Welcome to a new series!

In this five-part article series, we’ll dive deep into the Design Thinking process and talk about the most common pitfalls that even the most advanced designers and product managers fall victim to and how you can avoid them.

No matter how advanced you are in your career, my hope is that after reading this you’ll walk away with a new learning or way to improve your existing process. I’d also love to hear your feedback or additional advice in the comments!

Don’t worry, this is not another one of those “How to follow the design process” articles. Although helpful, those resources rarely equip you with the skills to handle all the little nuances and challenges that emerge whilst in the trenches of building products at a real company.

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. Let’s take a step back to examine and understand the most common mistakes people make throughout the Design Thinking process in order to avoid making them ourselves.

The design thinking process in stages.
The Design Thinking process split out into stages.

Stage I: Empathy

In a nutshell, empathy is our attempt to see the world through another person’s eyes and equip ourselves with the necessary information to solve their problems in a natural and meaningful way. Let’s walk through the top six pitfalls people fall into during the empathy stage.

Pitfall 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.

Creating an artificial funnel can produce biased results
Giving away too much context may box people into a stereotype or set of responses.

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.

Pitfall 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.

Use the 7 second rule before prompting your interviewee a second time.
Use the 7 second rule before prompting your interviewee a second time.

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.

Pitfall 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.

When fishing for insights, remember, often times insights are a few layers deep! Keep going!
Remember, often times insights are a few layers deep! Keep going!

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?”

Pitfall 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.

Quotes, pictures, and files help bring your interview notes to life.
Quotes, pictures, and files help bring your interview notes 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.

Pitfall 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? We’d probably save time too! Well, as Henry Ford says, “If I had asked people what they wanted, they would’ve said a faster horse.”

Henry Ford daydreaming about a faster horse.
Taking customer feedback at face value poses a risk of building a faster horse.

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!

Pitfall 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 say the same thing there’s likely something there!
If three people say the same thing there’s likely something there!

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 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!

The end of our journey… for now!

Understanding people can be downright tricky. Let’s face it – we humans are unpredictable. Nevertheless, armed with the wisdom of these six empathy pitfalls, I’m confident you’ll be well on your way to unlocking rich insights and invaluable information about your users and their needs.

The design thinking process

Now that we have a pile of rich insights and data, how do we package it all up into a crisp problem statement that’s ripe for a solution? Well, stay tuned for the next article… because it’s time to move over to the define stage!

--

--

--

Thoughts and ideas from practicing designers, brought to you by Snapdocs Design

Recommended from Medium

Tips for Running a Remote Research

Is Legal Design Bullsh*t?

Types of Dimensions in an Engineering Drawing

Redesigning the toggle switch

CREATIVE CODING

CDF Project 3, Part 2

Everyday UI: Mismatched Faucet Handles

Creating Better Typographic Hierarchy

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Chris Pokrzywa

Chris Pokrzywa

Lead Product Designer at Snapdocs, helping build the connective network for residential real estate.

More from Medium

Another Case Study About Information Architecture

Designing a meaningful product

Designing an inclusive vaccine registration platform

The key to a solid foundation for any digital product