How much user research is enough before building software?

Start with decisions, not a number

There is no universal number of interviews that makes software safe to build. Five conversations can reveal a strong pattern in a narrow audience, while twenty can remain inconclusive if the participants are vague or unrelated to the intended user. The useful question is not “How many people should we interview?” It is “Which decision must this research support?”

List the decisions that could change the project. Do people experience the problem often enough? Is the proposed audience reachable? Does the current workaround create meaningful cost? Would users change behaviour, and who would pay? Does an app fit the situation better than a website or service? Research is enough for the next step when these important uncertainties are reduced to an acceptable level.

Write down assumptions before speaking to anyone. Otherwise a conversation can feel informative while quietly confirming what the team already believes. Label each assumption as known, uncertain or risky. Focus time on assumptions that could make the product unnecessary, difficult to sell or impossible to deliver.

Recruit people who experienced the problem

The quality of research depends heavily on participant relevance. Recruit people who match the intended context and have recently experienced the behaviour. A general interest in technology is not enough. A person may like the concept but never face the problem, control the budget or influence the purchase.

Ask about a recent event. What happened first? What did the person do next? Which tools, people or documents were involved? Where did time, money or confidence disappear? How was the situation resolved? Concrete stories expose workarounds and priorities better than predictions about what someone might do later.

Include different roles when the product has more than one. A customer, administrator and decision-maker may describe the same workflow differently. Do not average their needs too early. Map where their goals overlap and where the product would need different content, permissions or support.

Ask questions that reveal behaviour

Avoid leading questions such as “Would you use an app that sends reminders?” They invite polite agreement and encourage people to design the solution for you. Ask what they do today, how often the problem occurs, what they have tried and what happens when they do nothing. Follow up on details instead of rushing to the next question.

Listen for evidence of priority. People who have created a spreadsheet, paid for a workaround, changed suppliers or built a manual process are showing effort. People who say a problem is interesting but have no current response may not feel enough urgency. Both answers are useful if interpreted accurately.

Share a concept only after understanding the current situation. Ask the person to react to a specific flow or prototype, then observe what they expect to happen. Do not measure only whether they like the wording. Check whether they can complete the task, explain the benefit and identify what would stop them using it.

Look for patterns and meaningful differences

After each research round, record observations using the same structure. Note the user context, problem, current workaround, frequency, consequence, desired outcome and evidence strength. Separate direct quotes from your interpretation. This makes it easier to see whether a pattern is real or simply memorable.

Patterns do not mean every participant says the same sentence. They may share a trigger, workaround or consequence while using different language. At the same time, differences matter. A problem may be urgent for one segment and minor for another. A feature may help a customer but create administration for the business. Segment findings instead of forcing a single average user.

Use a small evidence board or research summary. Mark assumptions confirmed, contradicted and unresolved. The purpose is not to produce a beautiful document. It is to make the next decision visible to the whole team and stop the loudest opinion from becoming the roadmap.

Set a stopping rule

Define before the next round what would be enough evidence to proceed. You might require a repeated problem across a defined segment, a clear workaround, a credible buyer and a successful test of the core task. The threshold should match the risk. A cheap prototype needs less certainty than a regulated workflow or a large integration project.

Watch for diminishing returns. If several relevant conversations reveal the same trigger, need and workaround, more interviews may add detail without changing the decision. That is a reason to move to a prototype, pilot or pricing test. If every conversation introduces a completely different problem, the audience or question may still be too broad.

Stopping does not mean believing every assumption is solved. Record remaining risks and decide how to address them through design, a limited pilot or post-launch measurement. Research should create a responsible next step, not a claim of certainty.

Turn evidence into a buildable plan

Summarise the research in terms of product decisions. State the first audience, problem, core behaviour, evidence, unresolved risks and the smallest test or product that follows. Remove features that appeared only because someone mentioned them unless they support the proven outcome. Make acceptance criteria observable so the team can tell whether the first version works.

Plan what must be learned after launch. Analytics can show activation, completion, errors and return behaviour. Support conversations can reveal confusion and missing content. A pilot can test operational load and integration reliability. Pre-launch research and post-launch learning are connected, but they should not be used to postpone action forever.

Enough research is reached when the team understands the important user problem, can identify a narrow first audience and has evidence for the next step. The aim is informed movement, not perfect certainty.

Sources

• User interviews · Nielsen Norman Group
• Events · Google Analytics

Frequently asked

How many user interviews are enough?

Enough interviews reveal repeated patterns among relevant participants and reduce the uncertainties that could change the decision. The number depends on audience size, problem variation and project risk.

Should I show my app idea during an interview?

First understand the current problem without showing the solution. Then use a prototype to test comprehension and task behaviour, not just whether people say they like it.

What if every interview gives a different answer?

Check whether the audience is too broad, the question is unclear or the problem is not shared. Segment the findings before deciding that research has failed.

Can research delay development too long?

Yes. Use a stopping rule and move to the cheapest experiment that can answer the next question. Research and building should form a learning cycle rather than separate endless phases.