UX Research Methods: A Practical Guide for Designers

UX research is not a nice-to-have. It is the mechanism by which you find out whether you are solving the right problem, for the right people, in a way that actually works. Skip it and you are designing in the dark -- making decisions based on assumption rather than evidence.

But research is also a toolbox, not a single method. Choosing the wrong tool for a question wastes time and produces misleading results. This guide covers the methods you will use most often in real design work, when to reach for each one, and how to think about fitting research into the broader design process.

If you are new to the field and want a foundation first, what is UX design covers the discipline from the ground up.

Qualitative vs Quantitative Research

Before looking at individual methods, it is worth being clear on this distinction, because it determines how you interpret everything you collect.

Qualitative research involves observing or talking with a relatively small number of participants -- usually fewer than twenty -- to understand their motivations, mental models, goals, and frustrations. It tells you why something is happening. The output is themes, patterns, and insight, not percentages.

Quantitative research collects data at scale. Surveys, analytics, A/B tests, and clickstream data all fall here. They tell you how many users do something, how often, and with what frequency. You can be statistically confident in the results. What you cannot learn from quantitative data alone is why those numbers look the way they do.

The distinction matters because they answer different questions. If your analytics show that 60% of users abandon a checkout flow at step three, that is quantitative: you know there is a problem and where it is. A round of usability testing or user interviews tells you what is actually going wrong at that step. You need both.

Generative vs Evaluative Research

A second distinction that shapes how you plan a research programme:

Generative research happens early. Its goal is to understand the problem space -- who your users are, what they are trying to do, what currently frustrates them. You are not evaluating anything yet; you are building the foundation that makes good design decisions possible. User interviews, contextual enquiry, and diary studies are generative methods.

Evaluative research tests something you have already made -- a prototype, a concept, a live product. You are asking: does this work? Does it solve the problem? Can users actually use it? Usability testing, tree testing, and A/B testing are evaluative methods.

Getting this wrong is expensive. Running usability tests before you understand the problem space will tell you whether a solution works, but not whether it is the right solution in the first place.

The Key Methods

User Interviews

User interviews are one-to-one conversations with people who represent your target users. They are the most flexible and widely used qualitative method because they can be adapted to almost any research question.

Used well, they surface the motivations, mental models, and contextual factors behind user behaviour -- things you cannot observe directly and that users will not mention if you ask them what they want from a product (because people are generally poor at predicting their own future behaviour).

When to use them: Discovery and problem definition. Use interviews when you are starting a new project, entering an unfamiliar domain, or trying to understand why a known pattern exists.

How many participants: Eight to twelve is typically enough to reach thematic saturation for a reasonably homogeneous user group. If your user population is diverse across significant variables (e.g., different levels of technical literacy, different job roles), you may need segments with five to eight participants each.

What you get: Themes, mental models, vocabulary users actually use, and the contextual factors that shape their behaviour. Not validation of specific solutions.

A common mistake: Asking leading questions or pivoting to solutions mid-interview. Your job is to listen and probe, not to pitch.

Usability Testing

Usability testing means giving real users a set of realistic tasks to complete on a product, prototype, or even a sketch, and observing what happens. You are not asking them to evaluate the design; you are watching how they interact with it. Where do they hesitate? Where do they make errors? Where do they give up?

This is the most direct way to identify usability problems before they become support tickets and lost customers.

Moderated vs unmoderated: Moderated testing means a researcher is present -- in person or by video call -- and can ask follow-up questions, prompt the participant to think aloud, and probe when something interesting happens. Unmoderated testing uses a tool (such as Maze or Useberry) to run sessions remotely without a facilitator. Moderated sessions produce richer insight; unmoderated sessions scale further and are faster to run.

How many participants: Jakob Nielsen's research established that five participants will surface roughly 85% of usability problems in an interface. This does not mean you always stop at five -- if you have distinct user segments, test each one separately. But five is a defensible number for most formative rounds, and it is far better than zero.

When to use it: Any time you have something to test -- wireframes, prototypes, or live products. Usability testing should happen throughout the design process, not just at the end.

Surveys

Surveys let you collect structured data from a large number of people quickly and cheaply. When designed well, they are genuinely useful for measuring attitudes, satisfaction, and the frequency of specific behaviours across a user base.

The critical limitations: surveys tell you what people say they do, not what they actually do. They are poor at uncovering unexpected insights because you can only ask about things you already know to ask about. And badly written surveys -- with leading questions, ambiguous scales, or false assumptions baked into the questions -- produce data that feels reliable but is not.

When to use them: After you have done qualitative work and want to check whether a finding holds at scale. Also useful for ongoing satisfaction measurement (e.g., NPS, CSAT) with existing users.

Best practice: Test your survey on five people before you send it. You will almost always find questions that participants interpret differently from how you intended.

Card Sorting

Card sorting is a method for understanding how users naturally categorise and group information. Participants are given a set of cards -- each representing a piece of content or a feature -- and asked to arrange them in a way that makes sense to them.

Open card sorting: Participants create their own category labels. Use this when you are designing a new information architecture from scratch and want to understand users' mental models.

Closed card sorting: Participants sort cards into categories you have already defined. Use this to validate an existing structure or test whether users can predict where things will live in a proposed navigation.

When to use it: Designing or redesigning navigation, menus, or information architecture. Card sorting is a generative method -- it helps you understand how users think about your content before you build a structure around it.

Tree Testing

Tree testing is the evaluative counterpart to card sorting. You present users with a text-based version of your navigation hierarchy (the "tree") and ask them to find specific items. Because there is no visual design involved, you are testing the structure and labelling of the navigation, not the layout.

When to use it: After you have designed an information architecture (often informed by card sorting) and want to test whether users can actually find what they need within it. Tree testing is particularly useful because it isolates navigation problems from visual design problems -- so you can fix the structure before investing in full visual design.

Tools like Treejack make tree testing straightforward to set up and run remotely.

Contextual Enquiry and Field Research

Contextual enquiry means observing users in their actual environment -- at their desk, in a warehouse, on the factory floor, at a kitchen table -- rather than in a lab or on a video call. You are watching how they work in context: what tools they use alongside your product, what interruptions they deal with, what workarounds they have developed for problems the product has not solved.

When to use it: When the context of use is an important variable. If you are designing software for hospital staff, watching how they use it at a nursing station -- surrounded by noise, interruptions, and competing demands -- will reveal constraints that a controlled interview will not surface.

What you get: Insight into the real environment, genuine workflows (not the idealised version people describe in interviews), and often a better understanding of what users actually need vs. what they say they need.

The trade-off is time and logistics. Contextual enquiry is slower and harder to schedule than remote interviews, but for complex or high-stakes products it is often the research method that produces the most useful findings.

Diary Studies

A diary study asks participants to record their experiences, thoughts, or behaviours over an extended period -- days, weeks, or sometimes months. Entries might be written notes, photos, voice recordings, or responses to prompted questions sent via SMS or an app.

When to use them: When you need to understand behaviour over time rather than in a single session. How do people use a health tracking app across a week? How does someone's experience of onboarding a new SaaS product evolve over a month? These are longitudinal questions that a one-hour interview cannot answer.

The catch: Participant compliance drops over time. People start enthusiastically and trail off. You need to design the prompts carefully, keep the recording burden low, and expect some attrition. For that reason, diary studies work best when you have a clear longitudinal question that genuinely cannot be answered any other way.

A/B Testing

A/B testing (also called split testing) shows different versions of a design to different groups of users and measures which version produces a better outcome -- more conversions, longer session time, fewer support requests. It is a quantitative method and requires sufficient traffic volume to produce statistically reliable results.

When to use it: Optimising a design decision at scale, where you have a specific metric you are trying to move and enough users to reach statistical significance. Common applications include landing page headlines, checkout flows, and email subject lines.

What it cannot do: A/B testing tells you which variant performs better on the metric you are measuring. It does not tell you why. And it cannot help you if you are building the wrong thing in the first place -- it optimises within a defined problem space, it does not define the problem space. That is what qualitative research is for.

A common mistake is running A/B tests before gathering enough qualitative insight. Testing two versions of a confusing page will tell you which version is less confusing. It will not tell you that the page should not exist at all.

Heuristic Evaluation

Heuristic evaluation is an expert review of an interface against a set of established usability principles -- most commonly Jakob Nielsen's 10 usability heuristics. Unlike the other methods listed here, it does not require recruiting participants. An experienced evaluator (or a small group of evaluators) reviews the interface systematically and identifies where it violates known usability principles.

When to use it: When you need fast, low-cost feedback without access to participants, or to complement user testing by preparing a cleaner prototype before running sessions. It is particularly useful early in a project to identify obvious problems quickly.

What it cannot replace: Real users. Heuristic evaluation is efficient but it is not a substitute for observation. Experts miss things that naive users surface immediately, and experts will not find problems that are specific to your user population's domain knowledge or context. For a step-by-step guide to running one, see heuristic evaluation in UX design.

How to Choose the Right Method

The best method for any situation depends on two questions:

What is the research question? Are you trying to understand users' mental models and motivations (qualitative, generative)? Are you trying to test whether a design works (qualitative, evaluative)? Are you trying to measure something at scale (quantitative)? Being precise about the question stops you reaching for a familiar method out of habit.

What stage of the process are you in? Early stages call for generative methods -- interviews, contextual enquiry -- that help you understand the problem. Later stages call for evaluative methods -- usability testing, tree testing, A/B testing -- that test your solutions. The two phases overlap and cycle; this is not a linear process.

A practical heuristic: if you do not know what question to ask, start with user interviews. They are the most forgiving method and they will almost always surface something you did not know to look for.

Research in Agile Teams

Running research inside agile development cycles is its own discipline. The pressure to ship is real, and research that cannot keep pace with the team's decision cycle gets deprioritised. The short answer is that research has to be continuous and scoped tightly to the team's current bets -- not front-loaded into a long discovery phase and not skipped entirely.

UX research in agile development covers the practical approaches in detail, including continuous discovery, dual-track agile, and how to run lean research that is fast enough to be useful without being so thin that it misleads.

Build the Skill by Doing It

Reading about research methods and being able to apply them are different things. The gap between the two closes through practice -- running real sessions, making mistakes, learning to spot when a participant is telling you what they think you want to hear, and knowing when you have enough data to act.

If you want to practise these methods on a real client brief, the Intermediate UX Design and UX Career Track courses at UX Academy include hands-on research modules with real companies. You will run interviews, conduct usability tests, and present findings to stakeholders -- the same work you will be asked to do in a professional UX role.