How to conduct user research: a practical guide
The short answer
To conduct user research, start with the decision you need to make, pick the method that answers it, recruit people who match your real users, and run short, structured sessions. Then transcribe, break the notes into small insights, group them into an affinity map and turn the key insights into specific design decisions.
What is user research and when should you do it?
User research is the work of finding out what people need, how they behave and where they struggle, so design decisions are based on evidence rather than opinion. Do it before you design, to understand the problem, and again before you build, to check that the design works. For an existing product, do it whenever the numbers show a problem you cannot explain.
Good research starts with a decision, not a method. Write down the question the team needs answered, for example "Why do new accounts stop after the first week?" or "Which of these two navigation structures do people understand?". The question decides the method, the people you recruit and what you do with the results.
Which user research method should you choose?
Choose the method by the type of answer you need: interviews and focus groups explain why, surveys and analytics measure how many, and usability tests show whether a design works. Most projects use two or three methods together, one to explore and one to confirm.
| Method | Answers what | When to use it | Sample size |
|---|---|---|---|
| Interviews | Why people act as they do, their goals, habits and workarounds | Early, before defining the product or a new feature | A small number per user type, until answers start to repeat |
| Focus groups | Shared attitudes, language and reactions to concepts | When you need many opinions quickly or want to see how people discuss a topic | Small groups for depth; larger live sessions when you need breadth |
| Surveys | How common a need, behaviour or preference is | After interviews, to check that a pattern holds across many people | Large enough to compare the groups you care about |
| Usability tests | Whether people can complete a task with a design, and where they fail | On prototypes before building, and on live products | A handful per round, with repeated rounds after each fix |
| Analytics | What people actually do, where they drop off, which features they use | On any live product, before and after changes | All real usage data you have |
| Competitor audits | What users already expect and where existing products fall short | At the start of a project and before major redesigns | The few products your users actually compare you with |
How do you recruit participants for user research?
Recruit people who match your real or intended users in the behaviours that matter, not just in age or job title. A finance app needs people who manage their own money, and a dashboard for operators needs people who run operations every day.
- Write a short screener with questions about behaviour, for example how often they do the task and which tools they use now.
- Recruit from your own users first: customer lists, in-app prompts, support contacts or partner companies.
- Include the people who find the product hardest, not only confident users. They reveal problems others work around.
- Recruit in the languages your users speak. We run research in both English and Arabic.
- Offer a fair incentive and make scheduling simple.
How do you run a user research session?
Run each session from a short guide that lists the questions or tasks, and let the participant do most of the talking. The guide keeps sessions comparable. Listening, not presenting, is what produces useful answers.
- Ask about specific past events: "Tell me about the last time you did this" gives better answers than asking what people would do.
- Use open questions and avoid suggesting an answer.
- In usability tests, give a goal, not instructions, and ask people to think aloud.
- Stay quiet when the participant struggles. The struggle is the finding.
- Record the session with consent, and have a second person take notes.
How do you analyse user research findings?
Analyse findings by breaking every session into small, single observations and grouping them until patterns appear. This is the pipeline we use on every project:
- Transcribe every session so nothing depends on memory.
- Split into nuggets. Break each transcript into nugget-sized insights, one observation, quote or behaviour per note, tagged with the participant.
- Group into an affinity map. Cluster related nuggets and name each cluster by what it says, for example "Users do not trust the total until they see the fees".
- Distil key insights. Reduce the clusters to a short list of key insights, each backed by several participants and linked to the evidence.
Keep the link from each key insight back to the original quotes. When someone questions a decision later, the evidence is one click away.
How do you turn research insights into design decisions?
Turn each key insight into a specific statement of what the design must do, then check the design against it. An insight such as "Operators check a booking's status before anything else" becomes a decision: status is the first column in the bookings table and can be filtered in one step.
- Write each insight as a design requirement the team can test.
- Rank requirements by how many users they affect and how close they are to the main task.
- Sketch flows and wireframes against the requirements, not against a list of features.
- Test the prototype with new participants and check whether the original problems are gone.
Research is only useful if it changes the product. That is why it sits at the start of our process and why our UX research work always ends with decisions and a tested prototype, not only a report.
Related services
