UX Research Methods

Research used to mean showing a finished screen and asking how it looked. A designer would put three mockups on the wall and ask the person at the next desk which one worked, or have a meeting room vote by show of hands. People almost always say the screens look fine. The person who made them is sitting right there, and nobody in the room has ever tried to get anything done with them.

So the same thing happened after every release. One team redrew the invite screen, shipped it, and found a month later that half the people who started an invite never finished. Nobody had flagged that spot in the mockup review. Everyone in that room already knew the email addresses of the colleagues they would invite. Real users didn't, so they left to go find an address book and never came back.

The gap was between what got asked and what the team wanted to know. The question worth answering was whether a person completes the invite. The question actually asked was whether the screen looked good. Ask about taste and taste comes back. To learn about behavior you have to hand someone a task and watch, and to learn about proportions you have to gather enough people to count.

UX research methods are that set of questions split by purpose. Once you know what you want to learn, the choice of tool is mostly made for you. In the design process these tools show up in two places: the first stage, where the team works out what the problem is, and the fourth, where it tests what it built. The usability test — hand a user a task on a real screen and watch — is by far the best known of them, so much so that people treat it as the whole field. Sitting next to it are a dozen other tools, each answering a different question.

The terms under UX research methods fall into six groups. What separates them is not what the tool looks like but what you pull it out to learn, from watching whether a person can finish something to turning usability into a number you can compare.

One more split runs across all six. Qualitative research captures why people behave the way they do, through what they say and what you see them do. Five participants is usually enough and the output is sentences. Quantitative research measures how much, which takes dozens to hundreds of people and produces rates and scores. The first four groups lean qualitative, the last two quantitative.

First, usability testing. Put the screen in front of someone, give them a task, and watch where they stall.

1. Moderated test — a facilitator sits alongside, hands over the task, and asks what the participant was looking for the moment their hand stops. You get reasons, at the cost of an hour per person and a calendar to coordinate.
2. Unmoderated test — the participant works alone and you get a screen recording and their voice. Ten sessions in a day is realistic, but you can't follow up at the point where they stalled, so the reason stays a guess.
3. Guerrilla test — stop someone in a cafe or an office lobby and finish in five minutes. The people you catch are usually not your users, so it can't settle fine-grained questions. It's a cheap way to catch the problems anyone would hit.

Second, expert evaluation. No participants to recruit, so it's fast and cheap.

1. Heuristic evaluation — three or four people walk the screens against a fixed list of principles and write down every place the design breaks one, usually the ten Nielsen heuristics. Two days is enough with nobody to recruit, but the problems experts find and the places real users stall don't always overlap.
2. Cognitive walkthrough — pick one task, step through the screens one at a time, and ask the same two questions at every step. Would a first-timer know what to click next, and would they notice that the click worked? It earns its keep on flows people pass through knowing nothing, such as the minutes right after signup.

Third, structure research. This runs before any screen is drawn, which ties it to the work of laying out an information architecture.

1. Card sorting — hand people cards with item names and have them make their own groups. Where the team's categories and the users' groupings disagree shows up here.
2. Tree testing — no screens, just the menu labels, and a question like "where would you go to change the company payment card?" It shows whether the names alone are enough to navigate when the layout isn't there to hint at the answer.
3. First click test — show one screen and record nothing but where the first click lands. It rests on the observation that people whose first click is right finish the task far more often than those whose first click is wrong.

Fourth, impression research. Not a judgment formed after long use, but what gets through in the first few seconds.

1. Five second test — show a screen for five seconds, take it away, and ask what stuck. It's the usual way to check whether a landing page conveys what the service actually does.
2. Preference test — put two or three options side by side and ask which is better. Without asking why, it ends as a vote on taste and leaves nothing to act on.

Fifth, behavioral observation. Nobody gets asked anything; you read the traces people leave. It only runs if you already have users.

1. Eye tracking — equipment records where the gaze lands and in what order. The hardware and the analysis time are expensive enough that small companies rarely run it.
2. Session replay — play back what real users did on screen. When several people shake the cursor in the same spot or press the same button three times, that spot is the problem.
3. Heatmap — clicks and scroll depth painted over the layout as color. It tells you where people clicked and not why, so it usually works as the starting point for the next study.

Sixth, quantitative scales. Surveys built to turn usability into one number you can compare across releases or across products.

1. System Usability Scale (SUS) — ten questions producing a score from 0 to 100. A 68 is the widely cited average, which lets you say where your number sits against the outside world.
2. Usability Metric for User Experience (UMUX) — the same idea cut down to four questions, used where a longer survey would lose responses.

The methods differ, but the sequence for running one is much the same.

1. Write down what you want to learn, in one sentence. "Evaluate the invite screen" is not a question. "Does a user who doesn't know the invitee's email address finish the invite?" is.
2. Pick a method that can answer that sentence. Reasons mean meeting people; proportions mean collecting numbers.
3. Recruit participants who match the conditions. This is usually the long pole — finding five admins at 30-person teams on a paid plan takes about two weeks.
4. Write the tasks and questions into a guide and rehearse it once on a colleague. That rehearsal is where leading questions get caught. "This button is easy to find, right?" becomes "find this button," and what comes back is behavior instead of agreement.
5. Run it, write down what you saw, and go through it with the team. What should be left at the end is a list of things to fix, not a report.

Three conditions narrow the choice: whether a screen exists yet, whether people are already using the product, and how much time there is. Before any screen, structure and impression research are what's open. With a screen, usability testing and expert evaluation open up. With live users, behavioral observation and quantitative scales start working. A day buys an expert evaluation or a guerrilla test, a week buys five moderated sessions, and a month is enough to add a quantitative scale on top.

"That's a screen review, not a research question. Let's write down what we want to learn first."

Starting a study without a purpose gets you opinions back instead of findings.

"This week we'll check the menu labels with a tree test and draw screens after that."

Screens drawn on a broken structure get redrawn, so the order should change.

"Three out of five got stuck, but let's not write that up as 60 percent."

Pulling a rate out of a small study creates more confusion than evidence.

At Pagedeck these lines came up often during the quarter spent on converting free teams to paid. When Grace suggested redrawing the checkout screen, Noa wrote down a question instead: what does an admin who starts checkout do between there and having the company card details in hand?

Noa reached for session replay first. Out of twenty replayed sessions that entered checkout and left, twelve sat on the card number field for more than three minutes. That located the stall but not the reason, so the following week she added five moderated sessions. Four of the five said the same thing. They didn't have the card themselves, they had to ask whoever handled finance, and they left the screen alone because closing it felt like starting over.

In the readout with Mia and Theo, the conclusion was not a nicer checkout screen but a flow for naming and inviting a separate billing contact. Finding where with numbers and then hearing why from people, in that order, is what produced the decision.

The most common mistake is reading research as asking users what they want and building it. The phrase "user-centered" travels with the field, so the reading is natural enough. But the solutions people describe are mostly borrowed from products they already use. Ask someone who finds inviting painful what would help and nine out of ten ask for a spreadsheet upload. What they actually need is a way to send an invite without knowing the address, so taking the request literally adds one upload feature nobody uses. Keep transcribing requests that way and six months later the product has twenty more features and the same conversion rate. What research is for is not the solution people asked for but the situation that produced the request.

Applying the rule of five to every method is the other common error. The number is famous enough that it detaches from its context. It holds for qualitative usability testing and nowhere else, and even there it means most major problems surface at least once within five sessions, not that five people represent everyone. Judge whether a usability score improved off five people and the result swings 20 percent every time one participant changes. Left alone, this turns "three of our five participants did this" into "60 percent" in a document, and next quarter's plan gets built on that number.