Which UX research method should you use?
August 26, 2026
The most expensive mistake in research is not running a bad study. It is running a good study that answers a question nobody needed answered.
Most teams default to whichever method they know best, usually interviews, and stretch it to cover everything. Interviews are excellent for understanding why people behave as they do, and poor value for finding out whether a button is findable. Choosing well is what makes research fast.
This guide maps the common methods to the questions they actually answer.
Start from the question, not the method
Write down what you want to know as a question. Then find it below.
- Does our message land in the first few seconds? Five-second test.
- Which of these designs works better? Preference test.
- Can people find the right starting point on this screen? First-click test.
- Do our categories and labels match how users think? Card sorting.
- Can people find things in our navigation structure? Tree testing.
- Can people complete a task in the design? Prototype test or unmoderated usability test.
- How many people think or do X? Survey.
- Why did that happen, and what were they thinking? Moderated interview.
- How does behaviour change over days or weeks? Diary study.
If your question does not fit any of these, it is usually because it is not a research question yet. Sharpen it until it could be answered wrong.
The quick methods
These are cheap, fast, and unmoderated. You can run one in an afternoon.
Five-second test
Show a design for a few seconds, then take it away and ask what the person remembers. It measures first impression and message clarity, not usability.
Use it for: landing pages, hero sections, value propositions, adverts, packaging. Do not use it for: anything requiring interaction, or anything below the fold. Participants: 15 to 30 for reliable patterns. Time: under an hour to set up.
The classic finding is a page that the team believes explains the product, where not one participant can say what the product does.
Preference test
Show two or more designs and ask which they prefer, and why. The "why" is where the value sits. A bare preference percentage tells you little on its own.
Use it for: settling internal design debates, choosing between visual directions, comparing messaging. Do not use it for: deciding which design is more usable. Preference and performance are different things, and people frequently prefer designs they perform worse with. Participants: 20 to 50.
First-click test
Give a task and record where the person clicks first on a static screen. The first click matters disproportionately because users who start down the wrong path often never recover.
Use it for: navigation labels, homepage layouts, calls to action, dense dashboards. Do not use it for: multi-step flows. Participants: 20 to 50.
The information architecture methods
These answer questions about structure and naming, not visual design.
Card sorting
Give people your content items and let them group them. In an open sort, they name the groups. In a closed sort, you supply the categories.
Use it for: designing a new navigation, restructuring existing content, checking whether your internal vocabulary matches your users'. Do not use it for: validating a structure you have already built. That is what tree testing is for. Participants: 15 to 30.
The output that matters is agreement per item. Items where people agree are well named. Items that scatter across many groups are ambiguous and need renaming or splitting.
Tree testing
The mirror image of card sorting. You have a structure, and you ask people to find something in it, with no visual design present.
Use it for: validating a proposed navigation, diagnosing why people cannot find something, comparing two structures. Do not use it for: generating a structure from scratch. Participants: 30 or more if you want confident numbers.
Watch two figures: success rate, and how many people got there directly without backtracking. A high success rate with lots of wandering means the structure works but the labels are unclear.
> Card sorting builds the structure. Tree testing proves it works. Running only one of them is half the job.
The task-based methods
Here you find out whether people can actually do the thing.
Prototype test
Participants complete a task in an interactive prototype. You see where they go, where they hesitate, and where they give up, before you build anything.
Use it for: validating a flow before development, comparing two interaction models, catching dead ends. Participants: 5 to 8 per user group for qualitative findings.
Unmoderated usability test
The same idea against a live product. Participants do the task in their own time and report how it went.
Use it for: benchmarking an existing flow, testing at a scale interviews cannot reach, checking a fix worked. Do not use it for: exploratory questions where you will want to ask follow-ups.
Moderated usability test or interview
A researcher is present, watching and asking. This is the most expensive method per participant and the only one that answers "why".
Use it for: understanding motivation, exploring an unfamiliar domain, digging into a problem the cheap methods surfaced but could not explain. Participants: 5 to 8 per group.
Spend interviews on the questions that need them. If a fifteen minute unmoderated test could have answered it, an interview is a waste of an hour and a much larger incentive.
The measurement methods
Survey
Good for scale, frequency and attitude across a large group. Bad for anything about behaviour that people cannot accurately self-report, which is most behaviour.
Use it for: sizing a problem, segmenting an audience, tracking satisfaction over time. Do not use it for: finding usability problems, or asking people to predict what they would do.
Diary study
Participants log entries over days or weeks. It captures things a single session cannot: habit, context, change over time, and the moments that happen when no researcher is watching.
Use it for: onboarding over the first week, recurring tasks, understanding a routine. Participants: 8 to 15, and expect some drop-off. Time: as long as the study runs, plus analysis.
Price this one properly. A seven day study is seven commitments, not one.
How many participants, really
Two different logics apply, and confusing them causes most bad research claims.
Qualitative methods such as interviews, prototype tests and moderated sessions surface most significant issues with 5 to 8 participants per distinct group. Adding more finds diminishing new problems.
Quantitative methods such as surveys, preference tests, first-click and tree tests produce numbers, and numbers need sample. Aim for 30 or more before quoting a percentage.
Reporting a percentage from five people is the fastest way to lose a stakeholder's confidence.
A sequence that works
For a new or redesigned product, this order avoids rework:
- Interviews to understand the problem space.
- Card sort to shape the structure.
- Tree test to prove the structure holds.
- Five-second and preference tests on the key pages.
- Prototype test on the main flows.
- Unmoderated usability test after launch to benchmark.
- Survey to size what you found.
- Diary study if the behaviour unfolds over time.
You will not run all eight for every project. Knowing which two you need is the skill.
Running any of these
UsersArabia supports all of these study types in one place, with vetted participants across the Middle East and North Africa. Recruitment is free to start and you pay only for participant incentives.