UX research methods

UX research is how you replace guessing with knowing — how you find out what users actually need, do, and struggle with, before you spend weeks building the wrong thing. It's the foundation of the entire discipline: good design starts with understanding people. This lesson maps the main research methods and, crucially, when to use each.

The two big divides: what people say vs do, and numbers vs reasons

Every research method sits along two axes, and knowing them tells you which method answers your question:

AXIS 1 — ATTITUDINAL (what people SAY) vs BEHAVIOURAL (what they DO)
   People are unreliable narrators of their own behaviour. What they SAY in
   an interview and what they DO in reality often differ. Use attitudinal
   methods for opinions/motivations; behavioural methods for truth about
   actions. When they conflict, trust BEHAVIOUR.

AXIS 2 — QUALITATIVE (WHY / how) vs QUANTITATIVE (HOW MANY / how much)
   QUALITATIVE — small numbers, deep insight into REASONS/motivations
     (interviews, usability tests). Answers "why?" Not statistically valid,
     but rich.
   QUANTITATIVE — large numbers, measurable patterns (surveys, analytics,
     A/B tests). Answers "how many / how much?" Statistically meaningful,
     but doesn't explain WHY.

The best insight often comes from COMBINING: quant tells you WHAT is
happening + how much; qual tells you WHY.

The single most important research truth: what people say and what they do are different things. Users will tell you they'd use a feature, then never touch it. So you watch behaviour for the truth and ask questions for the motivations behind it — and you combine quantitative (what/how many) with qualitative (why) to get the full picture.

The core methods and when to use them

THE RESEARCH TOOLKIT (matched to the question)

- INTERVIEWS (qual, attitudinal) — deep 1:1 conversations. For understanding
  users' goals, needs, context, frustrations. Best EARLY, to explore.

- SURVEYS (quant, attitudinal) — questions at scale. For measuring opinions/
  preferences across many people. Good for validating patterns.

- USABILITY TESTING (qual, behavioural) — watch users attempt real tasks on
  your design. THE method for finding what's confusing/broken. Do it often.

- ANALYTICS (quant, behavioural) — data on what users actually do in a live
  product (where they click, drop off, convert). The truth about behaviour
  at scale.

- FIELD STUDIES / CONTEXTUAL INQUIRY (qual, behavioural) — observe users in
  their real environment. Rich context.

- A/B TESTING (quant, behavioural) — compare two versions live to see which
  performs better. For optimising decisions with real data.

- CARD SORTING / TREE TESTING — for information architecture (later lesson).

MATCH THE METHOD TO THE QUESTION + THE STAGE:
  Explore needs -> interviews/field studies.
  Validate at scale -> surveys/analytics.
  Find usability problems -> usability testing.
  Optimise a choice -> A/B testing.

You don't use all methods every time. You pick the one that answers your specific question at your stage: exploring needs early (interviews), finding what's broken (usability testing), or optimising live (A/B tests). Matching method to question is the core research skill.

The mistake beginners make

The foundational mistake is skipping research and building on assumptions — designing what you think users want, based on your own preferences, and discovering too late that real users needed something else. Research is cheaper than building the wrong thing. Even a little research (five user interviews, one usability test) prevents enormous waste. The second mistake is trusting what users say over what they do — asking "would you use this?" (they'll politely say yes) instead of observing actual behaviour. Watch what people do; treat stated intentions with healthy scepticism. The third mistake is using the wrong method for the question — running a survey to understand why users struggle (surveys don't explain why), or interviewing five people to get statistically valid numbers (too few). Pick the method that actually answers what you're asking.

Your turn

---

Your turn

1. Pick a product or feature you're designing (or a real app you use). Write down THREE things you currently ASSUME about its users — then mark each as 'verified by evidence' or 'just a guess'. Notice how many are guesses.
2. For one key question about your users, choose the right method: is it 'what do they need / why do they struggle' (interviews/usability testing) or 'how many / which option wins' (surveys/analytics/A-B)? Match method to question.
3. Place four methods (interviews, surveys, usability testing, analytics) on the two axes: attitudinal vs behavioural, and qualitative vs quantitative. This map tells you what each is good for.
4. Plan the smallest useful research you could do this week (e.g. 5 user interviews, or one usability test with 5 people) to replace one of your assumptions with evidence.

Key points

• UX research replaces guessing with knowing — understanding what users actually need, do, and struggle with before building; good design starts with understanding people.
• Two axes place every method: attitudinal (what people SAY) vs behavioural (what they DO), and qualitative (WHY, deep, small N) vs quantitative (HOW MANY, measurable, large N).
• What people SAY and DO differ — trust behaviour for the truth, ask questions for the motivations, and combine quant (what/how many) with qual (why) for the full picture.
• Match method to question and stage: interviews/field studies to explore needs, surveys/analytics to validate at scale, usability testing to find what's broken, A/B testing to optimise.
• Avoid building on assumptions (research is cheaper than building the wrong thing), trusting 'would you use this?' over observed behaviour, and using the wrong method for the question.