Eight User Research Methods Compared, and When to Use Each

Start with the question, not the method

Before choosing a method, write down what you want to know. Most questions fall into two families. "Why" and "how" questions, such as why customers abandon a cart, need qualitative data. "How many" and "how often" questions need quantitative data.

Separate what people say from what people do. Survey answers often differ from real behaviour because people forget or want to be polite. If you need actual behaviour, observe it or read usage data. If you need feelings and reasons, talk to people directly.

Four methods where you talk to people or test with them

User interviews suit the early stage, when you are not sure what the real problem is. Plan for thirty to sixty minutes each and ask about past experience ("Tell me about the last time you ordered food through an app") rather than hypothetical opinions. The limit is that you hear from only a few people, so do not turn the results into percentages of your whole user base.

Surveys reach many people cheaply and work well for confirming what interviews suggested, though badly written questions produce skewed answers. A usability test asks people to complete real tasks on a prototype or live product while you watch where they struggle. Card sorting lets people group content topics in their own way, which helps with menus and information structure.

• Interviews: use for reasons and context. Limit: small number of voices.
• Surveys: use for a broad picture or to confirm a hunch. Limit: only as good as the questions.
• Usability tests: use once you have a prototype. Limit: show where people get stuck but not always how common it is.
• Card sorting: use when designing menus or categories. Limit: does not prove people will find things, so follow with a findability test.

Four methods that show real-life behaviour

A diary study asks participants to log their own experience over a period such as a week. It fits behaviour that happens outside a scheduled session, like daily money management or using a delivery app. The cost is participant effort and some drop-outs. An analytics review looks at data your product already collects, such as which page people leave most. It tells you what happened and where, but not why.

An A/B test compares two versions with real users to see which does better against a goal you set in advance. It needs enough users and enough time; with low traffic the result usually wobbles. Field observation means watching people work in their own place, such as a shop, a clinic or a warehouse. You see things nobody thinks to mention, like a sticky note on a monitor because the system is hard to use.

What users say and what users do rarely match, so keep both in your hands.

Choosing between them

If you do not yet know what the problem is, start with interviews or field observation. If you have a prototype and want to find where it breaks, run usability tests. If the menu structure worries you, try card sorting. Once the product is live and busy enough, review analytics to spot anomalies, then use an A/B test to prove a fix works.

Many teams get the best results by pairing the two kinds of data: quantitative data shows where the problem is, qualitative data explains why, and a second round of measurement checks the fix.

Small-sample tips

You do not need hundreds of participants to begin. For problem-finding usability tests, five people per user group often reveals the main issues in many projects. Treat that as a rough guide, not a rule. When user groups differ a lot, such as shoppers and back-office staff, test them separately.

Run small rounds rather than one big study: test three to five people, fix what you found, then test again. Avoid reporting percentages from a handful of people; describe what you saw and say how many of how many. Recruit people who match your real audience, because colleagues give very biased results.