UX Research Methods: A Practical Guide for Designers

UX research isn't a nice-to-have. It's the mechanism by which you find out whether you're solving the right problem, for the right people, in a way that actually works. Skip it and you're 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 UX research methods you'll 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're new to the field and want a foundation first, what's UX design covers the discipline from the ground up.

Thinking of making research your specialism? Beginner UX (AI) Design runs the design process on a real client brief, with live tutor feedback. Or book a free 15-minute call with an advisor first.

Qualitative vs Quantitative Research

Before looking at individual methods, it's 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 can't 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's quantitative: you know there's a problem and where it is. A round of usability testing or user interviews tells you what's 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're trying to do, what currently frustrates them. You aren't evaluating anything yet; you're 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're 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's 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're 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 can't observe directly and that users won't 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're 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 aren't asking them to evaluate the design; you're 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 at the Nielsen Norman Group (2000) established that five participants will surface roughly 85% of usability problems in an interface. This doesn't 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's 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're 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're 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 isn't.

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'll 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're 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's no visual design involved, you're 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're 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 hasn't solved.

When to use it: When the context of use is an important variable. If you're 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 won't 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's 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 can't 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 can't 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's 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're trying to move and enough users to reach statistical significance. Common applications include landing page headlines, checkout flows, and email subject lines.

What it can't do: A/B testing tells you which variant performs better on the metric you're measuring. It doesn't tell you why. And it can't help you if you're building the wrong thing in the first place -- it optimises within a defined problem space, it doesn't define the problem space. That's 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 won't tell you that the page shouldn't 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 doesn't 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's particularly useful early in a project to identify obvious problems quickly.

What it can't replace: Real users. Heuristic evaluation is efficient but it isn't a substitute for observation. Experts miss things that naive users surface immediately, and experts won't 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's 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 isn't a linear process.

A practical heuristic: if you don't know what question to ask, start with user interviews. They're the most forgiving method and they'll almost always surface something you didn't 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 can't 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's 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 on a real client brief, the Beginner UX (AI) Design and UX Career Track courses at UX Academy work with real companies. The Advanced Agentic (UX) Design course is for designers with 2+ years of experience who design AI agents and assistants.