Personas & Empathy Maps

---

Origins

Personas were introduced by Alan Cooper in the 1990s and formalized in The Inmates Are Running the Asylum¹. Cooper's argument was that software designed for "users" in the abstract consistently failed real users. Naming and detailing a specific archetypal user — their goals, behaviors, context, frustrations — gave designers and engineers someone to design for rather than someone vague to design at.

The Empathy Map was developed by Dave Gray at XPLANE and popularized through Gamestorming². Where a persona names who a user is, the empathy map captures the user's experience across four quadrants — what they say, think, feel, do — producing a richer picture of what the user brings to any interaction with the product.

What a Persona Captures

A well-built persona typically includes:

• Name and identifying details: not arbitrary — a memorable name and photo helps the team refer back to "what would Maya do?"
• Role and context: their job, daily environment, who they work with, what tools they use.
• Goals: what they're trying to accomplish, both with this product and more broadly.
• Behaviors: how they currently work, what habits they have, what they're skilled at and not.
• Frustrations and pain points: what's wearing them down in their current workflow.
• Quotes: actual or representative things they would say — the voice of the persona.

Personas can be data-grounded (built from research with real users) or provisional (built from hypothesis when research is not yet available). Both are useful, but their epistemic status is different — a data-grounded persona is evidence; a provisional persona is a hypothesis to test.

The Empathy Map

The classic empathy map has four quadrants around a central figure:

• Says: what the user actually says out loud, in interviews, in surveys, in support tickets.
• Thinks: what they're thinking but might not say — concerns, hopes, assumptions, doubts.
• Does: their observable behavior — what they actually do, not what they say they do.
• Feels: the emotional layer — frustration, anxiety, pride, relief.

The map is often extended with two more sections at the bottom: Pains (the obstacles and frustrations) and Gains (the outcomes they want).

The gap between "says" and "does" is often the most revealing part of the map. Users say they want feature parity with a competitor; their behavior shows they only use three features and ignore the rest. Designing from the say layer would build the wrong thing; designing with both layers in view points at what would actually serve them.

Building Personas Honestly

Personas have a credibility problem in product work. Too many were invented in conference rooms based on stereotypes, given names like "Mary the Marketing Manager," and then used to justify whatever the team wanted to build anyway. Cooper's original concept was always meant to be data-grounded.

A good persona-building process:

1. Conduct interviews with 5–15 actual users in the segment.
2. Identify patterns across interviews — common goals, behaviors, contexts.
3. Cluster into 2–4 personas — never one (loses nuance), never twelve (overwhelming).
4. Validate the personas by showing them to interview participants — do they recognize themselves?
5. Date them — personas become stale as the product and user base evolve. Refresh annually or after major shifts.

When to Use Personas vs. Empathy Maps

The two tools complement each other. Personas describe who; empathy maps describe experience. Use them together when possible.

• Personas: for ongoing reference during product decisions, hiring contexts for who's being built for, alignment across stakeholders about target users.
• Empathy maps: for shaping a specific feature, understanding why a current experience isn't working, or surfacing the gap between stated and actual user behavior.

Both are working artifacts, not deliverables. They earn their keep by being referenced often — in standups, in refinement, in design reviews — not by being polished and filed.

Common Pitfalls

• Persona invention: built from stereotypes, opinions, or sales fantasies rather than real users. The personas justify whatever the team wanted to build.
• Too many personas: a team with 12 personas may as well have none — nobody can hold them all in mind, and every decision can be justified by reference to some persona.
• Stale personas: built three years ago, hanging on the wall, ignored by the team because the user base has shifted.
• Treated as deliverables: a beautifully designed persona deck shown once and never referenced. The persona is for daily reference, not for the executive presentation.
• Demographics over behavior: "32 years old, lives in Brooklyn, drinks coffee" is not a persona, it's a profile. Behavior, goals, and context are what matter.
• Empathy map without observed data: a "Thinks" quadrant filled with assumptions is just opinion in a fancy frame.

Coaching Tips

Ground in Interviews

A persona built without talking to actual users is fiction. Insist on real research as input before the persona becomes a team artifact.

Cap the Count

2–4 personas. A team that wants twelve is either trying to cover every segment or trying to avoid the hard call about who matters most.

Refer Often

A persona referenced in refinement, planning, and reviews stays alive. A persona on a wall nobody looks at dies.

Watch the Says/Does Gap

On empathy maps, look hard at the difference between stated and observed behavior. The gap is usually where the real product opportunity lives.

Refresh Annually

User behavior shifts. The persona built two years ago is probably stale. Schedule the refresh deliberately rather than discovering the staleness in production.

Behavior Over Demographics

Push the team past "32 years old, coffee drinker" to "frustrated by the current export process, uses spreadsheets as the workaround." Behavior is what designs against.

Summary

Personas and empathy maps are tools for keeping the user in the room when the user isn't actually in the room. Done well, they shape every decision the team makes about what to build and how it should work. Done badly — built without research, frozen as deliverables, ignored after the workshop — they become at best decoration and at worst justification for whatever the team would have done anyway.

The discipline is to treat them as live working artifacts: built from real user research, referred to in actual product decisions, updated when the underlying user reality shifts. A team that does this gets a shared vocabulary for who matters and what they need. A team that doesn't ends up building for nobody in particular.

Back to Experience & Story Mapping