Empathy Map in Product Research

Building the right product starts with understanding the person who will use it. Not just what they need functionally, but what they feel, what they say out loud, and what they actually do when nobody is watching.

An empathy map is a simple tool that captures all of this in one place. Here is how it works and how to use it.

Key Takeaways

• Empathy maps capture the full user picture: they go beyond needs and pain points to include what users feel, say, think, and do in relevant situations.
• They are built from real research: an empathy map based on assumptions is a fiction. It needs interviews, observations, or behavioral data to be useful.
• They align the whole team around the user: sharing an empathy map helps engineers, designers, and marketers develop the same understanding of who they are building for.
• They complement personas, not replace them: a persona describes who a user is. An empathy map shows how they experience a specific situation.
• They are best created collaboratively: involving the full team in building the map creates shared empathy rather than one person's interpretation of user research.
• They should be revisited as you learn more: an empathy map built during discovery will often need updating after additional user research reveals new insights.

What is an Empathy Map in Product Research?

An empathy map is a visual tool in product research that captures what a specific user thinks, feels, says, and does in a particular context. It is used to build shared team understanding of user experience beyond surface-level needs and pain points.

The standard empathy map is divided into four quadrants: Think and Feel, Hear, Say and Do, and See. Some versions also include Pain and Gain sections at the bottom.

• Think and Feel: captures the user's internal emotional state, worries, and what matters most to them in the relevant situation.
• Say and Do: documents what the user says out loud and how they actually behave, which often differs from what they think and feel.
• See: describes what the user observes in their environment, including what they see others doing and what influences their perception.
• Hear: captures what the user hears from colleagues, friends, media, or other sources that shapes how they think about the problem or situation.

Understanding how empathy mapping fits within a broader user research practice helps teams use it at the right moments in product development rather than treating it as a standalone exercise.

How Do You Create an Empathy Map?

Create an empathy map by gathering user research data first, then filling in each quadrant with direct observations, quotes, and behavioral insights. Avoid filling it with team assumptions. Every entry should trace back to something a real user said, did, or felt.

The process is collaborative and takes roughly two to three hours with the full product team when done well.

• Start with research, not assumptions: conduct user interviews, observe users in context, or review existing research before drawing anything on the map.
• Use direct quotes in the Say quadrant: real words from real users are more powerful than paraphrased summaries that can distort the original meaning.
• Note contradictions between quadrants: when what a user says differs from what they do, that gap is often the most important insight on the entire map.
• Build it as a team activity: have each person add their own observations to each quadrant, then discuss patterns and disagreements as a group.

How Does an Empathy Map Differ from a Persona?

A persona describes who a user is, including their background, goals, and characteristics. An empathy map describes how a specific user type experiences a particular situation. Both are useful, and they work best when used together.

Teams often confuse the two because both tools describe users. The distinction is important because they answer different questions.

• Personas answer who: they give a user type a name, role, background, and set of long-term goals that remain consistent across situations.
• Empathy maps answer how: they show what a specific user experiences in a specific moment, which changes depending on the context being explored.
• Personas are stable reference documents: you might update a persona twice a year. An empathy map might be created fresh for each major research question.
• Use the persona to scope the empathy map: start with your persona, then create an empathy map for a specific situation that persona faces in your product.

When Should You Use an Empathy Map?

Use an empathy map at the start of a new product or feature discovery phase, when the team disagrees about user motivations, or when user research reveals behaviors that contradict the team's existing assumptions. It is most valuable before important design or roadmap decisions.

Empathy maps are most useful when there is meaningful uncertainty about how a user experiences a specific situation. They are less useful when the team already has strong shared understanding.

• At the start of discovery: before designing a new feature, create an empathy map to ensure the whole team understands the user's context before solutions are proposed.
• When research contradicts assumptions: if user interviews reveal unexpected behaviors or feelings, an empathy map helps the team process and align on the new reality.
• Before major design decisions: when choosing between different UX directions, grounding the decision in an empathy map ensures the choice reflects the user's actual experience.
• To onboard new team members: sharing empathy maps with designers, engineers, or stakeholders joining mid-project gives them fast context on who the team is building for.

At LOW/CODE Agency, we have helped 450+ clients build and scale digital products. Our clients include global brands like Medtronic, American Express, Coca-Cola, Zapier, and Sotheby's.

Conclusion

An empathy map is one of the most effective tools for turning user research into shared team understanding. It captures the full complexity of how users experience a situation in a format that every discipline on the product team can engage with.

The value is not in the document. It is in the conversation the team has while building it together, which often reveals misaligned assumptions before they become expensive design mistakes.