How to Get Started With the UX Research Process

Studies get run. Decks get shared. Findings get nodded at in a Thursday standup, then quietly outlive their usefulness in a Notion page nobody opens again.

BehavioralNielsen Norman Group has a name for this: recommendation breakage, the gap between a clear finding and a shipped change. Their analysis is blunt about the cost — wasted budget, and researchers burning out from running the same study twice because the first one changed nothing.

Key Takeaways

• The UX research process has two layers people constantly conflate: a four-phase project lifecycle (discovery, exploration, testing, listening) and a six-step loop you run inside a single study.
• Start every study by writing down the decision it will inform. If no decision changes based on the outcome, you're collecting trivia.
• Method choice follows the question, not the calendar. Behavioral questions need observation, attitudinal questions need conversation, scale questions need volume.
• Recruiting is the most common bottleneck, so start it before your discussion guide is finished.
• Five to eight participants surfaces most usability problems in a single flow. Beyond that, you're paying for confirmation.
• 80% of research professionals now use AI in their workflow, mostly for synthesis and prep — not for replacing participants.
• Research that produces no behavioral change in the product is a failed study, regardless of how good the findings were.

What the UX Research Process Is

The UX research process is the repeatable sequence in UI/UX design a team uses to turn an open product question into evidence, and that evidence into a design decision.

It covers framing the question, choosing a method, recruiting participants, running sessions, analyzing what came back, and verifying that something changed as a result.

That last clause matters. A process that ends at "insights delivered" is only half a process.

Everything upstream of it is well documented and largely uncontroversial. The real variance between teams sits in how tightly the loop connects to the roadmap.

UX Research Process by Clay

Two Models, One Process

Two frameworks circulate for this topic. They describe different things, and most articles present them back-to-back as if they're alternatives.

The four phases describe when research happens across a product's life. They're a map of a project.

The six steps describe how you execute one study. They're a loop you re-run every time you have a new question.

You don't choose between them. Your position in the lifecycle tells you what kind of question you're asking, and the six-step loop is how you answer it. A discovery question and a listening question use the same six steps with completely different methods plugged into step two.

The Four Phases: Where Research Sits in a Project

Discovery

You don't yet know what the problem is. The job is to map the territory before anyone sketches a screen. Field studies, stakeholder interviews, user interviews, and diary studies all belong here, with diary studies earning their keep when the behavior unfolds over days rather than minutes.

This is the phase teams skip most often, and the one that costs most when skipped. Building the wrong thing efficiently is still building the wrong thing.

Exploration

The problem is roughly defined. Now you're pressure-testing directions before committing engineering time.

Competitive analysis, persona work, journey mapping, task analysis.

Qualitative depth pays off here, because you need to understand why a behavior happens, not just how often. Concept testing has grown noticeably: up six points year over year to 64% adoption, which tracks with how many teams are bolting AI features onto products and need to know whether anyone wants them.

When we worked with Nuant on their crypto asset intelligence platform, the exploration question wasn't visual. It was how to make dense financial data legible to two very different user types without building two products.

4 Phases of the UX Research Process

Testing

You have something buildable, and you're checking whether people can use it. Usability studies, benchmark testing, first-click testing, tree testing, and accessibility audits live here. Run them before launch, because the cost of a fix rises with how much code depends on it.

Listening

The product is live, and real behavior is available at a scale interviews can never match. Surveys, product analytics, search-log analysis, support-ticket clustering, usability-bug review.

Listening is the cheapest research you'll ever do, because the participants recruited themselves. Most teams under-mine it badly. Your search logs alone will tell you what your information architecture fails to communicate.

Running a Single Study: The Six Steps

1. Write the Decision, Not the Goal

"Understand our users better" is not a research goal. It's a mood.

Write the sentence that describes what changes based on the result.

We will either keep the three-step onboarding or collapse it to one screen. We will either build the bulk-import feature this quarter or push it to next year.

If you can't write that sentence, stop. You're about to spend two weeks producing something nobody has a use for.

This habit prevents more wasted research than any other. It also makes stakeholder buy-in easier, because you're no longer asking for budget to learn things. You're asking for evidence to settle an argument that's already costing the team time.

Then write two to four research questions underneath the decision, specific enough that you'd recognize an answer when you saw one.

2. Pick a Method Your Question Can Answer

Method selection is a matching exercise, and the mismatches are predictable.

To know what people do, observe them. Self-report is unreliable about behavior, and the gap widens the more the behavior reflects on the person.

To know what people think or feel, talk to them. To know how many, you need volume: surveys or analytics.

The most common error is using a qualitative method to answer a quantitative question. Six interviews cannot tell you what percentage of users struggle with checkout. They can tell you why the ones who struggle do. Both are useful. They're not interchangeable.

Our full breakdown of UX research methods covers the selection logic in more depth, including where card sorting, tree testing, and empathy mapping each fit.

User Research Methods by Clay

3. Recruit Before the Guide Is Finished

This is a sequence dependency people learn the hard way.

Recruiting is the reliable bottleneck. Finding enough qualified participants remains the top struggle reported by researchers, and while recruiting timelines have improved slightly year over year, the problem hasn't gone away. Screener out, panel contacted, incentives approved — start all of that while you're still drafting questions.

The guide takes an afternoon. Filling six slots with the right people can take two weeks.

Screen on behavior, not demographics. "Has abandoned an online purchase in the last month" is a useful screener. "Aged 25 to 40" almost never is.

4. Run the Sessions

Record with consent, take structured notes, and resist the urge to explain your design.

The specific discipline that separates useful sessions from useless ones is silence. When a participant hesitates, wait. The pause is data. Most moderators fill it, and in filling it they hand the participant the answer.

Watch for friction: hesitation, backtracking, re-reading, the small physical tells of confusion. Note the timestamp so you can find it again during analysis, and ask about the thing you just saw, not the thing you hoped to see. Six people on a call changes how a participant behaves, so keep observers few and brief them beforehand.

5. Analyze Toward a Recommendation

Raw notes aren't findings, and findings aren't recommendations. You need all three, in that order.

Cluster observations into themes. Weight themes by frequency and severity, because a problem three of six people hit that blocks purchase outranks one five of six people mentioned as mildly annoying. Then convert each theme into something a designer or engineer can act on this sprint.

The failure mode here is the finding that stops short of a recommendation. "Users found the navigation confusing" gives the team nothing. "Users couldn't locate billing because it sits under Account rather than Settings. Move it and re-test" gives them a ticket.

Personas help at this stage if you build them from research rather than imagination. Built from imagination, they're just your assumptions wearing a stock photo.

6. Track Whether Anything Changed

Almost nobody does this step, which is why it's the most valuable one in the list.

After the recommendations go out, log which ones shipped, which got deferred, and which got quietly dropped. Review the log quarterly. Patterns emerge fast: certain teams never act, certain recommendation formats never land, certain research arrives too late in the cycle to be actionable.

Then close the measurement loop on the changes that did ship. Analytics, follow-up usability testing, satisfaction scores. Did the fix work, or did it just move the problem?

From e-commerce redesign to immersive 3D experiences, we know that no two websites should feel the same. Tell us what yours needs to do.

How Many Participants, and When to Stop

For usability testing on a single flow with a single user type, five to eight participants surfaces most problems. Run more and you'll mostly re-confirm what you already know, at full cost per session.

The exceptions matter more than the rule:

• Multiple distinct user types. Five per segment, not five total. A tool used by admins and end users needs both.
• Quantitative claims. A number you can defend needs a sample sized for it, usually a survey with a few hundred responses. Under a hundred, treat results as directional.
• Rare behaviors. Edge cases need targeted recruiting, not bigger samples.

The stopping rule for qualitative work: stop when two consecutive sessions produce nothing new. If session seven and session eight both surprise you, keep going.

Where the Process Breaks

Four failure modes account for most of the damage.

Research nobody asked for. A study commissioned without a decision attached produces findings without a home. Step one prevents this.

Findings that arrive after the decision. Research delivered in week six of a five-week build is theatre. Match timelines to the roadmap, or run smaller studies more often.

Insights that never become tickets. This is breakage, and it's the most common of the four. The fix is procedural: every recommendation gets an owner and a status, and the status gets reviewed.

Stakeholder resistance dressed up as pragmatism. Laura Klein at NN/g cataloged the standard objections — no time, too expensive, people don't know what they want, and the unspoken one, fear that the research will say the thing we built is bad.

UX Research Process

Her observation on the time objection is the useful counter: the teams claiming they lack time to research somehow found time to build the wrong thing first and then pay a consultant to fix it.

When You Shouldn't Run Research

Skipping research is sometimes the right call, and pretending otherwise damages your credibility with the people who control your budget.

Skip it when the answer is already established. Whether your form needs inline validation is not an open question. Consult existing guidance and move on.

Skip it when the cost of being wrong is lower than the cost of finding out. Small, reversible changes are often faster to ship and measure than to study.

Skip it when the decision is already made. If leadership has committed, a study won't change it. You'll produce evidence that gets ignored and spend credibility you need for the next question.

Skip it when you can't act on the answer. No engineering capacity for six months means findings will be stale by the time anyone reads them.

AI in the 2026 Research Process

The adoption numbers are real. Across the 485 researchers surveyed in User Interviews' 2025 report, 80% already use AI somewhere in their workflow, and 54% used it to experiment with methods they hadn't tried before.

Where it holds up: transcription, first-pass thematic clustering, screener drafting, discussion-guide review, synthesis across a pile of past studies, summarising support tickets at volume. All pattern-matching tasks over text you already own.

Where it doesn't: replacing participants. NN/g's work on synthetic users documents the failure mode clearly. AI-generated participants skew sycophantic and idealized. Asked whether they'd finished the online courses they'd started, synthetic users said yes. Real learners admitted they mostly hadn't.

Jeff Sauro's team found ChatGPT unusable as a stand-in for tree testing because it performed far better than actual humans, which makes it worthless as a measure of whether actual humans can navigate anything.

A subtler argument is worth sitting with. NN/g makes the case that even if AI matched a researcher's output quality, the team learning that comes from watching real users can't be outsourced. The deck isn't the product of research. The changed mind is.

Use synthetic users for hypothesis generation and desk research. Not for decisions.

Adapting the Process to Your Team

The six steps hold at any scale. What changes is how much ceremony each one gets.

Solo designer, no dedicated researcher. Compress hard. One decision, one method, five participants, findings in a page rather than a deck. Run it fortnightly rather than quarterly. Democratised research is now the norm rather than the exception — 71% of organizations report having people who do research outside a formal research role.

Embedded researcher on a product team. Your risk is the roadmap outrunning you. Keep a standing recruiting panel, so step three doesn't restart from zero, and pre-negotiate which decisions get research and which don't.

Dedicated research team with ops support. Your risk is breakage, not capacity. You'll produce more findings than the organization absorbs. Instrument step six seriously and use the log to argue for earlier involvement.

Agency work sits in a fourth category, where research compresses into a fixed engagement window. Narrow questions are what make it fit.

On Serena & Lily, the question was where in the browsing journey inspiration turned into intent, which was answerable inside the timeline and load-bearing enough to reshape the cart and checkout flow.

On Cornerstone, fifty-plus pages meant sequencing research by page priority rather than studying everything at once.

On Lulo Bank, a first-of-its-kind digital bank in Colombia, the question was trust: what a bank with no branches has to do onscreen to feel real.

From Google's wearable experience to Snapchat’s AR try-on lenses, we've helped teams across every industry design products people actually want to use. Let's talk about yours.

Read more

• What Is UI? Understanding the Basics of User Interface Design
• How to Hire a UI/UX Design Agency: 10 Tips for 2026
• How Much Does It Cost to Redesign a Website?

FAQ

How is the UX research process different from the design process?

The design process produces solutions. The research process produces evidence about problems and about whether solutions work. They interleave rather than run in sequence: you research, design, test the design, research again. Product design without research is guesswork with good typography.

How long does one research cycle take?

An unmoderated usability test can run in two to three days. Five moderated interviews take one to two weeks end to end, with recruiting consuming most of it. A diary study runs two to four weeks by design. Generative discovery on a new product area can take a month or more.

What's the minimum viable version of this process?

One written decision, one method, five participants, one page of recommendations with owners attached. That's a legitimate study. Everything beyond it is refinement.

How do I get budget for research when leadership isn't convinced?

Attach it to a decision that's currently stuck. Research funded as "understanding users" competes with feature work and loses. Research funded as "settling the onboarding argument that's cost us three sprints" reads as unblocking.

Can UX research be done entirely remotely?

Yes, and most of it now is. Moderated interviews, unmoderated usability tests, surveys, card sorting, and tree testing all work remotely, often with better geographic reach. The loss is contextual: you can't see the second monitor, the paper notes, the interruptions, or the environment shaping the behavior. For contextual questions, field studies still beat calls.

How do I choose between qualitative and quantitative methods?

Ask whether your decision needs a reason or a number. Reasons come from small-sample qualitative work. Numbers come from large-sample quantitative work. Most solid research plans use both in sequence: qualitative to find the problem, quantitative to size it.

Should product managers and engineers attend sessions?

Yes, with limits. Two observers maximum per session, briefed not to interject, and debriefed immediately after. Attendance is the single strongest driver of whether findings get acted on, because a stakeholder who watched a user fail doesn't need convincing later.

What do I do when research contradicts what a stakeholder wants?

Lead with the observation rather than the conclusion. "Four of six participants couldn't complete signup without help" is harder to dismiss than "the signup flow is bad." Then offer options rather than a verdict, so the decision stays theirs.

How does UX research differ from market research?

Market research asks whether people will buy and at what price. UX research asks whether people can use it and whether it solves their problem. Same customer, different question. A product can test well commercially and still be unusable.

Is heuristic evaluation a substitute for user testing?

No, but it's a useful filter. Running an expert review first catches the obvious problems cheaply, so your participant sessions aren't spent rediscovering that the contrast fails and the labels are ambiguous. Use it to clear the ground, not to replace the sessions.

How often should we run research after launch?

Continuously, at low intensity. A standing loop — analytics review monthly, a handful of sessions each quarter, survey twice a year — beats a large study annually. Behavior drifts, competitors change expectations, and a once-a-year snapshot tells you where you were, not where you are.

Who owns the UX research process?

Whoever owns the decision. Researchers run the method; product owns whether the finding changes anything. When ownership of step six is ambiguous, breakage follows.

Conclusion

The six steps aren't hard. Most teams can describe them without looking anything up.

The difficulty is downstream. Research earns its budget when a finding changes a build decision, and loses it when findings accumulate without consequence. So the measure of your process isn't how many studies you ran or how rigorous your method selection was. It's how many things you built differently because of what you found.

Track that number. It's the only one that argues for you.