User Research Methods
"Tell me about a time you did user research" is one of the most reliably discriminating questions in a UI/UX interview, because there are only two kinds of answers to it. The weak answer names a single method — "I ran interviews" — as if research were one activity you either did or didn't do. The strong answer names why that method, for that question, given those constraints, and can explain what it would have done differently with more time, less access to users, or a different stage of the project. Interviewers ask this question specifically to find out whether you understand that "user research" is a toolbox, not a tool.
This matters more in UI/UX interviews than the phrase "user research" might suggest, because the single most common design failure isn't bad visual taste — it's building the right-looking solution to the wrong problem, or validating a design with the wrong kind of evidence (a survey where you needed a usability test, or five opinions where you needed five hundred data points). A candidate who can map a business question to the correct method, defend a sample size, and name the bias that would undermine a given study is demonstrating judgment that generalizes to any project, which is exactly what "walk me through your process" questions are trying to surface.
This subject builds directly on ux-vs-ui-and-the-design-process — the Double Diamond's Discover phase is where most of this toolkit lives — and sets up the next two subjects in the track: personas-journey-maps-and-jtbd, which is what you build from synthesized research, and information-architecture-and-navigation, which goes deeper on card sorting and tree testing than this subject does.
The NN/g Framework: Qualitative vs Quantitative, Attitudinal vs Behavioral
Nielsen Norman Group's research-methods framework places every method on a 2x2 grid defined by two independent axes, and it's the single most useful mental model for answering "what research method would you use" questions, because it forces you to answer two questions at once instead of one.
Axis 1 — Qualitative vs Quantitative: what kind of data does the method produce?
- Qualitative methods produce rich, open-ended data from a small number of people — the "why" behind a behavior. You can't average it into a percentage; you synthesize it into themes.
- Quantitative methods produce numeric data from a large enough sample to be statistically meaningful — the "how many" or "how much." You can't ask it "why," only observe the pattern.
Axis 2 — Attitudinal vs Behavioral: what is the method actually measuring?
- Attitudinal methods measure what people say — their stated opinions, preferences, and recollections.
- Behavioral methods measure what people do — their actual actions, unmediated by self-report.
ATTITUDINAL BEHAVIORAL
(what people SAY) (what people DO)
┌───────────────────────┬───────────────────────────┐
QUALITATIVE │ Interviews │ Contextual inquiry │
│ Focus groups │ Usability testing │
│ Diary studies (recall)│ Diary studies (in-moment) │
├───────────────────────┼───────────────────────────┤
QUANTITATIVE│ Surveys │ Analytics / clickstream │
│ Preference tests │ A/B testing │
│ │ Tree testing │
└───────────────────────┴───────────────────────────┘
Why attitudinal and behavioral diverge — the classic interview point. People are unreliable narrators of their own behavior, not out of dishonesty but because self-report runs through memory, self-image, and social framing, none of which match what actually happened in the moment. The textbook case: users say in a survey that they'd pay for a premium feature, then a paywall A/B test shows near-zero conversion — attitudinal data said yes, behavioral data said no, and the behavioral data is the one that predicts revenue. This isn't a reason to discard attitudinal research; a survey still tells you why people hesitated in ways a conversion number never will. It's a reason to never treat stated preference as a substitute for observed behavior when they could plausibly diverge — and a strong interview answer names this explicitly rather than treating "we asked users and they liked it" as sufficient validation.
Generative vs Evaluative Research
A second, independent axis cuts across the grid above: what stage of the process is the research serving?
- Generative research (also called exploratory or foundational research) happens when the problem space is still open — you don't yet know what to build, or even exactly what the problem is. The question it answers is "what should we build?" It maps onto the Double Diamond's Discover phase from
ux-vs-ui-and-the-design-process. - Evaluative research happens once a specific design exists — a concept sketch, a prototype, or a shipped feature — and the question is "does this work?" It maps onto Deliver, and to a lesser extent the tail end of Develop once concepts are concrete enough to put in front of users.
Most named methods can run in either mode — an interview can be generative ("tell me how you currently manage your invoices") or evaluative ("walk through this prototype and tell me what you expect each button to do") — so "which method" is never a complete interview answer on its own; "which method, run generatively or evaluatively, at which stage" is. Confusing the two is a specific version of the Double Diamond mistake covered in the prior subject: running a generative interview but treating its output as if it validated a specific solution, or running a usability test on a prototype and treating its findings as if they'd uncovered the whole problem space rather than just this one design's flaws.
The Core Method Toolkit
Each method below answers a specific question and has a specific way it fails when misapplied.
Semi-structured interviews — a prepared set of open-ended questions with room to follow up on what the participant actually says, rather than a rigid script. Answers "how does this person think about the task, in their own words?" Qualitative, primarily attitudinal (people are describing, not being observed). Failure mode: participants describe an idealized or simplified version of their process, especially for habitual behavior they don't consciously think about — you get the story they tell themselves, not necessarily the actual sequence of actions.
Contextual inquiry — observing and interviewing someone while they perform the task in their real environment (their actual desk, their actual tools, their actual interruptions), rather than in an interview room recalling it after the fact. Qualitative, behavioral. This is why it surfaces things a standalone interview misses: the participant doesn't have to accurately remember or articulate their workaround for a broken step in the process — you watch them hit it. A user who says in an interview "I just export the report and email it" may, in context, be exporting it, opening it in three different apps to reformat it, and emailing it from a personal account because the corporate one is blocked — none of which they'd have thought to mention as "the process," because to them it's just what you do. Failure mode: harder to schedule and scale than a remote interview, and the observer's presence can itself change behavior (see the Hawthorne effect below).
Diary studies — participants log behavior, thoughts, or feelings over an extended period (days to weeks), usually in response to prompts or triggered events, rather than in one sitting. Qualitative, mixed attitudinal/behavioral depending on design. The specific use case: infrequent behaviors (something someone does monthly, not daily) or emotionally loaded ones (financial stress, health decisions) that a single interview can't capture because the relevant moment isn't happening in the room and isn't easily reconstructed from memory afterward. Failure mode: high participant drop-off over the study period, and entries closer to the end tend to get thinner as diary fatigue sets in.
Surveys — structured questionnaires distributed to a large sample. Quantitative, attitudinal — you're measuring stated opinion or self-reported behavior at scale, not observing actual behavior. Answers "how common is this opinion/preference across our user base?" Failure mode: response bias (people with strong opinions, usually negative ones, are more likely to respond at all — non-response bias), plus every risk of leading or loaded question wording covered in the bias section below. A survey is the wrong tool for "why" — open text boxes get skimmed answers, not the depth an interview gets.
Card sorting and tree testing — card sorting has participants group and label content to reveal their mental model of a category structure; tree testing gives participants a task and a stripped-down (visuals-free) version of a navigation hierarchy to see if they can find the right place in it. Both are IA-specific evaluative/generative tools — card sorting is generative (what structure makes sense to users), tree testing is evaluative (does this specific structure work). Covered in depth in information-architecture-and-navigation; the interview-relevant point here is knowing which one you'd reach for: card sorting before you've built a navigation structure, tree testing after.
Analytics and behavioral data — clickstream, funnel drop-off, session recordings, feature-usage counts pulled from a live product. Quantitative, behavioral. Answers "what are users actually doing, at scale, right now?" — and it's the most reliable method for detecting that a problem exists (a 40% drop-off at step 3 of checkout is not in dispute). What it cannot tell you is why — analytics shows the "what" without the "why," which is exactly the gap qualitative methods (interviews, contextual inquiry) exist to close. A candidate who treats a funnel chart as a complete diagnosis, rather than a prompt for a qualitative follow-up, is missing half the toolkit.
A/B testing — randomly split traffic between two (or more) variants of a design and measure the difference in a target metric. Quantitative, behavioral, and specifically evaluative — it validates a specific change against a specific metric, it doesn't generate new problem understanding. Requires enough traffic volume to reach statistical significance in a reasonable time window (see the sample-size section below); on a low-traffic product, an A/B test can take months to produce a trustworthy result, which is itself a reason to reach for qualitative evaluative methods (a moderated usability test) instead when volume is thin.
Choosing the Right Method for the Right Question
A decision framework, in the order to actually ask these questions:
- What stage am I in — generative or evaluative? If the problem isn't yet well defined, reach for generative methods (interviews, contextual inquiry, diary studies, analytics-as-a-prompt). If a specific design exists and needs validation, reach for evaluative methods (usability testing, A/B testing, tree testing).
- Do I need attitude or behavior? If the question is about why people do something or how they feel about it, attitudinal methods (interviews, surveys). If the question is about what they actually do, or you need to detect a problem you don't already suspect, behavioral methods (contextual inquiry, analytics, A/B testing).
- What resources do I actually have? Time (a diary study takes weeks; a hallway usability test takes an afternoon), sample size and statistical power (an A/B test needs real traffic volume; a qualitative study doesn't), and access to real users (if you can't get 5-8 target users this week, a method that depends on them isn't available this week regardless of how well-suited it is on paper).
Worked example — "users are abandoning checkout, which method first?" This is a behavioral symptom with an unknown cause, so the first move is quantitative behavioral: pull the funnel analytics to find the exact step where the drop-off concentrates — abandonment "at checkout" broadly could mean the shipping-cost reveal, a required account-creation step, or a payment-form error, and each implies a completely different fix. Once analytics narrows the where, the next move is qualitative — either a handful of moderated usability-test sessions watching real users attempt that specific step (behavioral, evaluative — do they actually get stuck where the data says), or, if the drop happens off-platform (e.g., users leave and don't come back, so you can't observe them completing it), a short survey or exit-intent prompt asking why they left (attitudinal, faster to get a signal, weaker at explaining causation). Going straight to a survey without the analytics step risks asking about the wrong step entirely; going straight to a usability test without the analytics step risks testing a step that isn't actually where users are dropping off.
Sample Sizes: Qualitative vs Quantitative
Nielsen's "5 users find ~85% of usability problems" rule applies specifically to qualitative, moderated usability testing — not to research broadly. The underlying math: as you add users to a usability study, each new participant is increasingly likely to hit a problem the previous participants already surfaced, so the marginal new problems found per additional user drops sharply. Nielsen's curve, based on modeling problem-discovery as a probability function (roughly, each user has about a 31% chance of hitting any given usability problem), shows the first user finding about a third of the problems, and by the fifth user you've typically surfaced around 85% of what exists — while user 10 or 15 mostly reconfirms problems 1-5 already found, at real cost in recruiting and moderation time. The practical conclusion isn't "5 is a magic number," it's "run small qualitative rounds and iterate between them" — test 5, fix what you found, test 5 more on the revised design, rather than one expensive 15-person round.
This rule does not transfer to quantitative research. A survey or an A/B test isn't trying to find problems that exist or don't (a binary you can converge on with a handful of people) — it's trying to measure the size of an effect precisely enough to trust the number, which requires statistical power. Required sample size there is driven by the baseline conversion rate, the minimum effect size you care about detecting, and your tolerance for false positives/negatives — smaller expected effects and lower baseline rates both push the required sample up, often into the thousands for a typical web conversion test. Running an A/B test with 5 users produces a number with no statistical meaning at all; running a usability study with 500 users to "find every problem" wastes budget on marginal returns the 5-8 user round had already mostly captured.
Why 5 is right for one and wrong for the other, stated plainly: qualitative usability testing is asking a discovery question ("does this problem exist"), which has fast diminishing returns per participant. Quantitative testing is asking a measurement question ("how big is this effect, reliably"), where the required precision — not diminishing returns on discovery — sets the floor, and that floor is set by statistics, not by how many distinct problems a handful of people can surface.
Bias and Research Pitfalls
- Leading questions. A leading question embeds the answer you expect into the phrasing. Weak: "Don't you find this checkout flow confusing?" — primes the participant toward "yes" regardless of their actual experience, and most people are socially inclined to agree with a question's framing. Strong: "Walk me through what you expected to happen when you clicked that button" — neutral, open, and lets the participant's own words reveal confusion (or lack of it) without suggesting it.
- Confirmation bias in synthesis. Researchers who go into synthesis already believing a hypothesis ("users struggle with onboarding") tend to notice and weight quotes that confirm it, and unconsciously discount contradicting data as noise or outliers. The mitigation is process, not willpower: synthesize with a second person who wasn't in the room forming the same running narrative, and explicitly look for disconfirming evidence before writing the readout, not just corroborating evidence.
- Recruiting bias. Testing only with existing power users over-represents people who've already adapted to the product's quirks and under-represents the friction a new user would hit — a redesign validated only against power users can ship changes that actively hurt first-time comprehension. Testing only with friends, colleagues, or people recruited from inside the company compounds this with social-desirability pressure (see below) and demographic mismatch against the real user base.
- The Hawthorne effect. People behave differently simply because they know they're being observed — more careful, more deliberate, sometimes performing competence they wouldn't show unsupervised. This is a specific risk for contextual inquiry and moderated usability testing, less so for analytics (which is passive and unannounced). Mitigation: frame the session as testing the product, not the participant ("we're testing whether the design works, not whether you can use it"), and lean on behavioral/passive data (analytics, unmoderated remote testing) when the Hawthorne effect specifically would distort the finding you need.
- Social desirability bias. In interviews, participants tend to give answers that make them look competent, reasonable, or aligned with what they think the researcher wants to hear, rather than their actual unfiltered view — especially on sensitive topics (money, health, admitting they didn't understand something). Mitigation: normalize the "wrong" answer explicitly ("most people find this part confusing — where did you get stuck?") and ask about specific past instances ("tell me about the last time you did X") rather than general self-assessment ("are you good at X"), since specific recall is harder to flatter than a general claim.
From Notes to Insight: Synthesis via Affinity Mapping
Raw research output — interview transcripts, session recordings, survey free-text — isn't actionable on its own; it becomes actionable through synthesis. Affinity mapping (thematic clustering) is the standard technique: write individual observations, quotes, and pain points on separate notes (physical or digital), then group them bottom-up into clusters based on what they actually have in common, rather than sorting them into categories decided in advance. Patterns that emerge from the clustering — not from a pre-existing hypothesis — are the themes that become findings.
The reason this step matters in an interview, not just in practice: a candidate who describes running the research but not how the raw notes became a decision has described data collection, not research. "We found in synthesis that three separate complaints — slow load time, an unclear progress indicator, and users abandoning mid-upload — all clustered around one root cause, a missing sense of system status during a long operation" is a synthesis story with a decision attached. That clustered, prioritized output is exactly the input the next subject in this track, personas-journey-maps-and-jtbd, builds from — personas and journey maps are themselves just structured, reusable artifacts of research synthesis, not a separate research activity.