Here is the most counterintuitive rule in UX, and one of the oldest: the first rule of usability is don’t listen to users.
Not because users are stupid. Because what people say and what people do are two different things, and the gap between them has sunk more products than bad code ever has. Someone tells you they would “definitely use” a feature. You build it. Nobody touches it. A stakeholder insists “users want X.” You ship X. The numbers do not move. Everyone was sincere. Everyone was wrong.
Jakob Nielsen put a number on it. Across 113 comparisons, the correlation between what users said they preferred and how they actually performed was just 0.44. In plain terms: self-reported preference predicts real behavior less than half the time. This issue is about why asking is a trap, what to do instead, and how to handle the stakeholder who is certain they already know.
In this issue:
The 0.44 problem
Why users can’t tell you what they want
The questions that lie and the questions that don’t
“I know what users want” and other dangerous words
How to find the truth instead
Resource Corner
The 0.44 problem
Start with the number, because it reframes a huge amount of common practice.
Nielsen and Jonathan Levy analyzed 113 pairwise comparisons of interfaces built for the same task and found a correlation of just 0.44 between users’ stated preferences and their measured performance. Later research nudged it to 0.53 for websites, still low. Both numbers say the same thing: you can only weakly predict what someone will actually do from what they say they prefer.
This is not a small caveat. It is a foundation-shaking fact for how a lot of research gets done. The classic trap is to create a few designs, show them to users, and ask which they like. Nielsen’s verdict on that method is one word: wrong. If users have not actually tried to use the designs, their comments are based on surface features, the things that catch the eye, not the things that make a task easy.
And here is the quietly hopeful part buried in the data. The more a design actually supports people in doing what they want to do, the more they end up liking it. Preference follows performance, not the other way around. Which means the way to a design people love is not to ask what they love. It is to make the thing work, and the love follows.
Why users can’t tell you what they want
This is not a flaw in your users. It is a basic fact about how people relate to their own needs, and understanding it changes how you research.
The pattern goes: a user experiences a problem, imagines a solution, and then requests that solution as a feature. The problem is real. The imagined solution usually is not the best one. So when someone says “I want to edit multiple items at once,” they have handed you their guess at a fix, not the underlying need. Build the literal request and you may solve the wrong thing entirely. Feature requests are symptoms, not solutions.
Users are not bad at this because they are dumb. They are bad at it because they are not designers. It is not their job to diagnose the root problem or weigh solutions against tradeoffs they cannot see. Their job is to live the problem. Your job is to figure out what actually solves it, and that requires looking past the request to the need underneath.
The same trap catches prediction. Ask “would you use this feature?” and people answer optimistically, generously, imagining an idealized future version of themselves. Nielsen’s third rule is blunt: definitely do not believe what people predict they may do in the future. Stated future behavior is the least reliable data there is. People are not lying. They genuinely do not know, because nobody can accurately forecast their own behavior in a situation they have not been in yet.
The questions that lie and the questions that don’t
Most of the bad data in UX comes from asking the wrong kind of question. Here is the difference, and it is worth memorizing.
🔴 “What features do you want?” Invites people to design for you, which they cannot do well. You get a wishlist of imagined solutions, not real needs.
🔴 “Would you use this if we built it?” Pure speculation about the future. The data is wrong before you collect it. People say yes to be nice and to imagine their best selves.
🔴 “Why don’t you use feature Y?” Asks them to rationalize past behavior they may not even remember accurately. You get a plausible story, not the truth.
🟢 “Can you try using feature Y while I watch?” This is the one that works. Instead of asking them to report, predict, or explain, you watch them actually do it. Behavior cannot lie the way self-report can.
That single shift, from asking to observing, is the whole discipline. Watch what people do, not what they say they do, and never trust what they say they will do. The best UX data comes from behavior: usability sessions, analytics, support tickets, what people actually click and abandon. The words around the behavior are useful context. The behavior is the truth.
“I know what users want” and other dangerous words
The say-do gap is not only a user problem. It is a stakeholder problem, and often a worse one, because stakeholders have the authority to make their guesses into roadmap.
The research on difficult UX situations is full of it. One finance expert told a designer: “I’ve spent three years on this. This is what I want on the page, and I’m confident. I know this is what people want, because as a finance expert, it’s what I’d want to see.” That is the trap in one sentence: a stakeholder mistaking their own preference for the user’s need. The same studies note that stakeholder requirements often change not from new user data but from shifting internal politics, and that requests frequently arrive as buzzwords, “I want gamification in our app”, with no clear answer when asked why.
This is why the most important research skill is not running studies. It is handling the gap between what a powerful person believes and what the evidence shows. And 54% of designers report stakeholders wanting to chase trends without a clear use case, so this is not rare. It is the daily job.
The move is not to argue opinion against opinion. You will lose, because they outrank you. The move is to shift the conversation from preference to evidence. Ask the stakeholder: “What problem does this solve for users or the business?” If users do not actually have that problem, show the data and propose alternatives that address the real need. And if they insist anyway, document the decision and proceed. You will not win every battle, and trying to is its own kind of burnout. But you change your odds enormously by making the conversation about evidence instead of taste.
How to find the truth instead
Concrete ways to get real answers instead of comfortable fictions.
✅ Watch, don’t ask. The single highest-value habit. Whenever you can, replace “what do you think of this” with “show me how you’d do this” and observe. Behavior is the data. Opinion is the noise around it.
✅ Dig past the request to the problem. When a user or stakeholder asks for a specific feature, do not build it yet. Ask what they were trying to accomplish when they felt the need. Solve the problem, not the requested solution.
✅ Triangulate behavior from multiple sources. The modern move is to extract real needs from support tickets, session recordings, onboarding analytics, and sales objections, places where actual behavior and friction live, not from surveys asking people to predict themselves.
✅ Treat preference data as a tiebreaker, not a driver. There is a right time to ask what people prefer: after they have actually used the thing, to break a tie between options that perform equally well. Preference is a garnish on behavioral data, never a substitute for it.
✅ Turn stakeholder opinions into testable questions. When someone says “users want X,” reframe it: “Great, that’s a hypothesis we can check. Here’s how we’d know if it’s true.” You are not refusing their input. You are holding it to the same evidence standard as everything else.
📦 Resource Corner
First Rule of Usability? Don’t Listen to Users (Nielsen Norman Group)
The foundational article behind this whole issue, with the 0.44 correlation and the three rules of what to believe. Decades old and more relevant than ever. Essential reading.
You’re Solving the Wrong Problem (and Your Users Know It) (UX University)
The clearest breakdown of why feature requests are symptoms not solutions, and the exact good-versus-bad question list. Directly actionable for both user research and stakeholder conversations.
How I Cut Down Stakeholder Rework with Better UX Storytelling (LogRocket)
A practical script for turning subjective stakeholder feedback into evidence-based conversations. The context-evidence-insight structure is worth stealing wholesale.
The Mom Test by Rob Fitzpatrick
The best book on talking to users so they can’t lie to you, even to be nice. Short, practical, and the single most useful thing you can read on asking questions that get real answers.
Data-Driven UX Design Guide for 2026 (Gitnexa)
A solid overview of basing decisions on behavior rather than the loudest voice in the room, including how to blend quantitative and qualitative evidence. Good for building the broader practice.
💭 Final Thought
“Listen to your users” is the most repeated advice in UX, and it is half wrong. Listen to their problems, yes. Watch their behavior, always. But do not trust their solutions, their predictions, or their stated preferences, because none of those reliably survive contact with what they actually do.
The same goes for the confident stakeholder, and for you. Everyone has a theory about what users want. The theories are cheap and usually wrong. The behavior is the only thing that is true.
So stop collecting opinions and start watching what people do. Build the thing that works, and the love follows.
Your users can’t tell you what they want. But they’ll show you every single time.
