User Empathy: How to Build Products People Actually Get

In one famous experiment, people tapped out the rhythm of a song everyone knows - “Happy Birthday,” say - and guessed that half their listeners would name the tune. The real number was about two and a half percent. The tappers heard a full melody in their heads. The listeners heard only knocks on a table.

That gap is the most important thing you will ever learn about building products. You are the tapper. Your users hear taps. And the better you know your own product, the worse you get at hearing what they hear.

Why this matters

You can ship a beautiful, fast, bug-free product and still watch people bounce off it in confusion. Not because they are slow, but because you built it knowing things they don’t.

Every label that “feels obvious,” every flow that “anyone could follow,” every empty screen you left blank - those are taps. To you they sound like a song. To the print-shop owner opening your app for the first time, frustrated and in a hurry, they are noise.

Empathy is the skill that closes this gap. It is not a soft, feel-good extra. It is the single most useful thing a product builder can do, and the hardest to keep once you become an expert. The good news: you can rebuild it on purpose.

Empathy is not sympathy

People swap these words, but in product work the difference decides what you build.

Sympathy is feeling for someone. “Poor shop owners, they find this so confusing.” You are still in your own seat, looking down with a little pity. Sympathy quietly creates distance.

Empathy is feeling with someone. You understand their goals, their context, and their limits so well that you redesign the product until the confusion never appears. Empathy connects.

Researcher Brené Brown, building on the work of nurse-researcher Theresa Wiseman, describes empathy as four moves: take the other person’s perspective, stay out of judgment, recognize their emotion, and show them you recognize it. She calls it “the emotional equivalent of pulling up a chair and sitting beside someone.”

Here is the practical test. Sympathy says, “We’ll add a help tooltip.” Empathy asks, “Why did they need help at all?” - and then removes the cause. Sympathy is an attitude. Empathy is an input to your design decisions.

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 idea comes from a 1989 economics paper by Camerer, Loewenstein, and Weber, and was made famous by Chip and Dan Heath in their book Made to Stick.

The tapping experiment above - run by Elizabeth Newton at Stanford in 1990 - is the cleanest proof of it. Out of 120 songs tapped, listeners correctly named just three.

This is exactly what happens to a developer. You built the system, so every screen feels self-evident.

You think: “Obviously the slug goes in Settings.”

They think: “What’s a slug? Where’s my product?”

You hear the full song. The new shop owner hears the taps. The space between those two heads is precisely where empathy has to do its work.

You are not your user

Nielsen Norman Group, the leading user-experience research firm, sums up their first rule in three characters: “You ≠ User.”

It rests on a well-documented bias called the false-consensus effect (Ross, Greene, and House, 1977): people assume others share their beliefs and will behave as they would. Anyone who acts differently gets quietly filed under “rare” or “weird.”

That bias produces the most dangerous sentence in product development: “Only someone careless or very different from us could fail to figure this out.” That sentence is the trap. The person who failed is usually right, and the design is wrong.

NN/g’s cure is blunt: test with real users, not your colleagues, and stop making assumptions. Your teammates carry the same curse of knowledge you do, so they can never stand in for a shopkeeper who has never seen the screen.

Don’t blame the user - blame the design

Don Norman, the cognitive scientist who coined the term “user experience,” wrote The Design of Everyday Things. His most quoted idea is the “Norman door”: a door with a handle that begs to be pulled, but which you actually have to push. When a door needs a “PUSH” sign taped to it, the door has failed. 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 is liberating: when people struggle, the fault is almost always the design, not the person. Yet users blame themselves - “I’m just bad with computers.” A screen that needs a manual is a Norman door dressed up in pixels.

Think of it this way. A good interface is a door whose handle shape alone tells you to push. A bad one is a door with a confusing handle and a hand-scrawled “PUSH (NOT PULL!!)” sign - which is just proof the design already lost.

Understand the job, not the stated preference

Harvard professor Clayton Christensen popularized Jobs to Be Done (JTBD): customers “hire” a product to do a job in their lives. The trick is figuring out the real job, which is often not what people tell you.

His milkshake story is the classic example. A fast-food chain wanted to sell more milkshakes. They surveyed customers about flavor, thickness, and sweetness, tweaked the recipe - and nothing changed.

Then someone simply watched. It turned out a large share of shakes were bought early in the morning by solo commuters, taken to go. The real job was surviving a long, boring drive. The shake “won” because it was thick enough to last through a thin straw, drinkable with one hand, and not messy. It beat bagels (crumbs), bananas (gone too soon), and doughnuts (sticky fingers). Asking “Want it sweeter? More flavors?” missed the truth completely.

The lesson: people are experts on their problems and amateurs at designing your solution. Study the job, not the wish list.

How to ask users without being lied to

Rob Fitzpatrick’s book The Mom Test is named for an uncomfortable truth: even your mother will lie to be nice if you ask bad questions. His three rules keep you honest.

1. Talk about their life, not your idea. The moment you pitch your solution, people turn polite instead of truthful.
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 single phrase to distrust is “I would definitely buy that.” Fitzpatrick calls it “the world’s most deadly fluff.” What someone did always outranks what they say they will do.

Common misconceptions

• “If it’s confusing, the user just needs to read the instructions.” No. A product that needs a manual to be understood has already failed the test. The fix is better design, not better docs.
• “My team agrees it’s intuitive, so it’s intuitive.” Your team shares your curse of knowledge. Their agreement tells you nothing about a first-time user.
• “Users told me they want this feature, so I’ll build it.” People are unreliable narrators of their own future behavior. Watch what they do; treat what they say as a clue, not a verdict.
• “More features means more value.” Often the opposite. Every extra option is another tap a stressed user has to decode.
• “A persona is a stock photo and a fun backstory.” A persona built without research is an “elastic user” who stretches to justify whatever the team already wanted to build.

How to use this: build empathy on purpose

Empathy fades the moment you become an expert, so you have to rebuild it deliberately. Here is a concrete toolkit.

1. Watch real users. Sit a genuine target user (not a colleague) in front of your product and give them a task. Stay quiet and watch where they hesitate. About five users will reveal roughly 85% of the problems.
2. Read your support tickets. They are a free, endless stream of the exact words confused users type and the precise moments they give up. The limit: they only show people who bothered to complain.
3. Dogfood with humility. Use your own product daily - it catches rough edges fast. But remember you can’t un-know what you know, so this never replaces watching novices.
4. Build research-grounded personas. Capture real goals, context, behavior, pain points, and the job-to-be-done. Keep them few, and use them to settle real arguments: “Would Priya, our non-technical shop owner, understand this label?”
5. Make an empathy map. Split a page into four quadrants - Says (real quotes), Thinks (private worries like “is this another app I’ll have to learn?”), Does (observable actions), and Feels (frustrated, overwhelmed, unsure). The gold is in the gaps: where Says and Does disagree, and where Thinks and Feels go unspoken.

Then design for the user who actually shows up. Not the calm, rested person on a big screen reading carefully - but the real one: frustrated (something already went wrong), rushed, often on a phone with one thumb and weak signal, distracted, and distrustful (“another login? will this bill me?”).

That turns empathy into hard rules:

• Put a product setting near the product, not buried 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% of people want.
• Write errors that say what to do next, not what went wrong internally.
• Give every screen a loading, empty, and error state - because to a non-technical user, a blank screen just reads as “broken.”

Conclusion

The one thing to carry away: the curse of knowledge is your default failure mode, and empathy is the discipline that corrects it. You will always hear the song. Your job is to keep checking whether the person across the table is only hearing taps - and to redesign until they hear the music too.

This is harder than it sounds, because the gap isn’t only about knowledge. It’s about emotion under pressure. A user who is rushed, anxious, and one bad screen away from quitting doesn’t make the calm, rational choices your mental model assumes. Which raises the next question worth chasing: how do people actually decide when they’re stressed, distracted, and short on patience - and how do you design for the messy, impatient brain instead of the tidy one you imagine?