UX/UI Design, A to Z ┃ 1.6 User Research (Part 2): Why the Decision Comes Before the Method

Good to see you again. How are you today?

When people hear "user research," they often picture a single study you run once, right before design begins. In real projects, it rarely works that way.

Research runs through the whole life of a product — from early planning, to testing prototypes, to improving things after launch. Sometimes what you learn sends you back to redefine the problem, or to fix a prototype and test the same task all over again. So research almost never moves in a straight line.

In this guide, we'll look at user research as three flows, based on what you're trying to do:

• Exploratory research — to understand the problem and the people
• Evaluative research — to check whether your design actually works
• Continuous research — to keep improving the experience after launch

And we'll keep circling back to one question that ties everything together:

"What decision does our team need to make right now, and what evidence do we need to make it?"

Flow 1 — Exploratory Research: Understand the Problem

Exploratory research is about understanding your users — their situation, goals, behavior, and struggles — before you start designing a solution. You'll also hear it called discovery research.

The goal here isn't to decide features. It's to answer questions like:

• In what situation do people run into this problem?
• What are they actually trying to accomplish?
• How do they solve it today?
• What's frustrating or limiting about that?
• What have we been assuming is true, without ever checking?

Here's the single most important mindset: don't take a user's request and turn it straight into a feature.

Say a user tells you, "Please add more search filters." Take it at face value, and you'll pile on filters. But the real problem might not be the number of filters at all — it might be that people don't have enough information to tell products apart. Add a hundred filters, and the problem is still there.

So the question a UX designer should really ask is: What were they trying to achieve, and what in the current experience is getting in the way?

For this kind of work, you'll use methods like in-depth interviews, field studies, contextual inquiry, diary studies, and surveys. In-depth interviews are especially good at uncovering people's real situations and unmet needs. (We'll dig into each method later.)

Flow 2 — Evaluative Research: Does It Actually Work?

Once you've designed something, evaluative research checks whether it actually helps people reach their goals. The star method here is usability testing — watching real users try to complete a specific task.

In a usability test, you give target users a wireframe, prototype, or the real product, ask them to do a task, and watch what happens. You're looking for moments like:

• Where they don't know what to do next
• Where they click the wrong menu or button
• Where a decision takes way too long
• Where they bounce back and forth between the same screens
• Where they hit an error or give up

In moderated tests (ones with a facilitator present), you might ask people to think aloud — to narrate what they're doing — so you can see what they notice, how they interpret it, and what they decide.

One thing worth burning into memory: usability testing is not about asking "Do you like this design?" What matters is watching whether people can actually get the task done. (The UK government's digital service guidance describes it the same way — observing people perform real tasks to spot problems with comprehension, task completion, wording, and layout.)

What should you record? Things like task success, time on task, number of errors, unnecessary steps, requests for help, and how often and how badly problems show up. But you don't need to capture everything. Early on, the qualitative "why are they stuck?" observation matters most; once the design is more concrete, you can add quantitative measures like success rate and time.

Flow 3 — Continuous Research: Keep Improving After Launch

Launching isn't the finish line for research. Real-world use surfaces problems your prototype never showed, and people's needs — and the market — keep shifting.

So after launch, you keep an eye on things like usage data and drop-off points, search terms and behavior patterns, support tickets, app store and service reviews, satisfaction surveys, usability tests for new features, and accessibility experiences.

The point isn't to collect as much data as possible. It's to find the most important user problem right now and decide what to fix first.

In practice, this loop repeats:

Research → Define the problem → Ideas & design → Prototype → Test → Build → Launch → Check the data → Improve → (research again)

A common trap: don't try to fix everything at once. Weigh severity, how often it happens, how many users it affects, business impact, and how hard it is to build — then set priorities.

And here's a rule worth remembering: the more expensive an assumption is to build, or the more it touches your product's structure, the earlier you should validate it — ideally in an early prototype. Change a core flow after it's already built, and you're not just moving pixels; you're shaking up data structures, engineering, and operations too.

Where Does the Data Come From? Primary vs. Secondary Research

Talking to users directly isn't the only kind of research. Analyzing information that already exists counts too. Research splits into two broad types.

Primary research

Primary research is when you collect the data yourself, for a specific purpose. This includes in-depth interviews, contextual inquiry and field observation, usability testing, surveys, diary studies, and focus groups. It gives you data tied directly to your users and your problem.

Secondary research

Secondary research means gathering and analyzing information that already exists — often called desk research. Think industry reports and market data, public statistics and academic papers, competitors' features and flows, past research, support tickets and reviews, usage logs, and relevant laws or accessibility standards. It's great for quickly getting the lay of the land and building the background you need to design a proper study.

Worth noting:

User research doesn't always mean primary research. Digging through existing support tickets, usage logs, or past studies is real user research too.

A Word of Caution About Competitor Analysis

Just because a competitor has a feature doesn't mean your users need it. Copy it blindly, and you copy their assumptions and problems along with it.

What competitor analysis is actually good for: seeing which interactions people already find familiar, what the industry treats as basic and expected, what problems competitors are trying to solve, what pain shows up over and over, and — most importantly — where you have a chance to solve things differently.

The key idea: competitor analysis doesn't replace user needs. It gives you hypotheses to test. If easy returns are the norm in a market, users may expect the same convenience from you. But you can't confirm that just by looking at competitors — you still verify it with your actual target users through interviews, surveys, or usability tests.

How to Choose a Method

Good user research isn't about using lots of methods. It's about picking the one that best fits the decision you need to make and the question you're asking. Here's a quick cheat sheet matching situations to methods:

• Want to deeply understand people's experiences and motivations? → In-depth interviews
• Want to see real environments and actual behavior (not just what people say)? → Field studies / contextual inquiry
• Want to know the distribution and patterns of opinions or behavior? → Surveys
• Want to explore a group's perceptions and shared language? → Focus groups
• Want to see how an experience changes over time? → Diary studies
• Want to validate a design's usability? → Usability testing
• Want to quickly grasp the market and existing material? → Desk research

Now let's look at each method.

A Closer Look at the Main Methods

1. In-Depth Interviews

A one-on-one (usually) conversation that explores a person's experiences, motivations, attitudes, and problems. Sometimes you'll interview two or more people together — like a family or work team who share a service.

A good moderator doesn't just read prepared questions in order. They catch clues in the answers and follow up. Something like: "Tell me about the last time you used this service → What did you do first? → Why did you do it that way? → What was the hardest moment? → Did you try any other way to solve it?"

Watch out: what people say doesn't always match what they do. Questions about future behavior ("Would you use this feature?") are especially unreliable. Ask about recent, real experiences and actions instead.

2. Focus Groups

A small group discusses a topic together. Good for exploring a range of perceptions and attitudes, the shared language a group uses, and first reactions to a new concept. People react to each other's stories, and topics surface that wouldn't come up in a solo interview.

Watch out: one person can dominate, or people just go along with the group — that's groupthink. It's also hard to dig into sensitive experiences. And it's a poor fit for testing usability: debating a screen together is nothing like each person doing a task alone. For interaction problems, run individual usability tests.

3. Surveys

Standardized questions that collect data from many users. Strong for spotting traits and behavior patterns, gauging satisfaction, checking a hypothesis from interviews, comparing groups, and estimating what share of users hit a certain problem.

Watch out: more responses don't automatically mean more reliable. Quality depends on whether your sample represents your target users, whether questions are neutral and clear, and whether everyone reads them the same way. There's no magic "30 people = quantitative research" rule; the number you need depends on population size, your goal, how many groups you're comparing, and your margin of error. And surveys are strong on "what and how much" but weak on "why." Found a pattern? Follow up with interviews to understand the cause.

4. Field Studies & Contextual Inquiry

You visit users' actual lives or workplaces to observe their behavior and environment. Contextual inquiry adds interviewing to that — watching someone do a real task and asking "why did you do that?" at the right moments. It's a more structured approach.

This is where you catch physical constraints, real work sequences and collaboration, the tools and documents people use alongside your product, the gap between official process and actual behavior, unconscious workarounds, and problems people never mention in interviews.

For example, if you're designing hospital wayfinding and only test the map screen, you'll miss the real experience of getting around. People using wheelchairs or strollers are affected by elevator locations, ramps, thresholds, corridor width, and sign height. Walk alongside them and observe, and you'll discover concrete design criteria — like when guidance is needed, how far ahead to give a turn instruction, and where a sign is visible from the user's line of sight.

5. Diary Studies

Participants record their own behavior and experiences over days or weeks — time and place, their goal in the moment, features they used, problems and how they handled them, feelings, and photos or screenshots. Great for behaviors that repeat over time: health, money habits, learning, shopping, commuting.

Watch out: the longer it runs, the more people forget to log or start writing less. Keep prompts short and clear, and use check-ins and a closing interview to fill in the meaning.

The Methods at a Glance

How many people do you need?

For qualitative research (interviews, usability tests), it's more effective to recruit a small, well-targeted group and repeat, rather than gather a huge number at once. The UK government's (GOV.UK) research guidance suggests around 4–8 people per round as a rule of thumb.

Need more evidence? Rather than cramming more people into one round, apply what you learned and run a new round. It's not an absolute formula, though — if you're covering different user types, accessibility needs, or usage contexts, adjust your recruiting so each key group is well represented.

What Really Matters in a Portfolio

If you're job-hunting in UX, this mindset matters a lot. "I ran interviews and usability tests" isn't enough on its own. What hiring managers want to see isn't the number of methods — it's what decisions your research drove.

A strong portfolio shows the whole thread:

What problem and uncertainty did the team face? → Why did you choose that method? → Who did you recruit, and by what criteria? → What questions or tasks did you use? → What behaviors and patterns did you find? → How did you interpret them into insights? → How did the design or priorities change? → How did you re-validate the change?

For instance, this beats "interviewed 5 users" by a mile:

At first, we assumed people dropped off because there weren't enough payment options. But interviews and usability tests revealed the real problem wasn't the number of options — it was uncertainty about unexpected extra costs and delivery timing. So we restructured the checkout screen to clearly show the total cost and estimated arrival date before payment.

That ties together hypothesis → method → finding → interpretation → design decision. Great UX work doesn't just show finished screens — it shows how evidence led to decisions.

Key Takeaways

• User research isn't a one-time step before design. It's a repeating activity across the whole product journey: explore → validate → keep improving.
• Don't turn a user's request straight into a feature — find the real problem behind it. ("Add more filters" isn't the same as "there aren't enough filters.")
• Usability testing isn't about whether people like a design — it's about whether they can actually complete the task.
• Competitor analysis doesn't replace user needs. It gives you hypotheses to test.
• Choose a method by whether it gives the most trustworthy answer to your question — not by what's familiar or easy.
• For qualitative research, 4–8 people per round, repeated beats piling everyone into one big round.
• The more expensive or structural an assumption, the earlier you should validate it — ideally in a prototype.
• It all starts with one question: "What decision do we need to make, and what evidence do we need?"

What's Next

This whole guide came down to one question: "What decision do we need to make, and what evidence do we need?" Next, we'll turn that question into something you can share and act on.

In Writing Research Objectives, you'll learn:

• Why research objectives matter — how they keep a UX project focused, and what goes wrong without them.
• How to write one, step by step — a simple procedure for turning a vague idea into a clear Research Objective Statement.

If this helped, stick around — follow the blog for the next one, and send it to a friend who's just starting out.

Thank you! 🙌

* Image credits: All images sourced from Unsplash.