If you work in UX long enough, you start to notice a pattern. Stakeholders love feedback. Surveys, NPS scores, interview quotes neatly highlighted in decks. It all feels concrete and reassuring. Someone said a thing, therefore we know a thing.
But most of the real insight does not come from what users say. It comes from what they do, what they hesitate over, what they avoid, and what they quietly work around. Observation is where understanding actually starts.
This is not an argument against listening to users. It is an argument for not stopping there.
Users are honest, but they are not objective
When users give feedback, they are usually trying to be helpful. They answer questions sincerely. The problem is not dishonesty. The problem is that people are not especially good at explaining their own behaviour, particularly in abstract or hypothetical terms.
Ask someone why they abandoned a flow and you might hear “it was confusing” or “it took too long”. Both may be true, but neither tells you where confusion started or what “too long” really means. Ask them what feature they want and they will often describe a solution that makes sense to them, based on their own mental model, not the constraints or goals of the product.
Observation bypasses this. You do not have to rely on memory or interpretation. You can see exactly where someone pauses, scrolls back, rereads, clicks the wrong thing, or opens a new tab to work around your design. Those moments are rarely mentioned in feedback, but they are where the real problems live.
Feedback is shaped by the question you ask
Another quiet issue with feedback is how much it depends on framing. Ask “Was this easy to use?” and you will get polite agreement. Ask “What did you find frustrating?” and you will get a list, but only of what the user consciously noticed and remembered.
Observation does not care about your question. It shows you behaviour as it happens. You might think you are testing navigation, but end up discovering that users do not trust your labels. You might think onboarding is the problem, but realise people are actually stuck because they do not understand the underlying concept your product is built around.
Some of the most valuable insights come from things you were not looking for. You only get those when you watch without over-directing.
What people say they want is often a proxy
When users ask for something, it is usually a signal, not a specification. “I want a download button” might really mean “I do not trust that this will be saved”. “I want fewer steps” might mean “I do not understand why I am being asked for this information”.
If you take feedback at face value, you risk building the wrong thing very efficiently. Observation helps you see the need behind the request. When you watch someone struggle, the underlying concern often becomes obvious in a way no quote ever makes clear.
This is especially important with experienced users. They are often very good at telling you what they think the product should do, based on how they have learned to use it. But those adaptations can hide serious usability issues that new users will hit immediately. Observing both groups side by side is often uncomfortable, and very revealing.
Social pressure changes what people say
People are polite. They do not want to sound stupid. They do not want to criticise something you clearly worked hard on. In interviews, especially moderated ones, users tend to soften their language or blame themselves.
You can hear this in phrases like “I might have missed it” or “I’m probably doing this wrong”. When you observe behaviour, that self-censorship disappears. Confusion is visible whether the user wants to admit it or not.
This is one reason why watching recordings of unmoderated sessions, or sitting quietly during a usability test, can be so powerful. You are not negotiating the truth socially. You are simply witnessing it.
Observation builds shared understanding
Another underrated benefit of observation is what it does for teams. A single video clip of a user failing to complete a task can do more than weeks of debate. It removes abstraction. There is no arguing with someone clicking the same thing three times and getting nowhere.
Feedback summaries often become opinionated by the time they reach decision-makers. Observation cuts through that. When designers, developers and product managers watch the same behaviour, they tend to align quickly on what actually matters.
This is not about catching users out. It is about grounding conversations in reality instead of interpretation.
Listening still matters, just not on its own
None of this means feedback is useless. Listening is essential for understanding motivation, expectations and emotional response. Observation shows you what is happening. Conversation helps you understand why it feels the way it does to the user.
The mistake is treating feedback as evidence rather than input. Feedback suggests where to look. Observation tells you what is really going on.
The strongest UX work usually combines the two. You watch someone struggle. You ask them what they were expecting. You notice the gap between those things. That gap is where design decisions should come from.
If you had to choose one
If you are forced to choose between observing users and collecting feedback, choose observation. You can design a good product without ever running a survey. You cannot design a good product if you never see how people actually use it.
Watching users can be uncomfortable. It exposes assumptions. It challenges pet ideas. It slows you down in the short term. But it is also the fastest way to stop guessing.
And in a field that often claims to be user-centred, actually watching users is the most honest place to start.
