UX/UI Design, A to Z ┃ 1.5 User Research (Part 1)

Welcome! How are you today?

Good user research isn't about confirming the answer your team was hoping for. It's about discovering the right problem — and the right direction to solve it.

Hold onto that distinction. It's the difference between research that helps and research that just flatters everyone's existing opinions.

Let's dig in.👇

What Is User Research?

User Research is the systematic work of understanding the people who use a product or service — within their goals, behaviors, environment, and context of use.

Through it, a design team gathers the evidence to answer questions like:

• Who are the actual users?
• In what situations do they use the product?
• What are they trying to accomplish?
• What difficulties and constraints do they run into?
• Is the current product actually meeting their needs?

Here's the part that trips people up. The goal of user research is not simply to collect users' opinions. Through observation, interviews, and data analysis, you're working to understand users' behavior and needs — and to turn that understanding into evidence you can base real design decisions on.

💡 Core Concept

User research isn't about listening to what users say. It's about understanding their behavior and context, and using that as evidence.

Example: Researching Users of a Shopping App

Say you're building a shopping app. Your team might investigate:

• How do users arrive at the app in the first place?
• What criteria do they use to browse and compare products?
• What information matters most when they decide to buy?
• Which screens confuse them, or make them drop off?
• What friction do they hit during checkout?

Analyze this, and you move past a vague "we should improve the checkout screen" to something far more useful: what exactly is the problem, and why it needs fixing.

The meaningful patterns you find get organized into User Insights — and those insights become the foundation that drives everything downstream: defining the problem, generating ideas, prototyping, and testing.

Qualitative vs. Quantitative Research

User research draws on two kinds of methods. They're not rivals — they answer different questions, and they work best together.

Qualitative Research

Qualitative research looks closely at a relatively small number of users to understand the reasons and context behind their behavior.

Common methods:

• In-depth interviews
• Field observation
• Contextual inquiry
• Usability testing

🗝️ The key: qualitative research doesn't just observe what users did. It explores why they did it — what they expected, what motivated them, and where they felt anxious or confused.

Quantitative Research

Quantitative research measures the behavior and responses of many users as numbers, to reveal scale and patterns.

Common methods:

• Structured surveys
• Web/app behavioral analytics
• Conversion and drop-off analysis
• A/B testing
• Metrics like clicks, errors, and task completion rates

🗝️ The key: quantitative research is what tells you how many users hit a problem, where drop-off happens, and whether your key metrics actually moved after a design change.

The Difference at a Glance

Why User Research Matters

1. It Lets You Test Your Team's Assumptions

When you start building a product, your team naturally makes assumptions about users:

• Users will want this feature.
• A long sign-up won't really matter.
• Everyone will understand what this icon means.
• Price is the biggest reason people leave.

Assumptions like these are a fine starting point — but they must never be treated as facts. User research gathers the evidence to support, revise, or discard each one.

2. It Reduces Your Team's Bias

Designers and product folks know their own product intimately — which makes it easy to assume users will behave the way they would. There's even a name for this in psychology: the False Consensus Effect — our tendency to overestimate how much other people think and act like us.

But the people building a product and the people using it can differ in prior knowledge, digital fluency, goals, physical and cognitive conditions, and the environments they use it in.

📌 A principle to remember: We are not our users.

Only by talking to real users and observing their behavior do you surface problems your team's perspective alone would never reveal.

3. It Helps You Find Root Causes, Not Just Symptoms

Users can describe the friction they feel. But they don't necessarily know its exact cause — or the right fix.

Say a user tells you "the search feature is frustrating." The real cause could be any of several very different problems: irrelevant results, unclear filters, poor typo handling, too many results, thin product information.

So instead of converting a user's words directly into a solution, you use questions and observation to find the root cause and the unmet need sitting underneath the behavior.

4. It Lowers the Risk of Building the Wrong Thing

Let's be honest about what research does and doesn't do. User research doesn't automatically raise revenue or conversion. What it does is help your team choose the important problems more accurately, and validate solutions early — which reduces the uncertainty in product development.

Catch a problem at the prototype stage, and changing direction is far cheaper than fixing it after development is finished. And even after launch, watching user behavior and feedback keeps surfacing new problems and opportunities.

The practical value of research:

• Catching wrong assumptions early
• Avoiding work on low-importance features
• Setting priorities based on real user problems
• Spotting usability issues at the prototype stage
• Supporting continuous improvement after launch

🔧 The practical view: User research isn't a tool that removes all risk. It's an activity that reduces uncertainty with better evidence.

Qualitative + Quantitative, Working Together

Here's how the two combine in practice.

Suppose your behavioral data reveals a high drop-off rate at the payment step. That tells you what is happening — and how big it is.

Then you run usability tests and interviews, and you uncover why people are leaving: a complicated input method, unexpected extra costs, an unclear error message.

Quantitative data confirms the scale of the problem. Qualitative research explains its cause and context. Put them together, and your design decisions get a lot more balanced — and a lot more defensible.

When Do You Do User Research?

Short version: not once, and not only at the start. Research repeats throughout the product's life — and what you research changes depending on the decision in front of you.

Here's the simple way to think about it. Each stage of the design process asks a different question, so each stage calls for different research:

But don't memorize the table. Memorize the question underneath it:

What decision do I need to make right now — and what do I need to know to make it?

Get that clear first, and everything else follows: the right question tells you the right participants, the right timing, and the right method to use.

One clarification: Tools like affinity diagrams, empathy maps, personas, and journey maps aren't methods for collecting data from users directly. They're tools for analyzing and organizing the data you've already gathered.

Key Takeaways

User research isn't about leaning only on what users say, and it isn't a rubber stamp for your team's ideas. It's the process of understanding — through evidence — what users actually do, in what situations, and why they struggle.

• Qualitative research digs into the reasons and context behind behavior.
• Quantitative research confirms the scale and patterns in numbers.
• Used together, they produce more balanced judgment.
• Research tests assumptions and reduces team bias.
• It repeats from discovery through post-launch, according to purpose.
• Before choosing a method, get clear on the decision the research needs to inform.

The one line to remember: Good user research isn't about confirming the answer your team wanted. It's about discovering the right problem — and the right direction.

Before You Go

Here's a small exercise.

Think of a product you use often, and one thing about it you'd love to change. Now write down your instinct — your assumption about what the problem is. For example: "People abandon the cart because shipping is too expensive."

Then ask yourself two questions:

1. Is this an assumption, or do I actually know it? (Be honest.)
2. What's the fastest way I could find out? Would I need qualitative research to understand why — or quantitative research to see how many people it affects? Or both?

That small habit — pausing to separate "what I assume" from "what I know," then matching the right method to the question — is the core reflex of every good researcher. Everything else in this discipline is built on top of it.

What's Next

In User Research (Part 2), we'll map out the full landscape of user research — how all the pieces fit together.

Then we'll compare the core preliminary research methods: what makes each one distinct, and how to choose the right one for the situation in front of you.

Follow this blog to get every new lesson as soon as it goes up — all free, always.

See you in the next one.

Thank you! 🙌