On this page
User research is the work of systematically engaging with users, observing their behavior, and gathering their feedback to inform product and business decisions. Its value isn't in learning about users for its own sake, but in making a specific decision rely less on guesswork. By the end of this article, you'll be able to tell what question each common research method answers, know the steps a study goes through from framing the question to delivering findings, and have a list of questions to answer before you start a study.
What is user research?
User research studies people: who they are, what they're trying to get done, in what context they use a product, what difficulties they run into, and how they make choices. The people you study can be current users, churned users, or potential users who haven't used the product yet.
It's different from routine user feedback. App store reviews, support tickets, and secondhand reports from sales are all useful leads, but they come from the few people who speak up on their own, and they aren't designed in advance. User research starts with the question you want to answer, then picks the right people and methods to gather evidence, and finally turns that evidence into findings you can test.
The types of questions user research answers
Most research questions fall into the five types below. Figure out which type yours is first, and you're less likely to pick the wrong method.
- Who users are and what they're trying to get done: the goals, usage contexts, and alternatives of different groups. Jobs to be Done (Clayton Christensen) takes this approach, understanding needs by starting from the job users want to get done.
- Why things happen: why users churn, why they don't pay, why they chose a competitor. Questions like these need interviews to draw out specific experiences and reasons.
- Whether people can use it smoothly: whether users can complete key tasks such as signing up, placing an order, or setting things up on their own, and where they get stuck.
- How many and what proportion: how common a need or problem is among users, and how different groups compare.
- Whether a change worked: after a new design, copy, or price goes live, did the key metrics actually change?
The first two types and the third are about exploring and explaining, and usually call for qualitative methods. The last two are about measuring and validating, and usually call for quantitative methods. A single project often runs into several of these in turn.
Common methods at a glance
| Method | Main questions it answers | Strengths | Limitations |
|---|---|---|---|
| User interview | Why, how it happens, what users are trying to get done | Lets you probe for specific experiences and motivations, and uncover problems you didn't anticipate | Small samples, can't estimate proportions; results are shaped by how questions are asked |
| Usability testing | Whether users can complete tasks, and where they get stuck | Shows real behavior directly; Nielsen (2000) found that about 5 users per round uncover most usability problems | Only evaluates existing designs or prototypes; doesn't tell you whether to build something |
| Survey | How many people, what proportion, how groups differ | Large samples, allows statistical comparison, relatively low cost | Can only ask questions you thought of in advance; answers are self-reported, not actual behavior |
| Focus group | What views a group of people holds on a topic | Reaches several people at once and lets you hear different views play off each other | Easily swayed by a few vocal people; not suited to understanding individual behavior in detail |
| Diary study | How behavior happens and changes over time | Records are made close to when things happen, so you can see repeated behavior and context | Takes a long time; participants tend to drop out midway and need ongoing follow-up |
| Behavior data analysis | What users actually did, and where they dropped off | Covers all users and reflects actual behavior rather than self-reports | Shows what happened but not why; depends on the quality of event tracking |
| A/B testing | Whether a change moved a metric | Establishes cause and effect; results can directly inform whether to launch | Requires enough traffic and time; can only compare options that are already built |
You can classify these methods in two ways. First, whether they capture what users say or what they do: interviews and surveys capture the former, behavior data analysis and A/B testing the latter. Second, whether they answer why or how many. What people say and what they do often differ, so important findings are best backed by both kinds of evidence.
The basic steps of a study
- Write down the business question and the decision to be made, for example "Should onboarding go from five steps to three?", and confirm who will make the decision and when.
- Break the business question into a few specific research questions, decide which type each one is, then choose methods.
- Define who to study: what criteria participants must meet, how many of each group you need, and where to recruit them.
- Prepare research materials: the interview guide, test tasks, survey questions, or experiment design. Pilot them on a small scale before starting for real.
- Run the study, keep the raw material as you go, and exclude responses that don't meet the criteria or are clearly low-effort.
- Analyze and write up findings: for each finding, state where the evidence comes from, how many people it involves, and whether there are counterexamples.
- Hand the findings to the team responsible, agree on what changes to make based on them, and decide what data will be used to check those changes after they ship.
The decision to be made sets the scope of the research. If you can't say what decision you're making, stop and get clear on that before discussing methods.
- Which decision does this study need to support? Who will make it, and by when?
- Without this study, how would the team decide right now? Based on what?
- What do we already know? What existing data, feedback, or past research do we have?
- What are the 3 questions we most want answered? Which type is each one?
- What kind of result would make us change our current plan?
- Who do we want to study? How will we find them, and is there anyone we need to exclude?
- What method will we use? Why can it answer the questions above?
- How large a sample, how much time, and how much budget do we need? Who will run it?
- Who gets the findings? In what format?
- After the change ships, what behavior data or metrics will tell us whether the findings hold?
- What personal information is involved? How will we inform participants and get their consent?
When to do research, and when you don't need to
When research is worth doing
- The decision is costly and hard to reverse, such as entering a new market, redesigning a core flow, or changing prices
- People on the team disagree sharply about users, and no one has evidence
- A metric has changed noticeably, but no one can say why
- You're building for an unfamiliar group, such as a new region, industry, or age group
- You're about to commit significant development resources and want to confirm the need is real first
When you can skip research or do less
- The change is small, quick to ship, and easy to roll back, so shipping it and watching the data saves more time than researching first
- The decision has already been made and won't change, so research would only serve as an endorsement
- Existing data and past research can already answer the question
- There's enough traffic to compare a few options directly with an A/B test
- The issue is a technical or compliance constraint that user opinion can't change
Skipping research doesn't mean ignoring users. After a small change ships, you still watch the data and read feedback; you just don't need a dedicated study.
Common mistakes
These mistakes are the most common in teams that are new to research. Most come from an unclear question, the wrong method, or misused findings.
Common mistakes
- Asking users directly what features they want: users are good at describing their experiences and difficulties, not at designing solutions. Ask what they did the last time they ran into the problem. The Mom Test (Rob Fitzpatrick, 2013) covers this in detail.
- Using interview results to estimate proportions: if half of a dozen or so participants mention something, that doesn't mean half of all users do. When you need proportions, validate them with a survey or behavior data.
- Only talking to the most active, most cooperative users: their views often differ from those of the silent majority and of churned users. Set recruiting criteria based on the research question, and make a point of including groups that rarely show up.
- Figuring out how to use the research only after it's done: lots of findings, none tied to a decision. At kickoff, write down who gets the findings and what they'll be used to decide.
- Treating one study as the final word: users and markets change, and findings apply to specific people and a specific time. Recheck important findings with data after the change ships.
- Listening to what users say but not watching what they do: self-reports and actual behavior often don't match. When you can, compare interview findings against behavior data.
How to do it in heari
In heari, you enter the business question and the decision to be made, and AI generates a research plan and interview guide. AI runs many interviews at once by text or voice and asks follow-up questions based on the answers. Every insight in the report comes with quotes and counterexamples and is labeled with participant counts, and you can accept, edit, or reject each one. Connected to ThinkingAI Agentic Engine, heari lets you select participants by behavior and validate findings with behavior data after changes ship.
FAQ
What's the difference between user research and market research?
They overlap but focus on different things. Market research looks more at market size, the competitive landscape, and brand awareness, and often uses large-sample surveys. User research looks more at how specific people use a product, what difficulties they run into, and why they make the choices they do, and often uses interviews, usability testing, and behavior data. Product teams usually need both kinds of information to make decisions.
Can a small team without a dedicated researcher do user research?
Yes. A product manager, designer, or operations person can take on the research lead role. Start with small, focused studies, such as interviewing 6 to 8 users around one decision or having 5 users try a new flow, then gradually build recruiting channels and a research repository. The key is to write down the decision the study supports beforehand and hand the findings to the person responsible afterward.
How long does a user research study usually take?
It depends on the method and scale. A round of usability testing or a dozen or so interviews usually takes one to three weeks from preparation to findings, and recruiting participants is often the slowest part. A diary study has to cover a long enough usage cycle, and an A/B test has to wait until the sample is large enough. When time is tight, narrow the research question rather than skipping analysis and review.
What makes a user research finding credible?
A credible finding can say which people and how many the evidence came from, can be traced to the raw records, and states the counterexamples and where it applies. Qualitative findings tell you what situations exist and why they happen; quantitative findings tell you proportions and differences. Ideally, test important findings again with behavior data or an experiment after the change ships.
