User Research Methods
You are not your user. Here's how to discover what people actually need — through interviews, surveys, personas, empathy maps, journey maps, and jobs-to-be-done.
The Snuggie was not a joke
In 2008, a product called the Snuggie — a blanket with sleeves — became one of the best-selling infomercial products in history. Design critics mocked it. "It's just a backwards bathrobe." The internet turned it into a punchline.
But the Snuggie team had done something clever: they watched people. Specifically, they observed that millions of Americans watched TV under blankets on their couch, and every time they needed to reach for the remote, answer their phone, or grab a drink, they had to pull their arms out from under the blanket. The blanket slipped off. They got cold.
The Snuggie solved a real, observed frustration. It sold over 30 million units and generated over $500 million in revenue.
Nobody asked for a blanket with sleeves. But the research — simple observation of real behavior — revealed a genuine unmet need.
This is what user research does. It reveals the problems people actually have, not the problems you assume they have.
Why research comes first
The number one reason products fail is not bad design, buggy code, or poor marketing. According to CB Insights analysis of 110+ failed startups, the number one killer is "no market need" — the team built something nobody wanted.
User research is how you avoid that fate. It answers the most dangerous question in product development: Are we solving a real problem for real people?
✗ Without AI
- ✗You assume you know the problem
- ✗You design for yourself
- ✗You discover failures after launch
- ✗You argue with opinions in meetings
- ✗You build features nobody uses
✓ With AI
- ✓You discover the actual problem
- ✓You design for real user needs
- ✓You catch failures in prototyping
- ✓You settle debates with evidence
- ✓You build features people request
The two types of research
All user research falls into two categories:
| Type | Purpose | When to use | Examples |
|---|---|---|---|
| Qualitative | Understand why — motivations, frustrations, mental models | Early discovery, understanding context | Interviews, observations, diary studies |
| Quantitative | Measure what and how much — patterns, frequencies, sizes | Validating hypotheses, measuring impact | Surveys, analytics, A/B tests |
Think of it this way: qualitative research tells you that users are frustrated with checkout. Quantitative research tells you that 34% of users abandon their cart at the payment step.
You need both. Qualitative research generates insights. Quantitative research validates them at scale.
User interviews — the foundation of UX research
A user interview is a structured conversation with someone who uses (or might use) your product. It is the single most important research method in UX, because it reveals motivations, frustrations, and mental models that no analytics tool can capture.
How to run a great interview
Recruit the right people. Interview actual users or people who match your target audience. Not your coworkers. Not your friends. Not yourself. 5-8 participants is the sweet spot for most studies.
Prepare open-ended questions. Never ask yes/no questions. "Do you like our checkout?" gets a useless answer. "Walk me through the last time you bought something online and it was frustrating" opens a gold mine.
Listen more than you talk. The 80/20 rule: your participant should talk 80% of the time. Your job is to ask, listen, and follow up — not to explain or defend your product.
Ask "why" five times. When someone says "I don't use that feature," ask why. When they answer, ask why again. Keep going. The first answer is surface-level. The fifth answer is the real insight.
Record everything. With permission, record audio/video. Take notes during the session, but review the recording afterwards. You will catch things you missed in real time.
Questions that work vs. questions that fail
| Bad question | Why it fails | Better question |
|---|---|---|
| "Do you like our app?" | Leading, yes/no | "Tell me about the last time you used our app." |
| "Would you use a feature that does X?" | Hypothetical — people cannot predict future behavior | "How do you currently handle X?" |
| "Don't you think the navigation is confusing?" | Leading — you are telling them what to think | "Show me how you would find [specific thing]." |
| "On a scale of 1-10, how easy was that?" | Quantitative answer without context | "What was going through your mind as you did that?" |
There Are No Dumb Questions
"What if users say they want something but they actually do not?"
This happens constantly. People are terrible at predicting their own behavior. Henry Ford supposedly said, "If I had asked people what they wanted, they would have said faster horses." The fix: never ask people what they want. Ask them about their problems, their frustrations, and their current behavior. Your job is to discover the need; designing the solution comes later.
"How do I get people to be honest instead of polite?"
Frame the interview as testing the product, not testing the user. Say: "There are no wrong answers. If something is confusing, that is the product's fault, not yours. Your honest feedback helps us make it better." Also, do not have the person who designed the feature conduct the interview — participants tend to be nicer to the designer.
Fix These Interview Questions
25 XPPersonas — making research actionable
After conducting interviews, you have pages of notes and hours of recordings. How do you make that useful for your design team?
You create personas — fictional but research-based representations of your key user types. A persona is not a demographic profile ("women aged 25-34"). It is a behavioral archetype that captures goals, frustrations, and context.
Anatomy of a useful persona
| Element | Example |
|---|---|
| Name and photo | Sarah, 32, freelance graphic designer |
| Quote | "I just need to send an invoice without it taking 20 minutes" |
| Goals | Get paid faster, spend less time on admin, look professional to clients |
| Frustrations | Current tool is bloated, invoicing takes too many steps, no mobile app |
| Behavior | Sends 8-12 invoices per month, uses phone for most work tasks, switches between 3 clients daily |
| Context | Works from coffee shops, unreliable wifi, needs offline access |
Empathy maps — quick synthesis
An empathy map is a fast way to capture what you learned about a user in four quadrants:
| Quadrant | Question it answers | Example |
|---|---|---|
| Says | What did the user literally say during the interview? | "I always forget where the save button is" |
| Thinks | What might they be thinking but not saying? | "This app makes me feel stupid" |
| Does | What actions and behaviors did you observe? | Clicks the back button 3 times before finding the right page |
| Feels | What emotions are they experiencing? | Frustrated, embarrassed, impatient |
Empathy maps work best as a team exercise after interviews. Put one on a whiteboard, hand out sticky notes, and have everyone add their observations. Patterns emerge fast.
Journey maps — the full user story
A journey map traces a user's entire experience with your product over time — from first hearing about it to becoming a regular user (or giving up).
Friend recommends it on social media
Reads features page, watches demo video, compares to competitor
Confused by pricing tiers, almost abandons, picks free plan
Tutorial is 12 steps long, skips most of it, gets lost
Finds 3 features they love, ignores the rest
Needs a feature on the paid plan, annoyed at the upsell
Compares pricing again, decides based on whether the product saved them time
The power of a journey map is that it reveals the gaps between stages — the moments where users get confused, frustrated, or lost. These gaps are your biggest design opportunities.
There Are No Dumb Questions
"What is the difference between a persona and a journey map?"
A persona answers who your user is. A journey map answers what their experience looks like over time. You typically create personas first, then map the journey for each persona. Different personas may have very different journeys through the same product.
Map a Real Journey
50 XPJobs to Be Done — the framework that explains milkshakes
Clayton Christensen, a Harvard professor, told a famous story about McDonald's trying to sell more milkshakes. They surveyed customers: "How can we improve our milkshakes? Thicker? Sweeter? More flavors?" Sales did not change.
Then they sent researchers to observe. They discovered that most milkshakes were bought at 6:30 AM by commuters in cars. These people had a long, boring drive and needed something to keep them occupied. They did not want a better milkshake — they wanted a better commute companion.
The "job" the milkshake was hired to do was: "Give me something interesting to consume during a boring 40-minute commute that fits in my cupholder."
This is the Jobs to Be Done (JTBD) framework. Instead of asking "Who is our customer?" it asks "What job is the customer hiring our product to do?"
The formula: When [situation], I want to [motivation], so I can [outcome].
- When I am commuting alone for 40 minutes, I want something engaging to consume with one hand, so I can make the drive less boring.
- When I have 5 minutes between meetings, I want to quickly check my team's progress, so I can walk into the next meeting prepared.
Key takeaways
- You are not your user — the number one reason products fail is building something nobody needs; research prevents this
- Qualitative research (interviews, observations) reveals why; quantitative research (surveys, analytics) measures how much
- 5 users find 85% of usability issues — you do not need massive sample sizes for qualitative research
- Interview technique matters: ask open-ended questions, listen 80% of the time, ask "why" five times, never ask people to predict their future behavior
- Personas synthesize research into actionable user archetypes — but they must be based on real data, not imagination
- Journey maps reveal the gaps between stages where users get frustrated or lost
- Jobs to Be Done shifts the question from "who is our customer" to "what job are they hiring our product to do"
Knowledge Check
1.Why should you avoid asking users 'Would you use this feature?' during an interview?
2.According to Jakob Nielsen's research, how many users do you typically need to uncover approximately 85% of usability issues?
3.What makes a persona useful versus misleading?
4.In the Jobs to Be Done framework, what 'job' were McDonald's morning commuters hiring the milkshake to do?