.webp)
UX research
Most teams have shipped a feature that users asked for and then never touched. It is tempting to blame the users. It is more useful to blame the method: asking people what they want is one of the least reliable ways to find out.
What people say, what people do, and what they say they do are entirely different things.
Margaret Mead, as it is usually quoted
Why the answers drift
Nobody is being dishonest. Three ordinary habits of the mind get in the way of a straight answer.
- Bias. People say they want a simple interface because that sounds sensible, then reach for the option with the most features.
- Memory. We rebuild past events as we recall them, filling gaps and quietly editing the story to suit how we see ourselves.
- Wanting to be liked. Faced with a researcher, people soften their opinions and say what seems agreeable.
Researchers have the same biases, which is why the fix is a better method and not a more suspicious interviewer.
Two kinds of evidence
Research methods fall into two groups, and a good study uses both. Attitudinal methods capture what people say: interviews, surveys and diary studies. They tell you about motives, expectations and feelings. Behavioural methods capture what people do: usability tests, analytics, A/B tests and watching someone in their own surroundings. They tell you what actually happens.
The same split runs along another line. Quantitative work, such as analytics and large surveys, answers "how many" and "which one". Qualitative work, such as interviews and observation, answers "why". Numbers show you where people leave; conversations show you the reason.
Getting more honest answers
- Ask about the past and about specifics ("tell me about the last time you booked a trip") rather than about the future or in general.
- Ask indirectly. "How would a typical customer use this?" lets people be candid without feeling judged.
- Make the room feel safe. Say plainly that you are testing the design, not them, and that nothing they say is wrong.
- Set what people say next to what they do, and trust the second when they disagree.
A sequence that works
- Start with behaviour. Look at analytics and watch real use to see what people actually do.
- Add the reasons. Interview people about the moments that stood out, to learn why.
- Test your guess. Put a prototype in front of people before you build it.
- Repeat. Needs shift, so the research never really finishes.
Turning findings into decisions
Research that stays in a document changes nothing. Personas, journey maps and storyboards earn their place because they let a whole team picture the same person and the same difficulty. Keep them short, grounded in real observations, and tied to a decision someone has to make.
Your users are not lying to you. They are people, and people are not good witnesses to their own behaviour. Listen to them, watch them, and let each check the other.