Why asking users what they want rarely works

So we did exactly that. We asked the user what they'd expect to happen next, what they'd change, what would make the journey better. They gave solid, clear, confident answers that, read back in isolation, would sound like useful direction. The problem was, when you stepped back and looked at the journey, none of those answers really solved what was going on.

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.

None of this makes the answers worthless. What somebody asks for is reliable evidence that something is wrong at that point in the journey. It is unreliable as a description of what would fix it, and the two get conflated because the requestglossary×RequestA request is an action sent from a client to a server asking for data or a service.Open glossary term→ arrives sounding like a specification.

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→, this became obvious quickly. Users were going through a booking journey where the early stages felt smooth and exploratory. But as they got closer to committing, hesitation crept 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.

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 journey. 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×ContextContext is the set of surrounding conditions that shape how someone behaves and decides, including their goal, their environment, their time pressure, and what happened immediately before. The same action can mean different things in different contexts.Open glossary term→, and ultimately 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.

The general shape is worth recognising because it recurs constantly. A requestglossary×RequestA request is an action sent from a client to a server asking for data or a service.Open glossary term→ for more of something is usually a request for reassurance, and reassurance is rarely delivered by volume. It comes from knowing what happens next, what it will cost, and whether the decision can be undone.

Across NHS work, 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 right. But when you start designing for that, it very quickly becomes overwhelming. 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.

Everything in one place is probably the most common versionglossary×VersionA version is a specific iteration of software or a product at a point in time.Open glossary term→ of it. Taken literally it produces a page nobody can scan. Taken as a signal, it usually means people have been made to hunt across several places and do not trustglossary×TrustUser confidence that a product, service, or organisation will do what it promises.Open glossary term→ that they have found everything.

The distinction between access and guidance is the useful one to hold on to. Users asking for more access are frequently describing a structure that gave them no sense of where they were, and the fix is sequence and hierarchyglossary×HierarchyHierarchy is the organisation of elements to show importance and guide user attention.Open glossary term→ rather than volume.

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 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 how 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. 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 build something that works for them when they're actually using it. And those two things, more often than not, are not the same.

The habit that makes this work is asking what happened just before the requestglossary×RequestA request is an action sent from a client to a server asking for data or a service.Open glossary term→. Somebody wanting more control has usually just experienced something they could not predict or undo, and that event is far more actionable than the featureglossary×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→ they proposed in responseglossary×ResponseA response is the data or result returned by a server after receiving a request.Open glossary term→ to it.