UX/UI Design, A to Z ┃ 1.9 User Interviews (Part 1): From Plan to Conversation

Good to see you again! :)

The goal of a user interview isn't to collect opinions. It's to understand what someone actually did in a real situation, and why they did it.

Ask a user "would you use a search feature?" and they'll say yes. People are agreeable, and they're optimistic about their future selves. Then you ship the search bar and watch the analytics: nobody touches it.

The problem wasn't the answer. It was the question. A good interview doesn't ask people to predict — it asks them to remember.

What Is a User Interview?

A user interview is a qualitative research method: a one-on-one conversation that explores a person's experiences, behaviors, motivations, and frustrations. Usually it's one participant at a time, though occasionally you'll interview a small group who use a service together — a family, a team.

Its strength is context. An interview tells you the story behind what someone does — the circumstances, the reasoning, the feeling in the moment. That's something no analytics dashboard can give you.

But it has a matching weakness. An interview tells you what people say, which isn't always what they do. If you need to know whether a screen is actually usable, an interview won't tell you — for that you watch people use it. More on that below.

The core principle:

What someone says they want matters less than what they did in a recent, real situation — and where they got stuck.

When Should You Interview?

This is the question people get wrong most often, so let's be precise about it. Interviews answer some questions well and others badly. The trick is knowing which is which.

Interviews are the right tool when you're asking why or what happens:

• Early in a project — to understand people's situation, goals, current habits, and problems before you design anything. What are they trying to get done? How do they do it today? Where does it break?
• After someone has used a prototype or product — to understand the reasons behind behavior you observed. You saw them hesitate on the payment screen; an interview helps you learn why.

Interviews are the wrong tool when you're asking is it usable:

• "Can people complete this task?" → run a usability test — give them the task and watch.
• "Is this button easy to find?" → usability test, not interview.

Here's the distinction that clears up most confusion. A usability test answers "can they do it?" An interview answers "why did they do it that way?" The two aren't rivals — they're a sequence. You watch someone struggle in a usability test, then you interview them to understand what they were thinking.

In short:

To understand the problem, interview. To check whether a design works, test. To learn why behavior happened, use both together.

A note on why "would you use this?" fails: it asks for a prediction, and people are unreliable narrators of their own future behavior. Swap it for "when did you last face this problem, and what did you do?" — now you're asking about something that actually happened.

The Whole Process, Start to Finish

Five steps, simply put:

1. Define your research goal and questions.
2. Recruit the right participants.
3. Prepare your interview guide and logistics.
4. Run the interview and capture it.
5. Analyze — turn records into patterns and insights.

Step 1 has its own lesson (1.7 Writing Research Objectives), and analysis (Step 5) gets its own treatment later. This article lives in the middle: recruiting, preparing, and running the interview.

1. Recruiting the Right People

A good interview starts not with meeting many people, but with meeting people who can actually answer your research questions. Participants should be current users, or people genuinely likely to use the service.

Set your screening criteria first

Base your criteria on the behaviors, experiences, and contexts tied to your research goal. A proto-persona can inform this — but remember it's an unvalidated hypothesis, so it shouldn't be the only basis for who you recruit.

For a finance-app study, useful criteria might be:

• Has used a mobile banking service within a recent time window
• Has performed the specific task or feature you're studying
• Falls somewhere identifiable on the spectrum from confident to struggling with digital finance

Demographics — age, job, gender — go in only when they directly relate to your research question. The point is never "what kind of person is this?" but "what have they experienced?"

Use a screener to confirm fit

A screener is a short questionnaire that checks whether an applicant meets your criteria. The craft here is to avoid questions that telegraph the "right" answer, and instead confirm real, specific experience.

The left-hand questions invite people to tell you what they think you want to hear. The right-hand ones ask about things that either happened or didn't.

Choose your recruiting channels

Depending on your audience and budget, use one or a mix:

• Existing users — customer panels, newsletters, in-service recruiting
• Professional recruiting services — when you need specific profiles, fast
• Communities and organizations — when you need particular experience or expertise
• Social media / open calls — when you want a wide net

Friends and colleagues can participate if they genuinely fit — but the relationship tends to soften honest answers. Where you can, use several channels to reduce bias.

On numbers: Run each round small, learn, then design the next round around what you found. Practitioner guides often suggest around 4–8 people per round of interviews or usability testing as a common starting point — but it's a starting point, not a rule.

2. Planning the Interview

Decide how you'll run it

In person lets you read facial expressions, body language, and the surrounding environment. Remote removes travel and location constraints and makes scheduling easier. Choose based on your topic, your participants' access, and whether you need to observe their environment.

Write your interview guide

An interview guide is a document that organizes your topics and question order around your research goal. It's not a script to read aloud — it's a checklist so you don't forget anything important while staying in a natural conversation.

Good questions follow four rules:

• Open, not yes/no — invite a story, not a one-word answer.
• Past, not future — ask about recent real experience, not intentions.
• Neutral, not leading — don't bake the answer (or a judgment) into the question.
• Broad to specific — start wide, then narrow toward concrete situations and reasons.

Finish your logistics

Before the interview, confirm:

• The participant knows the purpose, the duration, and how their data will be used
• Consent for recording and for handling personal data
• Roles split between facilitator and notetaker
• Meeting link, location, equipment, and materials checked
• A pilot interview or rehearsal before the real thing

3. Running the Interview

Run it in three parts — open, body, close. The shape keeps things natural and steady.

Open — build trust

Explain the purpose and how it'll go, and confirm consent for recording. A simple warm-up question helps the participant relax into talking.

"What finance app do you find yourself opening most these days?"

Body — explore real experience

Anchor your questions in recent, concrete experiences. When the participant mentions an important moment, follow it:

"What did you do then?" · "Why did you decide that?" · "Could you tell me a bit more?"

Stay in a natural conversation rather than marching through your guide mechanically — but if the talk drifts far from your research questions, gently steer back at a good moment.

Close — catch what's missing

"Is there anything important we didn't talk about today?"

This one question often surfaces the experience you didn't know to ask about. Thank the participant, and explain the promised incentive and any next steps.

The interviewer's mindset

• Listen more than you talk.
• Don't evaluate answers or supply the "right" one.
• Don't rush to fill silences — people often say the best thing right after a pause.
• Record not just words, but hesitations, shifts in emotion, and context.
• Never generalize one person's strong opinion into a fact about all users.

4. After the Interview: From Records to Insight

As soon as it's over, write up your notes while they're fresh. Separate what people said from what you observed, then look for behaviors, problems, and exceptions that repeat across participants.

Your analysis shouldn't end as a pile of quotes. It should flow:

Observed evidence → recurring pattern → impact on the user → implication for design

We won't go deep on analysis here. Grouping notes by shared meaning to find patterns is covered in the Affinity Diagram lesson; structuring what users say, do, think, and feel is covered in the Empathy Map lesson.

Showing It in Your Portfolio

In a UX portfolio, "I ran interviews with N people" matters far less than how the interviews changed a design decision. Show:

• What uncertainty or assumption you set out to check
• Why you recruited those particular participants
• What repeating patterns you found
• How your problem definition or design changed as a result

"At first I assumed users didn't need a search feature. But in interviews, people couldn't find the search bar and were navigating by menu instead. So rather than questioning whether search was needed, I prioritized its discoverability and the information architecture around it."

That's the shape of a good portfolio story:

An assumption, the evidence that challenged it, and the decision that changed.

Key Takeaways

• A user interview is a qualitative method for understanding experience and the reasons behind behavior — not a way to collect opinions.
• Use it early to explore problems and context; use it after product use to understand why observed behavior happened.
• It answers "why", not "is it usable" — pair it with usability testing when you need both.
• Recruit for experience, not demographics. Screen for what people actually did, using questions that don't reveal the "right" answer.
• Ask open, past-tense, neutral questions — remembering beats predicting.
• Run it open → body → close, and listen more than you talk.
• Connect findings to patterns and design decisions, never a pile of quotes.

Before You Go

A 10-minute exercise

Take one weak interview question and rebuild it.

Here's the question:

"Do you think our app's notifications are helpful?"

It breaks three of our four rules at once — it's yes/no, it's leading, and it asks for an opinion instead of an experience.

1. Rewrite it as an open, past-tense, neutral question about something that actually happened.
2. Now write the follow-up you'd ask after their answer — the "why did you do that?" that goes one layer deeper.
3. Check your rewrite against the four rules. Did any leading assumption sneak back in?

One possible rewrite:

"Think about the last notification from our app you remember getting. What did you do when it arrived?" — then follow with "What made you do that?"

The follow-up is where interviews earn their keep. Anyone can ask a scripted question; the insight lives in what you ask next.

What's Next

User Interviews (Part 2): Asking Better Questions

You know the four rules now. Next up: the techniques that turn them into real skill.

We'll cover:

• The 5 Whys — how asking "why" five times gets you past the surface answer to the actual reason
• Structured, semi-structured, unstructured — the three ways to run an interview, and when each one fits
• How to design a question set that reliably surfaces insight, instead of hoping for it

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! 🙌