Why research before building
Every software project rests on assumptions about people: that they have this problem, that they handle it in this way today, that they would use this feature, that they would switch from what they have. The team usually believes these firmly, because the idea came from someone who knows the field. Some of the assumptions are right. The trouble is that nobody knows which.
Research before development is the cheapest point at which to find out. A conversation costs an hour. A feature built on a wrong assumption costs weeks, and removing it later costs more. The purpose is not to ask users what to build. It is to understand their situation well enough that the team can decide what to build, and what to leave out, with evidence.
Start from the decisions
- 01
List the decisions ahead
Which users to serve first, which problem to solve first, which features are in the first release, which platform, what to charge.
- 02
List the assumptions behind each
For each decision, what the team currently believes about users that makes the planned answer correct.
- 03
Rate each assumption
How confident are you, and how costly would it be to be wrong? High cost and low confidence is where research belongs.
- 04
Turn those into research questions
Questions about people and their work, such as how do site managers record defects today and what goes wrong, not questions about your product.
- 05
Decide what would change your mind
Before you start, say what finding would lead to a different decision. If nothing would, the research is decoration.
Three to five research questions are enough for one round. A plan with twenty questions will answer none of them well.
Choose methods to fit the questions
| Method | Answers | Effort | Weakness |
|---|---|---|---|
| Interviews | Why people do what they do, what frustrates them, how they decide | Low to moderate | People describe an idealized version of their behaviour |
| Observation | What people actually do, including workarounds they no longer notice | Moderate | Needs access to the place of work |
| Review of existing data | How often things happen: support tickets, search logs, sales notes, analytics | Low | Shows what, rarely why |
| Survey | How widespread something is, across many people | Low to moderate | Only answers the questions you thought to ask |
| Competitor and alternative review | What people use today, including spreadsheets and paper, and why | Low | Tells you about products, not about your users |
| Prototype test | Whether people understand and can use a proposed design | Moderate | Needs a design to exist first |
For most projects before development, the core is a set of interviews combined with some observation and a look at data you already hold. Surveys are useful later, to check how common a pattern is once interviews have shown that it exists. A prototype test follows once there is something to show.
Decide whom to speak with
- 01
Who will use the product, by role?
Why it mattersBuyers, daily users and administrators have different needs. The person who signs the order is often not the one who uses the software.
- 02
How many in each group?
Why it mattersFor interviews, five or six people in a group usually reveal the main patterns. With more than one distinct group, speak to several from each.
- 03
Who is hard to reach but important?
Why it mattersField staff, night shifts, small customers. Their needs are the ones most often missed.
- 04
Are you including people who do not like the idea?
Why it mattersSceptics, former customers and those who chose a competitor are more informative than enthusiasts.
- 05
How will you find them?
Why it mattersExisting customers, sales contacts, professional communities or a recruitment service. Avoid relying only on friendly customers picked by the sales team.
- 06
What will you offer?
Why it mattersA fair thank-you for their time, and clarity about how the conversation will be used.
Ask about the past, not the future
The most common error in interviews is asking people to predict themselves. Would you use this? Would you pay for that? People answer kindly and inaccurately. What they did last week is evidence. What they say they would do is a guess.
Questions that produce evidence
- Tell me about the last time you had to do this
- What did you do first, and then?
- What did you use, and where did it let you down?
- What have you tried in order to fix that?
- How much time or money did it cost?
Questions that produce politeness
- Would you use a tool that did this?
- Do you like this idea?
- How much would you pay?
- Which of these features do you want?
- Don't you find that frustrating?
Prepare a short guide of topics, not a script, and let the conversation follow what the person says. Ask to be shown: the spreadsheet, the form, the screen, the notebook. Stay quiet after a question. Record with permission, and have a second person take notes so that the interviewer can listen.
A worked example
Research before building a maintenance app
This example is invented to show research changing a plan. A facilities company intends to build a mobile app for tenants to report maintenance problems.
- DecisionsWhether tenants or building managers are the first users, and whether photo reporting is the core feature.
- AssumptionsTenants are frustrated by reporting problems by phone, and would install an app to do it. Confidence is moderate. Being wrong would waste the whole first release.
- MethodInterviews with six tenants and five building managers, a day spent with one manager, and a review of three months of reported faults.
- FindingsTenants report a fault a few times a year and are content to send a message. None would install an app for it. Managers, however, re-enter every report by hand, chase contractors by phone and cannot tell tenants what is happening.
- ChangeThe first release becomes a tool for managers, with tenants reporting through a simple web form and receiving status updates by message. No tenant app is built.
Two weeks of research replaced the planned product with a different and smaller one, aimed at the people who had the real problem. The original app would have launched to tenants who had no reason to install it.
Turn what you heard into decisions
- Review together, soon. After each interview, the people present write down what they observed while it is fresh. Within days of the last one, the team reviews everything together.
- Look for patterns. Group observations across participants. A problem raised by one person is an anecdote. The same workaround seen in most sessions is a finding.
- Separate observation from interpretation. What people did and said, then what you think it means. Others should be able to disagree with the second without doubting the first.
- Answer the research questions. For each, what you now believe, how confident you are and what evidence supports it.
- State what changes. Features added, removed or reordered, users reprioritized, assumptions still open. This list is the product of the research.
- Keep it short. A few pages with quotes and photographs, read by the people who decide, beats a long report that is filed.
Research feeds directly into discovery and requirements. Our guide to what a product discovery workshop should deliver describes the stage that follows.
Consent, privacy and fairness
Tell participants who you are, why you are asking, how long it will take and what will happen to what they say. Ask before recording. Store recordings and notes securely, share them only with the people who need them, remove names from anything circulated more widely and delete the material when it is no longer needed. Where you are researching with employees, make clear that the subject is the work and the tools, not their performance, and that their managers will see findings without names.
Research planning checklist
User research planning checklist
0 of 11 checkedWhat to do next
Write down the three beliefs about your users that the project depends on most, and beside each how you know it. Where the answer is that everyone says so, you have your first research question. Then book conversations with five people who would use the product.
Our product design services page describes how research fits into our design work, and product discovery workshops build on it. Tell us what you are planning to build and who it is for.
Common questions
How many users do we need to interview?
For interviews aimed at understanding a problem, five or six people from each distinct group of users usually reveal the main patterns, after which sessions start repeating. More groups mean more interviews. If you need to know how widespread something is across a market, that is a question for a survey or data, after interviews have shown what to count.
Can we skip research if we know the industry well?
Experience gives you good assumptions, and research tests them. Experts are often right about the problem and wrong about how people currently cope, what they would change and who decides. A handful of conversations will either confirm your view cheaply or reveal the gap before it becomes expensive. Either result is worth an afternoon.
How long does user research take before a project?
A focused round can be planned, carried out and reviewed in a short period, with recruitment usually the slowest part. It should be sized to the decision: a large investment deserves more than a small feature. Research that runs on for months without changing any decision has lost its purpose.
Should developers and stakeholders attend interviews?
Yes, as silent observers, a few at a time. Hearing a user describe a problem in their own words persuades more than any report, and it gives the people building the product a picture of who it is for. Brief them to listen and not to explain or defend the idea during the session.
What if research contradicts what management wants to build?
Present what was observed, with quotes and examples, and what it implies for the plan, without overstating a small sample. The decision still belongs to the business. Often the result is a narrower first release aimed at the confirmed need, with the disputed features held until more evidence exists. That is a reasonable outcome for everyone.