How to Create an Empathy Map for UX Research

TL;DR: What You Will Learn

• An empathy map is a visual tool that synthesises user research into one shared picture of your user.
• Its four core quadrants are Says, Thinks, Does, and Feels, often with Pains and Gains added.
• The flow is simple: gather research, fill the quadrants, then convert patterns into actionable insights.

Let us start with what an empathy map actually is, and why it works so well.

What an Empathy Map Actually Is

Let me start with the simplest possible definition. An empathy map is a collaborative visualisation that pulls everything your team knows about a user into a single frame, usually split into what the user says, thinks, does, and feels.

It is less a report than a shared picture something a whole team can gather around, point at, and argue over in the same room.

The tool was popularised by Dave Gray and his team at XPLANE, and it has stuck around because it does one thing very well: it forces scattered research notes into a coherent, human-shaped summary that anyone can read in thirty seconds.

The Nielsen Norman Group frames the tool by its purpose rather than its shape. In their widely referenced primer Empathy Mapping: The First Step in Design Thinking, Sarah Gibbons describes it as a way to externalise what a team knows about a user, so the group can build a shared understanding of user needs and make better decisions together. NN/g also offers a sharp diagnostic that pairs well with everything below: a sparse empathy map is a sign that more research still needs to be done. In other words, the gaps in the grid are as informative as the notes that fill it.

Here is a Singapore scenario I like to use. Imagine a GovTech-style team building a municipal services app for HDB residents, the kind of app you would use to report a faulty lift or a choked rubbish chute.

The team maps a single resident, say an elderly Ang Mo Kio uncle. In the “says” quadrant: “I don’t know which town council handles this.” In “feels”: frustrated, a little embarrassed to ask. Suddenly, the design problem is obvious in a way a spreadsheet never made it.

How it Differs From a Persona

People confuse these two constantly, so let me be blunt about it.

A persona is a fictional profile: name, age, job, goals, a stock photo. An empathy map is a lens into one person’s inner and outer world at a moment in time.

Where a persona tells you who the user is, an empathy map gets at what it actually feels like to be them. In practice, I build the empathy map first from raw research, then distil a persona out of it, not the other way round.

Where it Fits in the Double Diamond

If you follow the double diamond design thinking process, the empathy map lives firmly in the first diamond, the Discover and Define stages.

It is a synthesis tool for the research you have already gathered through interviews or observation. You use it before you commit to solutions, which is exactly why it complements rather than replaces other artefacts. If you are still fuzzy on where research sits, it helps to be clear on the difference between UI and UX first.

When to Use One Versus a Journey Map

Reach for an empathy map when you want depth on a single user’s mindset at one moment. A journey map is the better call when you need to trace that same user across time, step by step through the whole experience of, say, booking a polyclinic appointment.

The best part is the cost. You do not need fancy software: a stack of sticky notes on a meeting room wall or a free Figma board works perfectly, which makes this one of the cheapest, highest-return exercises any Singapore team can run.

Understanding the Four Quadrants

When I first started running research sessions, I treated the empathy map as a box to tick. It was only when I started paying attention to the tension between the quadrants that the tool actually earned its place in my process.

The classic version splits your user into four zones: Says, Thinks, Does, and Feels. Newer versions add a footer for Pains and Gains, which I find pulls everything together neatly.

Says and Does

Says captures the actual words your user uses, ideally quoted verbatim from an interview. Does records the behaviour you observe, not what they claim to do.

Picture a daily commuter using the SimplyGo transit payment system. When I ask how the app is, he shrugs and says it is “fine”, so into the Says quadrant that goes.

But watch him in the wild and a different story appears. He opens the app to top up his card, taps around for a moment, then closes it and just taps his physical card instead.

That abandoned top-up belongs in Does. The gap between a shrugged “fine” and an abandoned action is where your real insight lives. Grounding your map in observed behaviour keeps you honest, because people are often unaware of their own workarounds.

Thinks and Feels

Thinks holds what your user believes but may not say out loud, often because it feels awkward or disloyal. Feels captures their emotional state: anxious, frustrated, relieved, or indifferent.

For our SimplyGo commuter, Thinks might be “I am probably doing this wrong” or “I do not trust the balance shown”. Feels might be a quiet flush of embarrassment at fumbling with the app while others queue behind him.

Notice that Says and Thinks can directly contradict each other, and that contradiction is a gift. Someone who says everything is fine but privately assumes the fault is theirs is telling you the product has an unaddressed usability problem.

Pains and Gains

Pains are the obstacles, fears, and frustrations standing in the way. Gains are the wants, needs, and measures of success your user hopes for.

The hidden pain here is not “the app is bad”. It is that topping up feels effortful and uncertain, so he avoids it entirely and risks getting stuck at a gantry with a low balance.

The gain is straightforward: a fast, trustworthy top-up he can complete without breaking his commuting rhythm.

I always tell teams I coach in Singapore to hunt for these contradictions deliberately. When what someone says clashes with what they do, or their calm words hide an anxious feeling, you have found the richest material an empathy map can surface.

Gathering the Right Inputs Before You Map

Here is the hard truth I share with every team I coach: an empathy map is only as accurate as the research feeding it. Fill it with assumptions, and you have just documented your own bias in a nice quadrant grid.

So before you draw a single box, gather real inputs from real users. I lean on five sources: user interviews, contextual observation, support tickets, surveys, and product analytics. Each one tells you something the others cannot.

Qualitative interviews and observation

Interviews are where you hear the actual words users use, and those words later fill the “Says” quadrant beautifully. I always record what people say verbatim rather than paraphrasing into marketing speak.

Contextual observation adds the layer interviews miss. Watching someone fumble through your checkout on a slow mobile connection while juggling a toddler tells you more about their pain than any survey ever will.

If you are building this skill and want to see how hiring managers probe for it, these UX designer interview questions show the kind of research thinking employers expect you to demonstrate.

Behavioural Data

Analytics and surveys give you the scale that qualitative work cannot. Where do users drop off, which pages do they bounce from, and what does the search log reveal about intent?

Support tickets are gold here, and they are usually sitting untouched. Take a small e-commerce SME selling on Shopee: before mapping their buyer, they should read six months of customer service chat logs and product reviews. Patterns emerge fast, like repeated confusion over delivery timelines or sizing, which feed straight into the “Pains” quadrant.

One firm reminder. Under the PDPA, anonymise personal data before it lands in a shared map, and get consent if you plan to quote a real customer’s words. Strip out names, phone numbers, and order IDs. Treat every quote as personal data until you have proven otherwise.

Existing Internal Knowledge

Do not overlook what your own team already knows. Sales, customer service, and account managers speak to users daily and carry a mental model you can mine in an afternoon workshop.

That said, internal opinion is a starting point, not evidence. Use it to form hypotheses, then validate against actual interviews and data so you are not just mapping the loudest voice in the office.

Finally, scope tightly. Build one empathy map for one specific user segment, never a vague “everyone”. A map for “first-time Shopee buyers aged over 50 who abandoned checkout” will guide real design decisions. A map for “our customers” will guide nothing at all.

Building the Map Step by Step

An empathy map falls apart when a team jumps straight into filling quadrants without agreeing on who they are mapping. So before anyone touches a sticky note, I always lock down two things: the goal of the session and the specific user we are focusing on.

Let me walk you through a realistic scenario. Picture a Singapore fintech launching a new savings app, running a 60-minute remote workshop on FigJam with product, design, and two customer support staff who take calls all day. That mix matters, because support hears the frustrations no dashboard captures.

Set the Goal and Prepare the Template

I open by stating the goal in one sentence: “Understand why first-time users abandon the account verification step.” Then I name the user, for example, a 28-year-old gig worker verifying identity on their phone during a lunch break.

Next, prepare the template before people arrive. In FigJam or Miro, you can drop in a ready-made empathy map frame with the four quadrants (Says, Thinks, Does, Feels) already labelled.

If your team is co-located, physical sticky notes on a wall still work beautifully, and something is energising about people moving around. But for remote or hybrid teams and most Singapore teams are hybrid now FigJam and Miro let everyone contribute at once without crowding a whiteboard.

If your designers are still finding their feet in these tools, point them to a step-by-step Figma tutorial for beginners so the tool never becomes the bottleneck during a live session.

Dump Observations, Then Cluster

Now, the working part. Give everyone five to seven minutes to silently dump observations onto sticky notes, one insight per note. This is non-negotiable, because a note that says “user is confused and clicks around and gives up” is impossible to cluster cleanly.

Wherever you can, use real user quotes verbatim. If a support agent remembers a caller saying “I don’t get why you need my payslip too,” that goes on a note exactly as spoken, in quote marks. Raw language keeps the map honest.

Then move to clustering. As a group, drag related notes into the four quadrants and stack duplicates. This is where patterns surface, like several notes clustering under “Feels” around anxiety about sharing income data.

Keep the whole thing tightly timeboxed. Here is the sequence I use for a 60-minute session:

1. Goal and user alignment (5 minutes)
2. Silent note dump (7 minutes)
3. Clustering into quadrants (15 minutes)
4. Group discussion and themes (20 minutes)
5. Capture next steps and open questions (13 minutes)

Facilitate so Quieter Voices are Heard

Discussion is where dominant voices take over, so I actively facilitate. I go quadrant by quadrant and directly invite the support staff to speak first, since they hold the frontline evidence but often defer to product managers.

A quick trick on FigJam: use anonymous or private cursors during the dump so people are not influenced by their manager’s notes. Then reveal everything at once.

Solid tool habits make this smoother, and reviewing Figma design basics every beginner should master helps your team run the whole workshop without friction.

Turning a Filled Map Into Real Insights

A wall covered in colourful sticky notes feels productive, but it is not the finish line. The real work of an empathy map starts when you stop capturing and start interpreting.

I always tell my teams: the map is a mirror, not an answer. Your job now is to read what it reflects and turn scattered observations into something you can actually design for.

Identifying Contradictions

The richest insights usually hide in the gaps between quadrants, especially between Says and Does.

Picture a team building a healthcare appointment app for elderly patients in Singapore. In the Says quadrant, users insist they trust the app and find it easy. But in the Does quadrant, the team observed the same users pausing, then calling their daughter to confirm the booking went through.

That mismatch is gold. It tells you the confidence they voice out loud does not match the behaviour you watched, which means the trust is fragile, not real.

When you spot a contradiction like this, resist the urge to pick a side. Instead, ask what tension the person is living with, because that tension is where an unmet need is usually buried.

Extracting Needs

Needs are verbs, not solutions. Someone does not need a bigger confirmation button; they need to feel certain their appointment is secured without asking anyone for help.

Go back through your quadrants and, for each pattern or contradiction, write the underlying need as a short human statement. For the healthcare example, the need might be: reassurance that the task is done, on their own terms.

Watch out here for over-interpreting thin data. If only one participant said something once, treat it as a hunch, not a finding, and note it as something to validate.

Two data points make a coincidence, not an insight, so be honest about how much evidence actually sits behind each need before you act on it.

Writing How Might We Questions

Once you have a clear need, reframe it as a How Might We (HMW) question. This turns a problem into an open invitation for ideas.

For elderly healthcare users, a strong HMW would be: How might we help older patients feel confident their booking is confirmed without needing to call a family member?

Keep your HMW statements at the right altitude. Too broad (“How might we help elderly people?”) gives you nothing to design against, while too narrow (“How might we add a green tick?”) smuggles in a solution before you have explored options.

Aim for three to six sharp HMW questions from a single map, then take them into ideation. Just remember that every one of them is still a hypothesis, so plan follow-up interviews or usability testing to confirm you read the map correctly before you commit engineering time to it.

Using Empathy Maps Across the Design Process

The biggest mistake I see teams make is treating the empathy map as a workshop artefact that gets photographed, filed away, and never opened again. That is a waste, because the real value comes from letting it work quietly across every later stage of your process.

Feeding Personas, Journey Maps, and Prioritisation

I use the completed map as raw material for the artefacts that come next. The Says and Thinks quadrants often become the backbone of a persona, while the Pains quadrant points directly to the friction moments I need to plot on a journey map.

When it comes to prioritisation, the map keeps me honest. If a proposed feature does not address a documented pain or gain, I have to ask why we are building it at all.

The map turns feature debates from opinion battles into evidence-based conversations.

A Singapore Banking Scenario

Picture a local bank redesigning its mobile onboarding flow. The team runs research with new-to-bank customers and builds an empathy map that surfaces a recurring pain: users abandon the flow during a lengthy Know Your Customer (KYC) step because it feels intrusive and slow on a phone.

In the next sprint planning session, a product owner wants to add more verification fields to reduce fraud risk. The empathy map sits on the shared Miro board, and the designer points to the Pains quadrant to argue for simplifying the KYC step instead, perhaps by using Singpass Myinfo to pre-fill details rather than asking users to type everything manually.

That single artefact aligns the compliance officer, the product owner, and the designer around what the customer actually experiences, not what each stakeholder assumes.

Keep It Visible and Revisit It

I keep the map somewhere the team walks past every day, whether that is a physical wall in the office or a pinned board in Figma or Miro. In design critiques, I open it before we discuss any screen so feedback stays anchored to user reality rather than personal taste.

An empathy map is never truly finished. As new research arrives, from usability tests, support tickets, or fresh interviews, I update the quadrants so the artefact reflects what we know now, not what we assumed six months ago.

This habit is really the design thinking mindset in miniature: empathise, define, then let those insights shape everything downstream. It is also the kind of evidence-based storytelling that separates strong portfolios from weak ones, which is one reason why UX designer job applications get rejected so often comes down to candidates who show pretty screens but cannot explain the user insight behind them.

So treat your empathy map as a living reference point. When you can trace a design decision back to a documented pain or gain, you are no longer defending choices; you are explaining them.

Common Mistakes That Weaken an Empathy Map

I have seen brilliant teams build a beautiful empathy map and still ship the wrong thing. The template is easy. Using it well is where most people slip.

Let me walk you through the mistakes I keep running into, so you can sidestep them.

Filling the Map From Assumptions, Not Research

The most common trap is treating the empathy map as a brainstorm. You gather the team, everyone shouts out what they think users feel, and someone dutifully sticks it under the “Feels” quadrant.

That is not research. That is a room full of guesses wearing a research costume.

I once worked with a Singapore transport startup that wanted to help commuters during peak hour. The team sat in an air-conditioned office and mapped what they assumed MRT riders felt: bored, so give them content to read.

They shipped a feature around that assumption. It flopped. When they finally rode the trains and observed people during a packed evening rush, the real friction was physical, not boredom. Commuters were wedged in with no free hand, worried about missing their stop, and stressed about connections. The genuine pain was never entertainment.

Grounding the map in observed behaviour and actual interview quotes would have surfaced that in an afternoon.

Mapping Too Broad An Audience

The second mistake is trying to map “all our users” on one canvas. When you blend a first-time buyer, a power user, and a reluctant colleague forced to use your tool, every quadrant turns into mush.

A useful empathy map represents one persona doing one thing. If you find yourself writing contradictory notes side by side, that is your signal to split the map.

Keep each map focused on a specific person in a specific context, tied to a specific research question you set out to answer.

Treating it as a One-Off Deliverable

The third pitfall is treating the map as a document to finish, file, and forget. Teams tick it off, celebrate, and never look at it again.

An empathy map is a thinking tool, not a trophy for your project wiki.

I always date my maps and note the research round they came from, so six months later I know whether the insight is still fresh or needs revisiting after new interviews.

Skipping the insight step

Finally, many people stop once the quadrants are full. They forget the whole point: to step back and ask what this reveals.

The map is raw material. The value comes when you look across it and name the tension or unmet need, then feed that into a design decision.

Do not skip that step. Fill the quadrants, then pause and mine them for the one insight worth acting on.

Conclusion

Remember where we started: a Singapore team huddled over a whiteboard, arguing about what users “probably” want, with three people quietly building on their own guesswork.

An empathy map cuts through that. It is a fast, low-cost way to take messy interview notes, support tickets, and observation data and pull them into one shared picture the whole team can point to.

That is its real power. When you can say “our user said this, so they feel that”, the debate stops being about opinions and starts being about evidence.

The four quadrants (Says, Thinks, Does, Feels) only work when you interpret them with discipline. Separate what you actually heard from what you inferred, flag the gaps, and let the pains and gains push you toward concrete design decisions rather than vague sympathy.

You do not need a big study to begin. Take your next project this week, gather even three or four real conversations, and run a small map with your team over a single lunch session. You will be surprised how quickly the loudest assumptions fall away.

An empathy map is one tool, though. To use it well, you need the wider foundation of user research, personas, journey mapping, and interface design that turns insight into interfaces people can actually use.

If you want to build that toolkit properly and practise it on real briefs with feedback, the Certified UX Designer (CUXD) 2.0 is built to take you from doing exercises like this one to leading them in a professional design role. It is the logical next step from reading about the craft to getting hired for it.