Teams often confuse talking to users with understanding them.
On fast-moving projects, pressure builds quickly. People want momentum, delivery needs clarity, and somebody always wants to know what should be built next. So a developer, Product Owner, or delivery lead sits down with a user, asks what they want, writes down a few requirements, and gets the work moving.
From a distance, that can look user-centred. The team spoke to users, listened carefully, and responded.
But that kind of conversation often gives you a shopping list rather than insight. And once that happens, the team starts treating user requests as answers instead of clues.
Where this goes wrong
Users are usually very good at describing what is frustrating, slow, repetitive, confusing, or risky in their day-to-day work. That matters because it gives teams access to the reality of the service, rather than the tidier version that lives in process maps and governance decks.
The trouble starts a step later.
People usually describe problems through the lens of the systems and processes they already know. So the fixes they ask for tend to fit the current setup: a new field, another status, a dashboard, an alert, a report, an extra step that gives them more control over a messy part of the process.
During a legacy migration, that often shows up as a push to recreate the old workflow in the new system, just with a cleaner interface.
Those requests often come from real pain. Sometimes they do point towards a useful change. But they are still only one view of the problem. If the team treats the request itself as the solution, the work can move quickly while the underlying issue stays exactly where it was.
A simple caseworker example
Take an internal caseworking service.
A caseworker may spend all day moving between systems, chasing missing information, checking guidance, copying updates into notes, and trying to keep cases moving. They know where the work slows down, which steps are unreliable, which details go missing, and which parts of the process create the most rework. In many cases, they are extremely good at the job.
So when you ask what would help, you might hear: “We need another status for cases waiting on external information.”
That request makes perfect sense from where they sit. They may have spent months or years dealing with cases that appear stuck, trying to work out what is happening, answering the same questions from colleagues, and carrying the risk of something being missed.
Asking for another status is a sensible response to friction they deal with every day.
What it does not tell you on its own is whether a new status is the right fix.
The bigger issue may sit somewhere else. The handoff into that stage may be too vague. The service may capture the wrong information at the start. Different teams may be using existing statuses in different ways. People may be relying on notes and memory because the workflow itself is poorly structured.
And the caseworker may never have had the time, permission, or distance from the work to question the shape of the process as a whole, because they are focused on doing the job in front of them and doing it well.
So the team hears “we need another status”.
The more useful question is: what is happening in the service that makes the current flow so hard to manage?
That is the point of research.
Why teams slip into order-taking
Part of it is pace. A request from a user feels actionable. It turns neatly into a ticket, creates visible movement, and gives the team something concrete to point at in planning or in a demo.
Part of it is discomfort. Understanding a problem properly takes longer. It means asking follow-up questions, sitting with uncertainty, and sometimes finding that the issue is broader than the team hoped. It may involve service design, policy, operations, content, training, handoffs, or governance. A feature request is much easier to hold than a messy problem with several causes.
Part of it is good intentions. Teams want to show that they are listening. The problem starts when listening gets reduced to building the thing that was asked for.
Once that happens, research starts collapsing into requirement capture with softer language.
What useful research gives you
Better user research means getting closer to the work itself.
You want to hear about the task, the blockers, the context, the dependencies, the workarounds, the judgement calls, and the consequences when things go wrong. You want to know what people are trying to get done, where the service makes that harder than it needs to be, and how they compensate when the system falls short.
That usually means spending less time asking what should be built and more time asking:
- what were you trying to do?
- what happened instead?
- what did you need at that point?
- how did you work around it?
- how often does this happen?
- who else gets pulled in?
- what is the risk when it goes wrong?
Those conversations give you something more useful than a list of requested features. They give you the shape of the problem, and once you understand that, you have room to make better design and product decisions.
Requests still matter
None of this means user requests should just be ignored. They still matter.
Requests from users are often valuable because they point directly at pain, reveal repeated failure points, and help you hear the language people use in their actual work. Occasionally, the thing somebody asks for really is what is needed.
But it's much more helpful to treat requests as evidence instead of instructions.
A request tells you where frustration has built up enough for somebody to name a fix. That is useful. It does not remove the need for judgement. The team still has to work out what is causing the friction, who else is affected, what trade-offs are involved, and whether the request would solve the problem well enough in practice.
Stop calling every user conversation research
If the main output from your sessions is a list of things people asked for, you may have learned something useful about demand, frustration, or expectations. But you may still be some distance from understanding the problem properly.
Good research gives a team a clearer view of the work, the constraints around it, and the reasons people have ended up asking for what they ask for.
That is when you can move from “what should we add?” to “what is making this work harder than it needs to be?”
And that is usually where the better decisions start.
