The Tapper and the Listener: You Are Not the User

You're showing your product to someone for the first time. They stall on the very first screen. You wait, then you can't help it: "just press the button at the top." They ask which button. You look at the screen you have seen ten thousand times, and for one second — only one — you see it the way they do.

That second is the most valuable thing in this article. It closes fast, and the whole discipline of user research exists to reopen it on demand.

The tapping experiment

In 1990 Elizabeth Newton ran a study at Stanford that has since become the standard illustration of this problem. Participants were split into two roles. The tappers were given a well-known song — a national anthem, a nursery rhyme — and asked to tap out its rhythm on a table. The listeners had to guess the song.

Before the tapping, the tappers were asked to predict how often they'd be understood. Their estimate: about 50%.

The actual result: 3 correct guesses out of 120. Two and a half per cent.

The reason is not in the ears. While the tapper taps, the full song plays in their head — the melody, the words, the arrangement. It is unimaginable to them that the other person hears bare knocks. This is the curse of knowledge: once you know something, you lose the ability to imagine not knowing it.

You are tapping. They hear knocking. And you cannot hear the knocking.

Every icon you can read without a label, every abbreviation on a dashboard, every flow that "obviously" goes this way — you're tapping. And your estimate of how clear it is will be off by roughly the same factor as the tappers'.

The false consensus effect

There's a second, related distortion. Lee Ross, David Greene and Pamela House described it in 1977: people systematically overestimate how many others share their views, preferences and behaviours. Ask someone what share of the population would do what they'd do, and the number comes back inflated — because your own way of doing things is the only one you have full access to.

Put those two together and you get the standard failure of designing by intuition: I'd find this obvious, therefore most people will.

And the trouble is that a designer is a spectacularly unrepresentative sample. You have the product open every day. You know its conceptual model because you built it. You're on a fast machine, a large screen, a good connection, in a quiet room, with the full attention you have deliberately set aside for it.

The person you're designing for opened the app between two other things, on a three-year-old phone, in a bright room, with 8% battery, while someone talks to them. They have forty seconds and no interest in your product as such.

Which brings out a line worth keeping: nobody wants to use your software. They want the thing on the other side of it. The product is a corridor, and nobody admires a corridor.

The three traps of designing for yourself

Break down what you actually carry that they don't:

You know where everything is. Your navigation cost is zero, so you can't feel the cost of a bad label. You'll never search your own menu.

You know why. You know why the account has to be created before the trial, why that field is required, why the steps go in that order. They see arbitrary demands and are not inclined to be forgiving.

You care. You've thought about this product for months. Their engagement is measured in seconds, and they've allocated exactly none of it to figuring out your terminology.

The uncomfortable consequence: your fluency with your own product is not a qualification. It's an impairment specific to your job, and the only treatment is regular contact with people who don't have it.

What doesn't count as research

Several things get used as substitutes. They aren't.

Analytics alone. They tell you what happened and where, never why. A drop-off at step three could be confusion, a broken button, a price, or the moment people realise this isn't for them. Four different problems, one identical curve.

Asking the team. Everyone in the room shares your curse of knowledge, in a stronger form.

"The client knows their users." Sometimes. Often what they know is their loudest three customers and their own assumptions, aged into certainty.

Your own experience. Legitimate as a source of hypotheses, worthless as evidence. The distinction is the whole point.

Copying competitors. The most seductive one, because it looks like research. But you're copying a solution without its reasoning, which may itself have been copied. Half the interface conventions in any industry are cargo cult with a long paper trail.

What you're actually looking for

If research is not "asking people what they want," what is it? Three shifts:

Behaviour, not opinion. What they did last Tuesday, not what they think of your idea. Opinions about hypothetical futures are close to noise.

Problems, not solutions. People are excellent at describing their pain and unreliable at prescribing cures. The famous "faster horses" quote is almost certainly not Ford's, but the underlying observation is sound: asked for a solution, people extrapolate from what exists.

Context, not preference. Where they are, what else is open, what they're interrupted by, what they do immediately before and after. Most product failures are context failures, and context is invisible in any conversation held in a meeting room.

The cheapest place to be wrong

The economic argument is simple and worth having ready, because someone will tell you there's no time for this.

The cost of changing a decision rises steeply the later it's made — Barry Boehm documented this in software in the 1980s and nothing has repealed it. Changing a sentence in a research summary is free. Changing a flow in a prototype costs an afternoon. Changing it after the code is written costs a sprint. Changing it after launch costs the sprint plus a migration plus the users who already learned the old way and the ones who left.

Research isn't a luxury layered on top of the work. It's the cheapest place in the whole project to be wrong.

And the scale is negotiable, which is the part people miss. "No time for research" usually means "no time to do it the way it's described in the book." But five conversations is research. An afternoon reading support tickets is research. Watching one person try to sign up is research, and it's typically the most bruising hour of a designer's month.

In practice

Watch one person use it this week. Not a study — one person, twenty minutes, no preparation. Say nothing while they work. This single habit does more than any amount of reading.

Read support tickets for an hour. They're free, already written, and full of the exact words your users use — which is also your best source of interface vocabulary.

Write down your assumptions before you research. List what you're sure of about your users. Then check. The value is in the list you were wrong about, and you can't measure that without writing it first.

Name the situation, not the person. Instead of "our user is a 30-year-old manager," write "someone doing this on a phone, in a hurry, for the second time this month." Situations are checkable; demographics rarely are.

Ban "obviously" in design discussions. Every time it appears, replace it with "we should check." The word marks the exact spot where the curse of knowledge is operating.

Keep a note of your own confusions. When some other product confuses you, write it down that minute. It's the only unfiltered access you'll ever have to the beginner's experience.

Check yourself

Close the article and answer in your own words:

What did the tappers predict, what actually happened, and why is the gap so large?
What is the false consensus effect and how does it show up in design decisions?
Why is a designer an unrepresentative sample of their own product's users?
Analytics show a drop at step three. Name four different causes that produce the same curve.
Why is copying a competitor's solution risky even when the competitor is successful?
Why is "behaviour, not opinion" the core rule of research?
What's the argument against "we don't have time for research"?

In short

The tapping experiment: tappers expected 50% comprehension and got 2.5%. Knowing something removes your ability to imagine not knowing it.
False consensus: we overestimate how many people are like us — and designers are the least representative sample of their own users.
You know where everything is, you know why, and you care. Your users have none of the three.
Analytics, team opinion, personal experience and competitor copying are hypothesis sources, not evidence.
Look for behaviour rather than opinion, problems rather than solutions, context rather than preference.
The cost of a wrong decision rises sharply from research to prototype to code to launch. Research is the cheapest place to be wrong.
Research scales down: five conversations, an hour of tickets, one person watched in silence.