Free · Powered by Google Gemini

Empathy Map Generator

The classic NN/g framework — says, thinks, does, feels — extended with anxieties, accessibility needs and trust signals. Generates a full empathy map from a one-paragraph description of your user.

Map a user

Describe the user, their context and what they're trying to do. The more specific the input, the more useful the output.

NN/g framework
Says · Thinks · Does · Feels Anxieties Trust

What an empathy map is for

An empathy map is a workshop artefact, not a research output. Its job is to compress what your team thinks they know about a user — across four lenses — onto a single sheet, so you can argue about the gaps. The four canonical quadrants come from NN/g's empathy mapping framework:

This generator extends the four with three additions we've found make empathy maps more useful in practice: anxieties (specific worries holding them back), accessibility considerations (so inclusion gets surfaced upstream), and trust signals (what would actually convince them to commit).

Empathy map vs persona — when to use which

Personas describe who the user is across many sessions. Empathy maps describe what's happening for them in the moment. They're complementary:

How to use the output

  1. Read it suspiciously. Anywhere you find yourself nodding along, ask: do I actually know this, or did I just like the way it was phrased? AI output sounds confident; it doesn't replace research.
  2. Mark gaps in red. Anywhere a quadrant is thin or wrong, highlight it. That's your research backlog.
  3. Pull the strongest item from each quadrant into the design brief. One says, one thinks, one does, one feels. Concrete enough that anyone could test the design against them.
  4. Run it again for adjacent moments. The same persona behaves differently when onboarding versus when failing a payment. Generate two or three maps and compare.

Why "trust signals" matters

Most empathy maps stop at feels. But the work of design is often to convert feels nervous into willing to commit — and that conversion is mediated by trust signals: testimonials, regulator badges, pricing transparency, refund language, the right photo of a real person.

By making trust signals explicit in the empathy map, the team gets pushed to ask the right downstream design question: what specifically would this user need to see, here, to feel safe enough to act? That's a much sharper brief than "make them feel reassured".

What's next

Once you've mapped the user, two natural next steps:

Map another moment.

The same persona behaves differently across onboarding, decision and failure states. Generate maps for each.

Generate the persona Map another user

When empathy maps earn their keep

Empathy maps are frequently treated as a research artefact — a deliverable you produce after interviews. That's the wrong end of the tool. Empathy maps earn their keep as a thinking artefact, not a documentation one. They force a team to distinguish between what a user says, does, thinks and feels — four categories that get flattened in most research notes into a single stream of quotes and observations.

The distinction matters because design decisions land differently depending on which category they respond to. A "says" insight ("this button confuses me") is often the surface expression of a deeper "feels" insight ("I don't trust this checkout"). A team that treats every quote as face-value input designs against symptoms rather than causes. The four-quadrant discipline surfaces the gap.

The four quadrants — how to fill each honestly

Says is the easiest quadrant and the most misused. Include only literal quotes the user actually said in interviews or in transcribed usability sessions. If the quote is paraphrased, mark it as such. "Says" that reads as a designer's interpretation of a user statement is the most common empathy-map failure mode — it launders opinion as evidence.

Does is observed behaviour, not stated behaviour. What users actually clicked, tapped, avoided, abandoned, retried. Behavioural analytics and session recordings feed this quadrant far better than interviews. If "does" is populated only from what users said they did, treat the map with suspicion — self-reported behaviour and observed behaviour diverge sharply, particularly around embarrassing or repetitive actions.

Thinks is inferred cognition. Populated from research signals — hesitation pauses, question-asking patterns in interviews, comparison shopping behaviour, tab-switching to competitor sites. This quadrant is inherently interpretive; the guard against fabrication is naming the specific evidence each thought is inferred from.

Feels is emotional register. Frustration, relief, suspicion, delight, resignation. Tone of voice in interviews, punctuation intensity in support tickets, expression captured on camera during moderated tests. The most-underused quadrant, and often the most decision-relevant — emotional friction is what drives churn even when task completion succeeds.

One map per moment, not one per persona

The most common misuse of empathy maps is producing one per persona and treating it as a lifetime portrait. Users are not consistent across contexts. The same persona onboarding a new product, hitting a payment failure, and returning for a repeat purchase inhabits three completely different emotional and cognitive states. Empathy maps produced at the persona level flatten this variance and become decoration.

Generate one map per critical moment in the journey — first purchase, first support interaction, first cancellation attempt, first upgrade decision. The maps disagree with each other; that disagreement is where design decisions live. Pair with the persona generator to establish the base persona, then map their behaviour at each critical moment separately.

Related methods

The empathy map sits alongside journey mapping (temporal view of the same user), jobs-to-be-done (functional framing of the same behaviour), and the wider UX research methods that populate its quadrants. It complements user interviews as the synthesis step and usability testing as the ongoing validation loop.

Done