Watch a Demo

Empathy Mapping for Better Digital Experiences

| December 4, 2015
Sign up to get bi-weekly insights and best practices, and receive your free CX Industry Report.
Thank you!

Get ready for some great content coming to your inbox from the team at UserTesting!


“When people talk, listen completely. Most people never listen.”

― Ernest Hemingway

Here’s a hard question: How do you listen to your users and infuse that empathy into your daily work?

After all, empathy is one of those fuzzy words that’s appealing as an idea but hard to wrangle into a tangible outcome. Somewhere between the inspiration and the code, the user’s voice—while captured—is often garbled in the final deliverable.

But what if there was a way for those of us who have to research, design, code and market digital experiences to have frameworks and tools to help us organize all the feedback into specific buckets? From these juicy bits, we could distill coherent goals that get to the heart of the logic and emotion of why users are willing to engage with our brand.

Capturing user feedback can often feel like drinking out of a firehose:

  • “Did they like that feature?” asks engineering.
  • “Did they like the fade-in on a scroll?” asks design.
  • “Will they convert?” asks marketing.

To handle this chaos, I use a framework called Empathy Mapping. It’s a simple way to actively listen when you speak with users and quickly organizing that feedback using a four-quadrant system, categorizing what these users say, think, feel and do.

For example, let’s say we’re testing a new mobile app prototype for online banking targeting mature users. We have a limited budget for creative and code and need to make sure we suss out key features for our next coding sprint. Here’s how to do it.

Step 1: Define the key question

Sit down with your team and identify one or two key questions you’d like to solve for right now. While everyone will likely have a different agenda, your goal should be to get everyone to vote on the areas in which they feel most strongly. These might not be obvious. In fact, they should be the murkiest (and thus carry the most risk for blowing up your budget or timeline).

For example, “What are the three things a user between the age of 50 – 65 would want to do—with one hand—on our mobile banking app while they’re standing in line at a coffee shop?”

A real life scenario might look something like this:

A user aged 55 with arthritis wants to login to our app using their thumb and check the balance of their bank account, transfer funds, and see scheduled payments while standing in line for coffee.

Note: Stating the context in which this experience will occur is actually a subtle detail that has big implications. A coffee line is filled with distractions and people jostling, but it’s often where most of us fit in our small tasks throughout the day.

Having a solid question with parameters will help you focus and ensure buy-in from everyone on the team.

Step 2: Assemble your script

If you’re using a research tool like UserTesting or running UX studies in person, it’s absolutely critical to have a tight script written out in advance. You want to think through:

  • Who you want to test (age, gender)
  • What you want to know (completing a task or reacting to a design)
  • Why they answer (include prompts why did you do this? Why do you feel that way?)

Pro tip: Be extra explicit in your instructions. If you were running a user test for the example above, you might want to assure users in the first step that you don’t want to observe their personal banking mobile experience. Remind them that you’re just testing  ideas and want to learn what they feel is broken or could be easier.

Step 3: Run a pilot and then a full test

I recommend running  a minimum of one or two pilot tests prior to running a full study. This can often be done offline with a casual friend or family member. Just make sure they fit your demographic and technology savviness for your target market to ensure consistency.

Conduct the test as you would with any other participant, and remember to avoid bias and resist your urge to coach your participants.

You’ll be surprised by what parts of your test script you feel are straightforward, yet to a participant they’re slightly confusing and, as a result, they begin going down the wrong path with their feedback.

So be sure to find the kinks and blind spots and adjust your script accordingly. Always refer back to your one big question to make sure you are getting at the information you need to make product feature or design decisions.

Step 4: Synthesize the data

Here’s where most people lose their steam. Quite a bit of work can go into Steps 1-3, and many people tend to think that once they’re done, they’ve checked the box for testing they’re ready to dive into design or code. Yet, there’s a bit more work to be done to mine the data for key insights.

This can feel daunting and you might be tempted to quickly flip to specific parts of your tests and not take in the whole experience.

But as Hemingway says, “Most people never listen.” However, it’s by listening to the feedback and synthesizing the data that you come up with insights that help you move the needle.

Here is where the art of active listening comes in. Empathy Mapping provides a framework for synthesizing the data, and this is where your true signals lie—between emotion and logic. Our goal is to separate this from the noise of “I don’t like that image” to the real gems of “Oh, I love feature X and use a similar feature every day in another app.”

To achieve this, we need a systematic approach to organizing all the comments from our user interviews.

Step 5: Create Your Empathy Map

An empathy map walks you through a handy framework for organizing all your users’ feedback into four simple squares: say, think, do, and feel.

Screen Shot 2015-12-04 at 1.15.36 PM

Source:‘s Empathy Map

Before moving forward, take a moment to refresh your team on your objectives, and what outcomes would be considered a success. In our example, this might be something like this:

A mature user with arthritis can log in to our app using their thumb, check the balance of their bank account, transfer funds, and see scheduled payments while standing in line for coffee.

How to do it

Grab a pack of Post-It notes and off to the side of the canvas give each of your testers their own color. Each tester will have a corresponding color code on the map which makes it much easier to attribute and understand who said what.

I’d also suggest printing out a large copy of the empathy map and hanging it up in a conference room or even against a window. ( You can get your own copy of’s empathy map for user feedback here.) Get you and your team up and moving as you watch the tests and organize the feedback. It makes for a much more fun experience to synthesize the qualitative data this way.

The four buckets of say, think, feel, and do mirror what users do when they go through an experience. This simple rubric becomes quite powerful because it gives you a system to organize all their behavior and comments in a highly visual way.


This is where we capture the feedback like “I don’t like that image”. Consider this a place to park feedback and tidbits from the user’s stream of consciousness. Not everything has to go here but if you think it’s interesting jot it down on a PostIt.


The “Think” part tends to reveal a bit about a user’s beliefs and the logic with which they approach the experience. For example, say one tester has security concerns and doesn’t want to use a mobile banking app. We’d capture “security issues for financial info on mobile”. That could be a key insight—especially if other testers also express this concern—and may  be a clue on whether or not this market is ready for such technology


This quadrant focuses on how users experience the app or website directly. We might notice how many times they attempted to log in, as well as  remarks like, “Ugh, I can never remember my password and hate resetting it on mobile.” Or they log in and go to the wrong part of the app such as “Settings.”

We’re just trying to capture their behaviors and actions in an impartial way. Make notes like “Login button -> password reset -> user would go out of the app and into Gmail,” to capture their actions. Bonus points for sketching these interactions.


Here’s where the real listening happens. Your goal is to read between the lines and empathize with how their emotions fluctuate throughout their experience. If the app surprises them with its ease-of-use or remarkable utility, you know you’re on to something.  “Wow, I can transfer money with two swipes and don’t have to put on my glasses to do it? Love this!”

Remember, people will buy on emotion and backfill with logic. The empathy map helps you zero in on this. No emotion = no logic = no adoption.

Putting This Into Action

At the end of all the mapping, take a step back and observe the colors. Did one tester provide tremendous insights as evidenced a ton of lime-green Post-It notes plastered all over the map? If so, she might be someone you can rely on going forward as a power user.

Next, step away for a day or two and let all this percolate in your mind. Your subconscious mind will chew away on the feedback, and the rest will make distilling your key insights a bit easier.

Finally, return to the map and begin the distillation process. While every comment may not be relevant, you might notice a few trends where users are constantly saying, “I hate logging into mobile financial apps,” and you can begin to see where your experience could improve.

Mobile Hack

Another way to gather additional insights is to check out the app reviews and add that add that feedback to your Empathy Map as well. For speed, we tend to recommend looking at the best and worst mobile apps for your space. These “extreme cases” actually tend to yield the best insights.


via Google Play


Executing on Empathy

We’ve found that after running as few as five tests, we have enough insight to answer 80% of the question. And in an agile word this is usually enough to run another sprint. It’s easy to get fixated on getting perfect clarity on an issue before iterating, but over time this approach has diminishing returns with a real cost to time and budget.

So instead, return to the key question you defined in step 1. In our case it was:

What are the three things a user between the ages of 50 – 65 would want to do, with one hand, while standing in line at a coffee shop?

The empathy map will help you zero in on the following:

  • Are we solving the right problem?
  • Does our current experience elicit positive emotions?
  • How do people perceive the value?

While talking with humans can sometimes be a messy and confusing experience, using this kind of methodology helps tremendously with active listening. Instead of sifting through hours of video or transcripts and dumping the findings into a PowerPoint deck, you actively create a visual representation that captures actionable data and reveals the key insights directly from the users themselves.

Synthesizing this data suddenly becomes something you’ll look forward to and that the team can enjoy together. You’ll find yourself speaking in terms of the users themselves. For example, “Tester X is nervous about mobile security. We need a way to assure him his data is safe.” Teams advocate on behalf of the people they feel they have a personal connection with.

And that’s what great digital experiences are all about: designing and building technology with heart. It’s at the core of today’s best brands, not to mention it makes your job infinitely easier.

A parting note

Henry Ford famously said, “If I’d asked people what they wanted they would have said a faster horse.” Those who doubt human-centered design often believe that true innovation happens independently of users through a sole visionary founder. They claim ordinary people cannot articulate what’s possible with technology nor define it for use within their daily lives. To them, we’re all just wasting our time trying to spend time with users if we truly want to develop leapfrog innovations.

But if we rewind the clock to the experience Henry Ford was designing for, it comes down to one simple thing: users said they wanted to go faster. And while they might not have envisioned a Model T, they certainly knew the challenges of the horse and buggy and could speak to the pain points around that experience.

The same is true for the iPhone. People carried an iPod, a GPS for driving, a laptop for computing tasks and a clunky flip phone for calling or texting. Not to discredit Apple’s engineering and design prowess, but observing and speaking with users you can imagine how Apple quickly saw that there was a hungry market to carry one device that could deliver on all the above with seamless functionality. The problem was thus clearly defined by their behaviors and habits. Users don’t care how we build these experiences. They just want to accomplish their goals.

Gathering feedback will only get you so far. Having empathy for your users and using that to guide your design decisions empowers you to truly listen to what your users want and need.