A Practical Guide to User Interviews

User interviews are where assumptions go to die. That feature you’re convinced users need? They don’t. That workflow you think is intuitive? It’s not. The problem you’re solving? Might not actually be their biggest pain.

The best user interviews completely change product direction. The worst ones confirm what the team already believed, usually because they asked leading questions and ignored uncomfortable answers.

Good user research isn’t about validation, it’s about learning. If you finish an interview more confident in your original hypothesis, you probably asked the wrong questions or heard what you wanted to hear.

Why Most User Interviews Fail

Let me be direct: most teams are terrible at user interviews. Not because they’re lazy or stupid, but because interviewing is a skill nobody teaches them.

They Pitch Instead of Listen

I’ve watched engineers explain their solution for ten minutes before asking what problems users face. By then, you’ve anchored the conversation. Users will discuss your solution, not their problems.

Your job is to shut up and listen. I know that’s hard. You’re excited about what you’re building. But users don’t care about your solution until you understand their problem.

Rule I follow: user talks 80% of the time, I talk 20%. If I’m talking more, I’m doing it wrong.

They Ask Hypothetical Questions

“Would you use this feature?” is useless. People are terrible at predicting their own behavior. They’ll say yes because they want to be helpful or sound smart. Then they never actually use it.

Better questions focus on past behavior. “Tell me about the last time you struggled with X.” “Walk me through how you currently solve this problem.” “What did you try that didn’t work?”

Past behavior predicts future behavior far better than hypothetical preferences do.

They Ignore Body Language and Hesitation

Users will be polite. They’ll tell you your idea is great even if they’d never use it. But watch their face when you describe it. Listen for hesitation. Notice when enthusiasm drops.

I remember pitching a feature to a user who kept saying “yeah, that could be useful.” But every time I mentioned it, there was a tiny pause. I finally asked, “You don’t sound convinced.” Turned out they had a workaround they liked better. If I’d taken “useful” at face value, we’d have built something nobody wanted.

A Framework for Effective Interviews

Here’s what actually works when talking to users.

Prepare, But Stay Flexible

Have a discussion guide, not a script. Know what you want to learn, but be willing to follow unexpected directions.

I structure guides around themes, not specific questions:

• Current workflow and tools
• Pain points and frustrations
• Workarounds and hacks
• Goals and desired outcomes

Then I improvise based on what the user says. If they mention something interesting, I explore it. Rigid scripts miss the gold.

Start Broad, Then Go Deep

Begin with open-ended questions about their context. “Walk me through your typical day.” “How do you currently handle X?” This builds rapport and gives you context for deeper questions.

Then zoom into specific moments. “You mentioned struggling with reports. Tell me about the last time that happened. What were you trying to accomplish? What got in the way?”

The more specific you get, the more useful the insights. “Reporting is hard” tells you nothing. “Last week I spent three hours trying to pull data from two systems into a format my boss would accept” tells you everything.

Ask “Why” Multiple Times

Surface answers rarely reveal root problems. When someone says they want a feature, ask why. When they explain, ask why again. And again.

This isn’t interrogation, it’s archaeology. You’re digging past stated needs to underlying motivations.

User: “I need better dashboards.” You: “What would better dashboards help you do?” User: “Make faster decisions.” You: “What decisions are slow right now?” User: “Figuring out which projects are actually on track.” You: “What makes that hard?” User: “Project managers all report differently, so I can’t compare.”

Now you’re getting somewhere. The problem isn’t dashboards—it’s inconsistent data structure. Different solution needed.

Watch What They Do, Not Just What They Say

If possible, observe actual workflows. Ask users to share their screen and show you how they work. Seeing beats hearing.

I once interviewed users about a financial planning tool. They all said they wanted more features. Then I watched them use it—they struggled with features we already had. They didn’t need more. They needed the existing product to be simpler and more obvious.

Actions reveal truth more reliably than descriptions do.

Putting This Into Practice

Theory is nice. Here’s how to actually run better interviews.

Recruit the Right Participants

Talk to people who have the problem you’re solving, not people who might theoretically care about your solution.

If you’re building project management software, talk to project managers struggling with current tools. Not to their bosses who buy software. Not to people who’ve never managed projects. Actual users with actual problems.

I aim for 5-8 interviews per user segment. Fewer and you might talk to outliers. More and you start hearing the same things repeatedly. Diminishing returns set in fast.

Record Everything (With Permission)

Don’t rely on memory or notes. Record the conversation so you can focus on listening, not scribbling.

I use a tool that transcribe automatically. Then I review transcripts to pull key quotes and themes. Memory is unreliable, recordings let you catch things you missed live.

Always ask permission first. Most people don’t mind if you explain you want to focus on the conversation rather than note-taking.

Involve Your Team

Engineers and designers should join interviews. Hearing directly from users is far more powerful than reading a research report.

I schedule interviews when team members can join. If they can’t, I share recordings. Second-hand research loses impact.

Synthesize Themes, Not Just Quotes

After interviews, identify patterns. What did multiple users struggle with? What problems came up repeatedly? What surprised you?

Don’t just collect quotes, find the underlying themes connecting them. “Users want better reporting” is a quote. “Users struggle to trust data accuracy, which makes them hesitant to share reports with leadership” is a theme worth building around.

I use simple affinity mapping: write insights on sticky notes, group related ones, name the groups. Digital tools work, but physical notes make patterns more visible.

Common Mistakes That Wreck Interviews

Let me save you from things I’ve gotten wrong.

Leading Questions

“Don’t you think it would be better if…” is leading. You’re guiding them to agree with you.

Better: “How do you currently handle X?” Neutral, open-ended, lets them describe reality without your framing.

Talking About Your Solution Too Early

Save your pitch for the end. First, understand their world. Then, if appropriate, show what you’re building and get reactions.

Starting with your solution anchors the conversation around your thinking. Starting with their problems lets you learn whether your solution even matters.

Not Following Up on Vague Answers

User: “The process is complicated.” Bad response: “Okay, what else?” Good response: “Complicated how? Walk me through the last time you did it.”

Vague answers hide useful specifics. Your job is extracting them.

Ignoring Contradictions

If someone says time-saving is their priority but describes spending hours on manual processes they could automate, that contradiction matters. Explore it.

“You mentioned time is tight, but you’re doing X manually. Help me understand that choice.”

Often the contradiction reveals the real constraint. Maybe they don’t trust automation. Maybe the automation tools are harder than the manual process. Maybe they’ve tried and been burned before.

Scaling Interviews Effectively

You can’t interview every user. Here’s how to get value without making it your full-time job.

Continuous, Not Campaign-Based

Don’t do six months of research, then go heads-down building for a year. Talk to users continuously. Even one interview per week builds ongoing customer connection.

Maintain regular touchpoints with power users. Not formal research sessions, casual conversations about how they work and what’s changing. This prevents you from drifting too far from reality.

Mix Methods

Interviews are deep but slow. Complement them with surveys (broad but shallow), usage analytics (behavioral truth), and support tickets (pain points).

Each method has blind spots. Together, they give you a fuller picture than any single approach.

Build a Research Repository

Don’t let insights disappear into decks nobody reads. Create a searchable repository of key findings, quotes, and themes.

When someone proposes a feature, you can quickly check: did this come up in research? What did users say about similar ideas?

Tools like Notion pages work. The format matters less than making insights findable and reusable.

Key Takeaways

Here’s what matters for user interviews:

• Listen more than you talk: Your job is understanding their world, not explaining yours. If you’re talking more than 20% of the time, you’re doing it wrong.
• Focus on past behavior, not future preferences: “Tell me about the last time X happened” beats “Would you use Y?” People are terrible at predicting their own behavior.
• Ask why repeatedly: Surface answers rarely reveal root problems. Keep asking why to uncover underlying motivations and constraints.
• Involve your team: Second-hand research loses impact. Engineers and designers should hear directly from users whenever possible.

Making This Work

Start small. Schedule one user interview this week. Prepare a few open-ended questions about their workflow and pain points. Record it (with permission). Review the recording and write down three things you learned.

You’ll probably realize how much you assumed that wasn’t true. That’s valuable. Do it regularly and you’ll build products that actually solve real problems instead of imagined ones.

The best product teams I know don’t just interview users—they’re genuinely curious about them. Cultivate that curiosity and the technique will follow.

Have questions or thoughts? Get in touch - I’d love to hear from you!