How to Conduct User Interviews

User interviews are not conversations. They're structured research sessions where you learn how someone thinks, not what they want you to build.

That distinction matters. A lot of teams run "interviews" that are really just informal chats where they collect wish lists. Those sessions feel productive in the moment and produce almost no usable insight.

Here's how to run interviews that actually inform design decisions.

When to use interviews

Interviews belong in early-stage research. Use them when you're trying to understand:

• How users currently solve a problem (with or without your product)
• What their mental model of a domain looks like
• What motivates their behavior

Don't use interviews to validate design decisions — use usability testing for that. Don't use them to find out what features users want — their suggestions are usually solutions to unstated problems, and you need to find the problem first.

Writing a discussion guide

A discussion guide is a structured outline of your interview. It's not a script — you won't read questions verbatim. It's a map that keeps you on track.

Structure it in three parts:

Warm-up (5 minutes): Background questions. Current role, how they spend their day, what tools they use. This relaxes the participant and gives you context.

Core topics (30-40 minutes): 4-6 topic areas with 2-3 questions each. Focus on past behavior ("Walk me through the last time you...") rather than future speculation ("Would you..."). Past behavior is real data. Future behavior is a guess.

Wrap-up (5 minutes): "Is there anything I haven't asked about that you think is important?" You'll get surprising answers.

Keep your questions open-ended. "How do you currently manage your design files?" is good. "Do you find it hard to manage your design files?" is leading.

Write your guide in Notion so it's shareable and editable before sessions.

Setting up the session

Recording consent: Ask for permission to record before the session, not during. Explain how the recording will be used. Most participants say yes once they understand it's for internal research, not public use.

Environment: Remote interviews are fine. Use a video call so you can see facial expressions. If you're in person, choose a quiet, neutral location — the participant's own workspace works well because you can observe their environment.

Start with easy questions. The first five minutes should feel like small talk. Participants who are comfortable share more.

Have a second person take notes. As the interviewer, your job is to listen and follow up. You can't do that well while typing. If you're solo, record and take sparse notes — just timestamps and key phrases.

Active listening techniques

The most important skill in user interviews is knowing when to follow a thread versus staying on your guide.

When a participant says something surprising or contradictory, follow it. Use neutral probes:

• "Tell me more about that."
• "What do you mean by [specific word they used]?"
• "Can you give me an example?"

Don't rephrase what they said back to them — you'll accidentally lead them toward your interpretation. Use their exact words.

The silence technique: After a participant finishes an answer, wait three to four seconds before responding. Many will fill the silence with more detail, often the most honest thing they say.

Avoiding leading questions

This is where most interviewers go wrong.

Leading questions sound like this:

• "Does the confusing navigation make it hard to find things?"
• "Would it be helpful if we added a dashboard?"
• "So you basically use it like a project management tool?"

Neutral versions:

• "How do you find what you're looking for?"
• "What would make that easier?"
• "How would you describe what you use it for?"

Don't nod enthusiastically or say "great answer" — it signals that certain answers please you, which shapes what the participant says next.

Note-taking approaches

Even with a recording, take notes during the session. Here's what to capture:

• Direct quotes (with timestamps)
• Moments of hesitation or confusion
• Things the participant does (behaviors), not just what they say
• Your own observations and questions to follow up on

Mark your interpretations clearly — "I think this means X" should be distinguished from "Participant said X."

After the session, write a brief summary while it's fresh. Don't wait to do all your synthesis at once — you'll lose the nuance.

Synthesizing findings in Miro or Notion

After 5-8 interviews, you'll have enough data to start synthesis.

Affinity mapping in Miro: Take your notes and pull out discrete observations — one observation per sticky note. Group similar observations together. Name the groups. Patterns will emerge.

Research repository in Notion: Create a database where each interview is a record. Tag by participant type, date, and key themes. Link quotes to themes. This makes the data searchable when you need it later.

Synthesize findings in Miro

Look for patterns across participants, not individual quotes. One person saying something is interesting. Five people independently saying the same thing is a finding.

Common mistakes

Interviewing friends and family. They want to help you and they know too much about your thinking. Their answers will be skewed toward what they think you want to hear. Recruit strangers.

Asking hypothetical questions. "Would you use a feature that..." is not a research question. "What do you currently do when..." is. Hypotheticals produce hypothetical data.

Treating the discussion guide as a checklist. If a participant goes off-script in a genuinely interesting direction, follow them. The guide exists to keep you on track, not to prevent you from learning anything unexpected.

Sharing findings before synthesis. One striking quote from one participant is not a finding. Synthesize across participants before drawing conclusions.

Build your research repository in Notion

Good user interviews take practice. Your first few sessions will feel awkward. That's normal. The skill compounds — by session ten, you'll be noticing things in the first five minutes that tell you exactly where to dig.