Turn scattered research into a question worth answering
An administrator pauses before each invitation and checks a spreadsheet. Brook Workspace’s team watches the task and writes “doesn’t trust us.” That explanation might be right. It might also be a confident guess hiding a much narrower problem. The next design depends on telling those apart.
Brook Workspace is a hypothetical collaboration product. Its administrator, task session, reported concerns, and research notes below are invented for this walkthrough.
An empathy map organizes what you know about a user in a situation. The four-part version described by Nielsen Norman Group uses Says, Thinks, Does, and Feels. It helps a team examine words, behavior, and interpretations together.
Separate what happened from what you think it means
In the fictional task, checking the spreadsheet is observed behavior. Concern about granting wrong access is reported. Distrust is the team’s interpretation. These notes can all be worth keeping, but they do not have the same evidential status.
The question becomes what the administrator needs to know before sending an invitation. An empathy map puts words, behavior, possible thoughts, and feelings beside each other while preserving the gaps. It should make unsupported certainty harder, not give it four colored boxes.
Keep evidence attached
One user group · One situation · Research evidence
Reported words
Says
Preserve an exact quote or mark a paraphrase and its source.
Reported or inferred
Thinks
Record reported thoughts; label interpretations as inferences.
Observed or reported behavior
Does
Distinguish what you saw from what someone described doing.
Reported or inferred
Feels
Keep the emotion and context, with uncertainty visible.
The user and the situation anchor all four parts. Says records reported words; Does records behavior. Thinks and Feels capture the person’s reported thoughts and emotions, or clearly marked interpretations. The quadrants may overlap. Their purpose is to aid understanding rather than force every note into one perfect category.
FrameworkWorld recommends giving every note a source reference and an evidence label. Use observation for behavior you saw, reported for what a participant told you, and inference for an interpretation. A statement about behavior in an interview is reported behavior, not a direct observation.
For Says, use an exact quotation only when the research record contains those words. Otherwise write an attributed paraphrase. For Thinks and Feels, avoid claiming access to a person’s inner state. Ask about it, and preserve uncertainty when the answer is unknown.
These distinctions matter when notes conflict. A participant may praise a workflow but abandon it during a task. The discrepancy is a question to investigate, not proof that the person is dishonest or that the researcher knows the answer.
Give each quadrant the right kind of note
Says records words from the participant. Use a quotation only when you have the exact wording. A useful paraphrase is fine, provided it is presented as one and linked to the original record.
Does captures behavior. “Checked the spreadsheet before each invitation” is something an observer might see. “Always checks the spreadsheet” requires broader evidence. Keep the scope of the claim as small as the observation supports.
Thinks can include thoughts the person reported and interpretations the team wants to investigate. Make the difference visible. “Believes the product is unsafe” is a much stronger claim than “may be unsure about access rights.”
Feels records reported emotion or a carefully labeled inference. A pause can reflect anxiety, concentration, confusion, or an interruption elsewhere. The map gives you a place for the question; it does not give you access to someone’s mind.
The same source may inform more than one quadrant. Avoid treating duplicated notes as multiple pieces of independent evidence. Keep source references and participant differences visible so a repeated sticky note does not become a stronger finding by accident.
Think of the map as a shared reading desk. The original research remains the material on the desk; the four labels help people examine it without replacing it.
Watch Brook’s interpretation become testable
During a simulated invitation task, an administrator checks a spreadsheet before adding each colleague. That goes under Does as an observation. The participant explains that she wants to avoid granting the wrong access; this is a paraphrase under Says, not a fabricated quotation.
The team initially writes that she distrusts the product. It relabels that note as an inference under Thinks because the session did not establish distrust. When asked about the pause, the participant reports uncertainty about which permissions an invitation grants. That reported uncertainty belongs under Feels, with a reference to the session note.
Instead of designing a more persuasive invitation banner, the team prototypes a preview of access rights. It plans another task session to observe whether administrators can explain the permissions before sending. The map helped change a messaging assumption into a testable comprehension question.
The next session may still show hesitation for a different reason. A map of one situation does not explain every administrator’s behavior.
Watch an interpretation become testable
| Note from the hypothetical session | Evidence status | What it permits you to say |
|---|---|---|
| Administrator checks a spreadsheet | Observed behavior | A check occurred before invitations |
| Administrator explains concern about wrong access | Reported, paraphrased | Access accuracy matters in this account |
| The team writes “distrusts the product” | Inference | Distrust is a hypothesis to investigate |
| Administrator reports uncertainty about permissions | Reported experience | Permission meaning needs clarification |
Keeping the status attached changes the design discussion. The team can test an access-rights preview without declaring that it has solved a broad trust problem. It asks whether an administrator can explain the permission consequences before sending an invitation.
In the next session, the researcher watches the behavior and asks follow-up questions without prompting the expected answer. If the participant still checks a spreadsheet, the team investigates what the spreadsheet supplies. It might contain organizational rules the product cannot infer.
A useful map also preserves disagreement. If another administrator understands the permissions immediately, compare circumstances and experience instead of averaging the two accounts into a fictional typical user. Separate maps may be more informative.
When sharing the synthesis, retain enough source context to check it while protecting unnecessary personal information. A colleague should be able to see why a conclusion was reached without receiving every identifying detail from the session.
End with a question, owner, and proposed evidence. “Explore a preview and check permission comprehension in the next task session” is something a team can act on. “Users need confidence” is still too broad to design or evaluate.
Choose a task that could disprove the interpretation
Brook prototypes an access-rights preview and asks an administrator to explain the permissions before sending. The researcher observes the task and follows up without supplying the expected explanation.
If spreadsheet checking continues, the team investigates what the sheet provides. It may contain organizational rules that a permissions preview cannot supply. That result would change the hypothesis. The map has guided a comprehension test without pretending to diagnose every user’s trust in the product.
Build a map from research
- Name the user group and situation, such as a first-time administrator inviting colleagues. Avoid an unbounded map of “all customers.”
- Collect relevant interview and observation records. Follow the permissions and handling rules agreed for that research.
- Extract one idea per note. Keep a reference to the original evidence without exposing unnecessary personal information in the shared map.
- Sort notes across the four quadrants and retain their evidence labels. Mark gaps instead of inventing content to make the map look balanced.
- Discuss contradictions and differences between participants. Split the map when combining people would hide materially different needs.
- Choose a research question or product hypothesis and identify what evidence could challenge it. Stop the workshop with a next action and an owner.
The map should make the next decision clearer. It does not need an equal number of notes in every box.
When the map helps—and when it does not
Use empathy mapping to synthesize qualitative research, prepare a cross-functional review, or identify gaps before designing a solution. It is particularly useful when team members have different interpretations of the same evidence.
Do not use it to estimate how common a need is. Interview themes do not establish population percentages. Do not use demographic stereotypes or generated text to fill missing evidence; mark the assumption and investigate it.
The map also loses time and sequence. If the order of events explains the difficulty, a journey map may be the better next artifact. If the issue is already well understood, return to the research only when new evidence or a consequential decision warrants it.
Related frameworks
Jobs to Be Done investigates the progress a person wants in a particular circumstance. Use its interview focus when the empathy map describes reactions but leaves the underlying goal unclear.
Buyer Personas summarize recurring buying needs and decision patterns across a group. An empathy map can contribute evidence, but one participant’s experience is not enough to establish a buyer segment.
Sources and further reading
- Nielsen Norman Group, Empathy Mapping: The First Step in Design Thinking, accessed October 21, 2026. Source for the four-part version and its research-synthesis purpose. Evidence labels, workshop steps, and the fictional example here are editorial recommendations.