User Empathy: Seeing Through the User's Eyes

Empathy is the skill of feeling with another person — seeing the world from inside their head. For a product builder, it is the single most useful skill you have, and the hardest to keep. This chapter teaches you what empathy is, why your own expertise quietly destroys it, and how to rebuild it on purpose.

Empathy is not sympathy

People mix these two words up, but in product work the difference decides what you build.

Sympathy

Feeling for someone. "Poor shop owners, they find this confusing." You are still sitting in your own seat, looking down at the user with a bit of pity. Sympathy creates distance.

Empathy

Feeling with someone. You genuinely understand their goals, their context, and their constraints, so you redesign the product until the confusion never appears. Empathy connects.

The researcher Brené Brown, building on nurse-researcher Theresa Wiseman, lists four parts of empathy: take the other person's perspective, stay out of judgment, recognise their emotion, and show them you recognise it. She calls empathy "the emotional equivalent of pulling up a chair and sitting beside someone."

The curse of knowledge: you hear the song, they hear taps

The curse of knowledge is a thinking trap: once you know something, you cannot easily imagine what it is like not to know it. The phrase comes from a 1989 economics paper (Camerer, Loewenstein & Weber) and was made famous by Chip and Dan Heath in Made to Stick (2007).

This is exactly what happens to a developer. You built the system, so every label, flow, and empty screen "feels obvious." You are the tapper. The new print-shop owner hears taps.

  BUILDER (tapper)            SHOP OWNER (listener)
  hears full song            hears only the taps
  +----------------+         +----------------+
  | "Obviously the |  --->   | "What's a      |
  |  slug goes in  |  taps   |  slug? Where's |
  |  Settings."    |         |  my product?"  |
  +----------------+         +----------------+
        ^                            ^
        |  the gap between these     |
        +--- is where empathy lives -+

You are not your user

Nielsen Norman Group, the leading user-experience research firm, sums up their first rule as "You ≠ User." It rests on a known bias called the false-consensus effect (Ross, Greene & House, 1977): people assume others share their beliefs and will act as they would. Anyone whose behaviour differs gets seen as "rare" or "weird."

NN/g's cure is blunt: "Test. With real users (not your colleagues)... Don't make assumptions." Your teammates carry the same curse of knowledge you do, so they are not a safe stand-in for a shop owner who has never seen the screen.

Don't blame the user — blame the design

Don Norman, who coined the term "user experience," wrote The Design of Everyday Things (1988; revised 2013). His most useful idea is the "Norman door": a door with a pull handle that you actually have to push. When a door needs a "PUSH" sign taped to it, the door is badly designed — good hardware tells you what to do without words.

Two terms make this precise:

Affordance

A possible action an object permits. A chair affords sitting; a button affords clicking.

Signifier

A perceivable signal that tells you where and how to act — an arrow, a flat plate that says "push here," a clearly clickable button.

Norman's thesis: when people struggle, the fault is usually the design, not the person. Yet people blame themselves — "I'm just bad with computers." A UI that needs a manual is a Norman door. This is the heart of the print-SaaS rule that a shopkeeper, not a developer, must understand every screen.

Understand the job, not the stated preference

Harvard professor Clayton Christensen popularised Jobs to Be Done (JTBD): customers "hire" a product to do a job. His milkshake story shows why watching beats asking.

How to ask without being lied to

Rob Fitzpatrick's The Mom Test (2013) is named for a simple truth: even your mum will lie to be nice if you ask bad questions. His three rules:

1. Talk about their life, not your idea. The moment you pitch your solution, they turn polite instead of honest.
2. Ask about specifics in the past, not opinions about the future. "Tell me about the last time this happened" beats "Would you use this?"
3. Talk less, listen more.

The empathy toolkit

Personas — done well vs badly

A persona is a written archetype of a user, popularised by Alan Cooper in The Inmates Are Running the Asylum (1998).

• Badly: a stock photo plus invented trivia (age, favourite coffee), with no research — an "elastic user" who stretches to justify whatever the team already wanted.
• Well: grounded in real interviews; captures goals, context, behaviour, pain points and the job-to-be-done; few in number; used to settle real arguments — "Would Priya, our non-technical shop owner, understand this label?"

Empathy map (Says / Thinks / Does / Feels)

Created by Dave Gray at XPLANE and published in Gamestorming (2010), the empathy map has four quadrants:

• Says — real quotes from research.
• Thinks — private worries they won't say aloud ("is this yet another SaaS I'll have to learn?").
• Does — observable actions, not claims.
• Feels — the emotion: frustrated, overwhelmed, unsure.

Real users arrive stressed, not curious

Your imagined user is calm, rested, on a big screen, reading carefully. Your real user is the opposite: frustrated (something already went wrong), rushed (a task to finish, no time to explore), often on a phone with one thumb and poor signal, distracted, and distrustful ("another login? will this bill me?"). Their mental load is already high before they open your app.

This is why "discoverability without a manual" matters so much. A stressed print-shop owner who navigates by intuition and never reads docs has zero patience to figure things out. Empathy turns into concrete rules: put a product setting near the product, not in global settings; use plain labels ("Store Name," "Order Status," never uuid or payload); say "Saved successfully," never "200 OK"; set defaults to what 90% want; write errors that say what to do next. And every data view needs loading, empty, and error states — because to a non-technical user, a blank screen simply reads as "broken."

Key takeaways

• Empathy ≠ sympathy: feel with users and redesign the cause of confusion; don't pity them and bolt on a tooltip.
• The curse of knowledge makes everything you built feel obvious to you and baffling to a newcomer — you hear the song, they hear taps.
• You are not your user; the false-consensus effect tricks teams into testing on themselves. Watch real target users instead.
• Don't blame the user (Norman) — a UI that needs a manual is a "Norman door," a design failure.
• Watch what people do, not what they say: the milkshake story and The Mom Test both prove behaviour beats stated preference.
• Build empathy on purpose with usability watching, support tickets, humble dogfooding, research-grounded personas, and Says/Thinks/Does/Feels empathy maps — then design for the rushed, distrustful, phone-in-hand user who never reads docs.