Conducting user research well depends less on methodology than on asking questions that produce reliable answers. People are poor at predicting their own future behaviour and good at describing what they actually did, which means most research failures come from question design rather than sample size or technique. This guide covers how to choose a method for your question, how to interview without leading, how many people you genuinely need, and how to turn findings into decisions rather than a report nobody uses.
Start From the Decision, Not the Method
Research that begins with a method produces findings looking for a purpose. Starting from the decision you need to make determines which method fits and how much evidence is enough. It also prevents the common outcome where research confirms what the team already believed, because a decision framed honestly can have more than one answer.
Write Down the Decision First
State what you will do differently depending on the outcome. If no decision changes either way, the research is not worth running.
Distinguish Behaviour From Preference Questions
What people do requires observation. What they value can be asked. Confusing the two is the most common source of misleading research findings.
Choose the Cheapest Adequate Method
Existing support tickets often answer the question without any new research. Our data analytics work frequently surfaces answers already present in behaviour data.
Set a Falsifiable Expectation
Record what you expect to find before starting. This makes it visible when research confirms a bias rather than testing one.
Interviewing Without Leading
Interviews are the most useful and most easily corrupted research method. A leading question produces a confident wrong answer, and the person will be entirely sincere. The discipline is asking about specific past behaviour rather than general opinion or future intent, then staying quiet long enough for the useful detail to emerge.
Ask About the Last Time, Not In General
Specific recent episodes produce accurate recall. General questions produce an idealised account of how someone believes they behave.
Never Ask if They Would Use It
Hypothetical future behaviour is unreliable and consistently positive. Ask what they currently do about the problem and what that costs them.
Follow the Workaround
When someone mentions a spreadsheet, a manual step, or a habit, pursue it. Workarounds identify genuine requirements more accurately than requested features.
Tolerate Silence
Pausing after an answer produces elaboration. Filling the gap yourself replaces their thinking with your prompt, which is where interviews most often go wrong.
Separate Observation From Interpretation
Record what was said and done separately from what you concluded. Our UI/UX design research keeps these distinct so conclusions remain challengeable.
Observation and Usability Testing
Watching someone attempt a task produces information no interview can, because people omit steps they no longer notice and describe intentions rather than actions. The method is simple and the discipline is difficult, since the instinct to help is strong and helping destroys the test entirely.
Give a Task, Then Stop Talking
State the goal and let them proceed. Every clarification you offer removes the information you were there to collect.
Watch Where They Hesitate
Pauses, backtracking, and misdirected attempts identify friction more reliably than anything a participant says afterwards.
Test With People Outside the Team
Colleagues know the intended path and cannot unsee it. Their success demonstrates nothing about a new user’s experience.
Use Realistic Tasks and Data
Artificial scenarios with clean data produce artificial results. Real tasks with realistic content surface the problems that actually occur.
Five to Eight People Is Usually Enough
That range surfaces most significant usability problems. Beyond it you see repetition and would learn more by fixing what you found, then retesting.
Research Without Budget or Time
Most teams have less research capacity than they would like, which is a constraint rather than a reason to skip it. Several methods cost almost nothing and use evidence you already hold. The realistic alternative to imperfect research is not perfect research, it is deciding on assumption, which is considerably worse.
Mine Support and Sales Conversations
Tickets, call notes, and churn reasons contain research you already paid for. This is the fastest available source of evidenced problems.
Talk to Five People This Week
Six to eight conversations reveal recurring patterns. Scheduling them is usually the obstacle rather than any methodological difficulty.
Use Behavioural Data as a Starting Point
Analytics shows where people struggle without explaining why. Use it to identify where to look, then talk to people about that specific step.
Run Short Focused Sessions
Thirty minutes on one question beats a ninety-minute session covering everything. Shorter sessions are easier to schedule and easier to analyse.
Validate Before Building
Testing an assumption costs days, building on a wrong one costs months. Our MVP development approach sequences this deliberately.
Turning Findings Into Decisions
Research that ends in a document has failed. The output should be a decision or a changed priority, ideally recorded where the team will encounter it. Findings that live in a folder get cited selectively months later by whoever remembers the part supporting their position, which is worse than no research at all.
Report Findings, Not Volume
Three findings that change decisions beat forty observations. Length signals effort rather than value and reduces the chance anyone reads it.
Separate Evidence From Recommendation
State what you observed and what you propose separately, so others can disagree with your recommendation while accepting your evidence.
Quantify Where You Can
Note how many participants encountered each problem. This prevents a single vivid comment outweighing a pattern seen repeatedly.
Connect Findings to Backlog Items
Attach findings to specific tickets or requirements. Our custom software development engagements trace requirements back to their evidence for exactly this reason.
Record What You Chose Not to Act On
Documenting deliberately deferred findings prevents the same discussion recurring and preserves the reasoning for later.
FAQs
How many people do I need for user research?
Five to eight participants surface most significant usability problems in testing. For interviews, six to eight conversations typically reveal recurring patterns. Beyond that you see repetition, and you would learn more by acting on findings then testing again.
What questions should I avoid in user interviews?
Anything hypothetical, particularly whether someone would use or pay for something. Future intent is unreliable and consistently optimistic. Ask what they did last time they faced the problem and what that cost them in time or money.
What is the difference between user research and usability testing?
User research explores who people are, what they need, and how they currently work. Usability testing observes whether people can complete tasks with a specific design. Research shapes what to build, usability testing checks whether the build works.
Can I do user research without a budget?
Yes. Support tickets, sales call notes, and churn reasons contain evidence you already hold. Add six to eight short conversations with actual users. Scheduling is usually the real obstacle rather than cost or methodological complexity.
How do I stop research confirming what we already believe?
Write down what you expect to find before starting, frame the decision so more than one outcome is genuinely possible, ask about past behaviour rather than opinions, and record observations separately from your interpretation of them.
What should a research output look like?
Three to five findings that change decisions, each with how many participants encountered it, evidence separated from recommendation, and links to specific backlog items. Long reports signal effort rather than value and reduce the chance anyone acts on them.
