The False Consensus Effect: Why You Are Not Your User

The false consensus effect is the habit of assuming other people share your opinions, choices and behaviour more than they really do. In product work it shows up as "I would use this, so our users will too." The fix isn't to ignore your own judgement. Write your guesses down before you research, talk to people who are not like you, and let what they actually did overrule what you expected them to do.

This guide explains where the effect comes from, how to spot it in a product team, a six-step routine for countering it in research, and when your own view is still worth something.

What the false consensus effect is

The term comes from a 1977 paper by Lee Ross, David Greene and Pamela House at Stanford. They defined it as people's tendency to see their own choices as common and appropriate, and the opposite choices as unusual, even deviant.

Two things make it hard to catch:

• It feels like knowledge, not bias. When you picture "a typical user", the picture is built from your own reactions plus the people you happen to talk to. It doesn't feel like a guess.
• It works in both directions. People who make a choice think it's popular. People who make the opposite choice think that is popular. Both groups can't be right.

The Nielsen Norman Group put the product version plainly. In Raluca Budiu's article "You Are Not the User", she writes that designers, developers and even UX researchers "fall prey to the false-consensus effect, projecting their behaviors and reactions onto users." Jakob Nielsen's shorter version, from an interview about the best design advice he ever got, is six words: "You are not the target audience."

The evidence: a sandwich board and 115 tests

The best-known demonstration is the sandwich board study. Ross and his colleagues asked Stanford students whether they would walk around campus wearing a sign that said "Eat at Joe's". Some agreed and some refused. Then each student estimated how many of their peers would make the same choice.

Students who agreed to wear the sign estimated that around 62% of their peers would also agree. Students who refused estimated that only about 33% would agree. Each group thought its own choice was the normal one.

That could have been a one-off. It wasn't. In 1985 Brian Mullen and colleagues pooled 115 hypothesis tests from 23 studies in a meta-analysis and found the effect was highly significant, with a moderate effect size. Joachim Krueger and Russell Clement (1994) went further and called it "ineradicable": in their studies the bias held even when people had other information about the group available to them.

The useful lesson for researchers is the second half of the sandwich board result. It isn't that people overestimate agreement in general. It's that your estimate of what's common is pulled towards whatever you yourself would do.

How it shows up in product teams

Product teams are a near-perfect setting for the effect. Everyone in the room uses the product every day, knows how it was built and usually shares a background with the people sitting next to them. Six signs it's shaping your decisions:

1. "I'd never use that." A feature gets cut because the people in the room wouldn't use it, without anyone asking the people who might.
2. Internal dogfooding treated as user research. Feedback from colleagues stands in for feedback from customers, even though colleagues know the product far better.
3. Personas that look like the team. The "primary persona" has the team's job title, tools and level of technical comfort.
4. Surprise at the support queue. Tickets about things "everyone knows how to do" keep arriving and get treated as edge cases.
5. One loud customer becomes "users". A request from a customer who thinks like the team gets read as a request from the whole base.
6. Skipping research because the answer is obvious. If nobody on the team can imagine a different answer, that's the moment the effect is strongest.

Why it's so hard to shake

Knowing about the bias doesn't switch it off. A few reasons it sticks:

• You talk to people like you. Part of the effect likely comes from who we spend time with. If your friends, colleagues and social feeds all share your habits, your sample of "other people" is biased before you start.
• Your own experience is vivid. You remember exactly how you felt using the feature last week. A user you never met has no such weight in your memory.
• Expertise widens the gap. The more you know about a product, the less your experience looks like a new user's. That makes the closely related curse of knowledge worse.
• Agreement inside the team feels like evidence. When five people in a room all expect the same thing, it feels like a sample of five. It's really a sample of one shared background.

How to counter it in your research

You can't remove the bias from your head, but you can design research that catches it. This six-step routine works for interviews, surveys and usability tests alike.

1. Write your predictions down first

Before any fieldwork, have each person on the team write what they expect: the most common answer, the share of people who will pick each option, the reason people will give. Keep the predictions separate so nobody anchors on the loudest voice. Without a written guess, "we already knew that" is impossible to argue with.

2. Recruit outside your own circle

Friends, colleagues and power users from your community are the people most likely to think like you. Go further out: customers from other segments, people who tried the product and left, people who chose a competitor. See finding research participants for channels.

3. Ask about what people did, not what they'd do

Hypothetical questions invite people to answer the way they imagine a sensible person would, which is its own consensus guess. Ask about the last time they faced the problem, what they tried and what happened. Grand tour questions are a good opener.

4. Count, don't recall

After ten interviews, the two or three stories that matched your expectations will feel like "most people". Tally how many participants said each thing. Where you can, add a structured question so the count is exact.

5. Look for the opposite case on purpose

For each finding, ask who disagreed and why. If nobody did, check whether your sample could have produced anyone who would. Negative case analysis is a formal way to do this.

6. Compare the predictions with the results

Put the written guesses next to what you found and talk through the gaps. This is the step that changes how a team thinks. A product manager who predicted 70% would pick an option and saw 25% doesn't need a lecture about bias.

Hearing it from people who are not you

The steps above only work if the conversations happen with people whose lives differ from yours. A few habits make that easier in practice:

Photo by Monica Melton on Unsplash

• Let the participant set the vocabulary. If they call it "the export thing", so do you. Your internal names are a clue that you're thinking as an insider.
• Resist finishing their sentences. When a participant hesitates, it's tempting to offer the answer you'd give. Wait instead. Our guide to silence in user interviews covers how long.
• Invite observers from the team. Engineers and designers who watch a session where someone struggles with the "obvious" flow update their mental model of users faster than any report.
• Debrief straight away. Ask each observer what surprised them. Surprises are where the team's assumptions just met the real world.

When your own view is still useful

"You are not the user" can be taken too far. Some practitioners argue that if you never use your own product you lose a lot of useful intuition, and that some teams genuinely are part of their audience: developer tools built by developers, for example.

The answer is to treat your own experience as one data point, clearly labelled. It's a fine source of hypotheses. It's a poor source of estimates about how common something is. Use it to decide what to ask, then let the participants decide what's true.

How Koji helps

Koji runs AI-moderated interviews by voice or text, so you can hear from many more people outside your own circle than a team could schedule by hand. Here's how it maps to the routine above:

• Write your predictions first. Every Koji study starts from a research brief with a stated goal and questions. Upload your team's predictions as a context file so they sit next to the study.
• Recruit outside your circle. Share an interview link anywhere, import a CSV of customers to give each one a personal invite link, or recruit from Koji's research panel from the Panel recruit tab. Screening questions keep each study to the people you meant to reach.
• Ask about past behaviour. The AI interviewer follows up on each answer, up to three times per question, so participants get asked "what happened next?" instead of being left at the hypothetical.
• Count, don't recall. Structured questions (single choice, multiple choice, scales, ranking and yes/no) sit inside the conversation and produce exact counts in the report, while open questions get thematic analysis.
• Look for the opposite case. Each finding in the report shows the share of participants behind it, and you can open the supporting responses to read the quotes, including from people who said something different.

There's one more detail that matters for this bias in particular. When you try your own interview in Koji's preview, that run never counts as a response and never appears in the report. Your own answers stay out of your users' data.

Related Resources

• The curse of knowledge in user research
• Confirmation bias in user research
• Cognitive biases in user interviews
• Negative case analysis
• Product dogfooding guide
• Structured questions guide

Sources

• Budiu, R. (2017). You are not the user: The false-consensus effect. Nielsen Norman Group.
• Krueger, J., & Clement, R. W. (1994). The truly false consensus effect: An ineradicable and egocentric bias in social perception. Journal of Personality and Social Psychology, 67(4), 596–610.
• Mullen, B., Atkins, J. L., Champion, D. S., Edwards, C., Hardy, D., Story, J. E., & Vanderklok, M. (1985). The false consensus effect: A meta-analysis of 115 hypothesis tests. Journal of Experimental Social Psychology, 21(3), 262–283.
• Nielsen, J. The best design advice I ever got. Interview, Peachpit.
• Ross, L., Greene, D., & House, P. (1977). The "false consensus effect": An egocentric bias in social perception and attribution processes. Journal of Experimental Social Psychology, 13(3), 279–301.