Ask users what they do, not what they want.
"Run practical, scrappy user research that focuses on actual behavior."
Why this exists
If you ask users what they want, they will describe faster horses. The job is to understand the behavior beneath the request, including what they are trying to accomplish, where they get stuck, and what they have tried. Talk to them, watch them, and resist explaining your product while they struggle with it.
Operational Flow
Talk to actual users: Before starting a feature, interview at least three end users. Do not interview colleagues or the client's internal team. Schedule thirty minutes for each and record the call.
Structure the interview: Spend ten minutes on context, fifteen minutes on the problem area, and five minutes on open thoughts. Do not show your prototype in the first fifteen minutes.
Observe instead of asking for narration: Ask users to show you how they work instead of asking how they feel. Watching a workflow reveals more than listening to opinions.
Synthesize within 24 hours: Write a two-paragraph summary in Notion after each session. Detail your observations and the new questions raised. Insights decay quickly if left unprocessed.
Run quarterly usability tests: Recruit three to five users for a one-hour session on Maze or UserTesting. Watch them complete tasks in the live product. Note hesitation, mistakes, and questions.
Keep research focused: If you are designing a payment flow, talk only to people who pay for software. Do not run research for months just to avoid making a design decision.
What good looks like
- A spec opens with a quote from a user interview that is specific enough to show clear context.
- A planning meeting changes direction because three out of five interviewed users could not find a setting.
- A researcher updates the spec immediately after an interview because a key assumption was proven wrong.
What NOT to do
- Don't survey users when you need to understand behavior. Surveys capture opinions, but interviews show patterns.
- Don't present your solution during a discovery interview. Doing so biases every subsequent answer.
- Don't treat a single user's strong opinion as a trend. One passionate user is a data point, not a mandate.
- Don't skip research because the timeline is tight. Spending ninety minutes with three users is faster than two sprints of code rework.
The most expensive user research mistake is running it after you have already made your decision. It happens constantly: a team builds a feature based on intuition and then runs interviews hoping for validation. When users struggle, the team files the feedback under ‘edge cases’. We have made this mistake. We shipped a feature that failed, and the retrospective showed that interviewing two users beforehand would have redirected the entire build. Research is input for decisions, not decoration.
The practical step is simple: before you write a spec, talk to three people. Use Calendly, offer a £20 gift card, and record the session. Ask what they are trying to accomplish, watch where they get stuck, and listen for the moment they surprise you. That is the data point the spec needs. You are looking for the things you did not know you did not know, not confirmation.