Why asking users what they want rarely works

If you’re trying to improve something, why wouldn’t you go straight to the people using it and ask them what they want changed? It feels efficient. Direct. Almost obvious.

So we did exactly that.

We asked the user what they’d expect to happen next, what they’d change, what would make the journeyglossary×Pain PointA specific problem or frustration users experience when trying to complete a task.Open glossary term→ better in their eyes. And they gave solid answers. Clear, confident, well-articulated answers that, if you just read them back in isolation, would sound like useful direction.

The problem was, when you actually stepped back and looked at the journeyglossary×Pain PointA specific problem or frustration users experience when trying to complete a task.Open glossary term→, none of those answers really solved what was going on.

That’s something I’ve seen repeatedly over the years, across very different types of projects. Users are incredibly good at reacting to what’s in front of them. They can tell you when something feels off, when something is frustrating, when something doesn’t quite make sense. But when you ask them to design the solution, even indirectly, they’re working from a completely different vantage point.

They’re solving the moment they’re in, not the systemglossary×SystemA system is a collection of interconnected components that work together to achieve a specific function or outcome.Open glossary term→ as a whole.

On a travel platformglossary×PlatformA platform is a system or environment that enables users, services, or applications to interact, build, or operate.Open glossary term→ I worked on, this became very obvious quite quickly. Users were going through a booking journeyglossary×Pain PointA specific problem or frustration users experience when trying to complete a task.Open glossary term→ where the early stages felt smooth, exploratory, even enjoyable. But as soon as they got closer to committing, you could feel the hesitation creep in. Not always verbally, but in how they behaved. They slowed down. They re-read things. They started second-guessing decisions they’d already made. On Travelbag, that patternglossary×PatternA reusable solution to a common design problem.Open glossary term→ showed up repeatedly.

When we asked them what they wanted at that point, the answer was almost always the same. More information. More clarityglossary×ClarityClarity is how easily users can understand what is happening and what they need to do.Open glossary term→. More visibility of pricing and options earlier in the journeyglossary×Pain PointA specific problem or frustration users experience when trying to complete a task.Open glossary term→ so they could feel more confident about what they were doing.

It sounds completely logical.

But when we actually explored that direction, the effect was the opposite of what they expected. Bringing more information forward didn’t increase confidenceglossary×ConfidenceConfidence is the level of certainty in a decision or outcome based on available evidence.Open glossary term→, it introduced more doubt. Users started comparing options they didn’t need to compare yet, questioning decisions before they had enough contextglossary×ContextThe surrounding conditions that shape behaviour and decisions.Open glossary term→, and ultimately taking longer or dropping out earlier. What they had asked for made the experience heavier, not better.

What they were really telling us wasn’t we need more information. It was we don’t feel comfortable committing yet. Those are two very different problems, and if you take the requestglossary×RequestA request is an action sent from a client to a server asking for data or a service.Open glossary term→ at face value, you solve the wrong one.

I’ve seen a similar patternglossary×PatternA reusable solution to a common design problem.Open glossary term→ in more complex environmentsglossary×EnvironmentA specific setup where software runs, such as development, staging, or production.Open glossary term→ as well, particularly when working across large, fragmented systemsglossary×SystemA system is a collection of interconnected components that work together to achieve a specific function or outcome.Open glossary term→ like the NHS.

Users would often say they wanted everything in one place. All the information, all the options, all the answers visible without having to navigate around.

Again, it sounds like the right thing to do.

But when you start designing for that, it very quickly becomes overwhelming. Too much content, too many pathways, no clear sense of direction. What users actually needed wasn’t more access, it was better guidance. They needed to feel like they were being led through something, not dropped into it.

That distinction only becomes clear when you stop focusing on what users say and start paying closer attention to what they do.

In my experience, the most valuable moments in researchservice×User ResearchUnderstand user behaviour, validate ideas, and make clearer product decisions with evidence you can act on.Open service→ are rarely the direct answers. They’re the behavioursglossary×BehaviourBehaviour refers to how users interact with a system, including actions, patterns, and responses.Open glossary term→ that don’t quite match what’s being said.

A user might tell you everything is clear, but then hesitate before clicking.

They might say they’re confident, but go back and check something they’ve already seen.

They might describe a journeyglossary×Pain PointA specific problem or frustration users experience when trying to complete a task.Open glossary term→ as straightforward, but take a completely unexpected route through it.

Those small inconsistencies are where the real insightglossary×InsightAn insight is a meaningful understanding that explains why something is happening and what it means.Open glossary term→ usually sits.

There’s also something else going on when you ask users what they want, which is easy to overlook. People naturally try to be helpful in those situations. They want to give you something useful, something constructive, something that feels like a contribution. They’re not trying to mislead you, but they are, in a way, stepping into a role that isn’t theirs.

Because design isn’t about collecting suggestions and stitching them together.

I’ve worked on projects where teams leaned heavily into user suggestions, almost treating them as requirements. Every piece of feedbackglossary×FeedbackFeedback is the system response that informs users about the result of their actions. It helps users understand what has happened and what to do next.Open glossary term→ became something to consider implementing, every idea something to explore. The result was always the same. The product became heavier, more complex, trying to accommodate too many directions at once, and in doing so, losing any sense of clarityglossary×ClarityClarity is how easily users can understand what is happening and what they need to do.Open glossary term→.

That’s where experience starts to matter more than processglossary×ProcessA process is a defined sequence of steps used to achieve a specific outcome.Open glossary term→.

The job isn’t to take what users say and translate it directly into featuresglossary×FeatureA feature is a specific piece of functionality within a product that delivers value to users. It represents something users can do or experience as part of the overall product.Open glossary term→. It’s to understand what sits underneath it. When someone says they want more control, it might actually mean they don’t trustglossary×TrustUser confidence that a product, service, or organisation will do what it promises.Open glossary term→ the systemglossary×SystemA system is a collection of interconnected components that work together to achieve a specific function or outcome.Open glossary term→. When they ask for more options, it might mean they’re unsure they’re making the right choice. When they say something is confusing, it might not be the interface at all, it might be the way the journey is structured.

Those are very different problems, and they require a different level of thinking to solve.

So I don’t ignore what users say, far from it. But I don’t treat it as the answer either.

Because the goal isn’t to buildglossary×BuildA build is the process of compiling and packaging code into a runnable application.Open glossary term→ what users ask for in the moment.

It’s to buildglossary×BuildA build is the process of compiling and packaging code into a runnable application.Open glossary term→ something that works for them when they’re actually using it.

And those two things, more often than not, are not the same.