User interviews: what to ask to get honest answers?
How to ask, listen and take notes so a user interview gives you facts instead of polite compliments.
Written by Phan Lam Duy Khoi
Ask about a specific time something actually happened, such as “When was the last time you…, and how did you do it?”, instead of asking for opinions or what people would do in the future. Do not suggest the answer, do not pitch your idea, listen more than you talk, and keep facts separate from interpretations in your notes.
Three people said “I'd use it”, then nobody did
This is an illustrative situation. You are the new PO of an order-management app for small online sellers. Your manager wants a feature that automatically messages past customers and invites them to buy again. To be safe, you call three sellers who use the app and ask: “If the app could message your customers to buy again, would you use it?”
All three say: “Of course, that sounds great.” You report back to the team with confidence. The team builds it over two sprints (a sprint is a short, fixed-length work cycle). The feature ships, and a month later almost nobody has switched it on.
Those three sellers did not lie to you. They answered the question you asked: a question about the future, about an idea that sounds nice, from someone they did not want to disappoint. This article covers a different way to ask: what to ask, whom to ask, how to take notes, and how to turn several interviews into something the team can use to decide.
Why are user interviews harder than they look?
Talking to users sounds simple. The hard part is that every answer sounds useful, including answers that do not reflect what people actually do. There are three main reasons.
- People are polite. When you describe an idea you are excited about, it is easy for the listener to say something nice. Jakob Nielsen of NN/g notes that users may tell you what they think you want to hear.
- People are poor at predicting their own future. “Would you use it?” forces them to guess. The same article advises not to believe what people predict they may do in the future.
- People report from memory. NN/g describes interview data as reported behaviour, not observed behaviour. Memory can be wrong, miss details, or lean toward the image the speaker wants others to see.
New POs carry one more pressure: you want a quick answer to report back. That makes it tempting to ask questions that produce a “yes”. A good interview is not there to confirm an idea. It is there to understand what users do today, where they struggle, and how they cope.
Rob Fitzpatrick's book The Mom Test was written for exactly this problem: how to learn the truth from customers even when they are not fully honest with you. If you want to go deeper after this article, it is worth looking up.
What are the steps of user interviewing?
You do not need a large research project. For one specific product question, you can go through these four steps in a few days.
- Define what to learn: A question about behaviour, not about your idea
- Recruit and get consent: People who did the task recently
- Ask about the last time: Retell what happened, then dig deeper
- Note and synthesise: Separate facts, group repeated patterns
If after synthesis you still cannot answer what you needed to learn, go back to step 1: fix the question or find better-matched people.
In step 1, turn the idea into a question about behaviour. Instead of “Do sellers want automatic customer messages?”, write “How do sellers invite past customers to buy again today, and where does it cost them effort?”. The second question can be answered with things that happened. The first can only be answered with guesses.
What should you ask in a user interview?
The main rule: ask about specific past events, not opinions or hypotheticals. NN/g recommends jogging the memory by asking about a specific event rather than a general process, for example “Tell me about the last time you…”. A specific occasion has a date, a context and details, so it is harder to embellish.
The second rule: do not suggest the answer. NN/g defines a leading question as one that includes or implies the answer the interviewer wants. The table puts fragile questions next to better ones.
| Fragile question | Why it fails | Better question |
|---|---|---|
| “If the app had feature X, would you use it?” | It asks about the future. People have to guess and may say “yes” to be polite. | “When was the last time you did the task X is meant to help with? How did you do it?” |
| “Do you think this idea is good?” | You are pitching. What comes back is a compliment, not a fact. | “What does this task cost you today? Walk me through the last time.” |
| “Messaging old customers is a real pain, right?” | A leading question: the answer is already in it. | “What is easy and what is hard when you message old customers?” |
| “How do you usually do this?” | Too general. People describe the ideal version. | “The last time you did this, where did you start?” |
| “What features would you like us to add?” | It hands the job of designing the solution to the user. | “When was the last time the app wasted your time?” |
| “Would you pay for this?” | A promise about the future that costs nothing to make. | “Are you paying money or effort for any way of solving this today?” |
After the opening question, the value is in the follow-ups. A few work almost anywhere: “Can you tell me more?”, “What did you do next?”, “Why did you do it that way?”, “You said X, what do you mean?”. When you repeat something back, use the participant's exact words. NN/g advises against restating participants' words in your own terms, because it is an easy way to slip your own idea in.
How does an interview session flow?
A session can follow four parts. The interview guide at the end of this article uses the same order.
- Opening: Purpose, length, ask to take notes
- Context: Who they are, what their work is like
- The last time: Retell one specific occasion
- Dig deeper and close: Ask why, thank them, ask who else to meet
Listen more than you talk. An easy check: if your notes contain more of your own sentences than the user's, the session is drifting. When the person pauses, try staying silent for a few seconds before your next question; they may keep going on their own. NN/g also warns against interrupting or rushing participants, because it damages rapport.
If you can, go as a pair: one person asks, one takes notes. The interviewer can focus on listening and digging deeper, and the notes come out more complete. If you are alone, jot keywords during the session and write them up straight afterwards while your memory is fresh.
Whom to recruit, and how to handle consent and privacy?
The right people have done the task you want to understand, and done it recently. A simple screening question before booking: “In the past month, have you [done the task]?”. Anyone who says no is not the person you need for this round.
- Find people through colleagues who talk to customers: support, sales, operations. They know who has just run into the situation.
- Do not only ask friends, colleagues, or people who already love the product. They are inclined to say what pleases you.
- Aim for heavy users, light users, and people who stopped using the product. People who left can tell you what those who stayed do not say.
- There is no fixed number for interviews. The often-quoted 5 users is NN/g guidance for usability testing, not interviews. Start with a few people and stop when new sessions no longer teach you anything new.
For consent and privacy, these apply to every session:
- Explain the purpose, the length, and that they can stop at any time.
- Record audio or screens only with clear permission. Never record secretly.
- In your notes, refer to participants by code, such as “Participant 1”, “Participant 2”. Keep contact details separate and visible only to those who need them.
- Do not put names, phone numbers, recordings or notes containing personal data into AI tools unless your company has a policy allowing it. The article on using AI in PO work covers this boundary.
- Follow your company's data rules. If they are unclear, ask your manager before booking the first session.
How do you take notes that separate facts from interpretation?
While you listen, your mind interprets on its own: “so she needs a reminder feature”. That may be right, but it is your thought, not what the user said. If both go on the same line, a few days later you will no longer be able to tell them apart.
- Fact: something the person did or said. Write their exact words in quotation marks when you can.
- Interpretation: what you infer from the facts. Write it separately, mark it clearly, and add the question you need to check with others.
- Notable emotion: moments of frustration, embarrassment or excitement. Note what they were describing at the time.
Turning several sessions into a conclusion builds on this separation. After each session, copy each fact onto its own line or card. Once you have a few sessions, group similar lines and count the people who said them, not the number of mentions. One person saying something three times is still one person.
Write each group as a sentence with a count: “3 of 4 people described…”. That keeps you honest about how certain the conclusion is. A very striking story from one person is a signal to ask more, not yet a pattern.
Example: interviewing the seller again
Back to the opening situation. This time the PO does not describe the idea and asks about the last time instead. This is an illustrative conversation with a fictional seller, called Participant 2.
- PO: When was the last time you messaged a past customer to invite them to buy again?
- Participant 2: Probably last week. There's a customer who often buys milk for her kid.
- PO: Could you walk me through what you did?
- Participant 2: I remembered she usually orders at the end of the month, so I opened my phone and asked if she needed more.
- PO: How did you remember it was the end of the month?
- Participant 2: Just in my head. I remember regulars. People who only bought once, I don't message.
- PO: What about people who only bought once?
- Participant 2: Messaging strangers gets you blocked. I once sent a message to my whole list and several people blocked my page.
- PO: You said “blocked my page”. Can you tell me more?
- Participant 2: Since then I only message people one by one, people I'm sure will need something soon.
No question asks “would you use it”. No question suggests an answer. The PO's last question repeats the seller's own words, “blocked my page”, instead of rephrasing them. The table shows the notes from that session, with facts and interpretations separated.
| Note | Type | Next step |
|---|---|---|
| Messages regulars to ask if they need more, relying on memory of when they usually buy | Fact | Ask others how they keep track of customers' timing |
| Does not message customers who bought only once | Fact | Ask other sellers whether they message one-time buyers, and why |
| Once messaged the whole list, “several people blocked my page” | Fact (exact words) | Flag as a risk for automatic sending |
| She needs to know which regulars are about to run out more than she needs automatic messages | Interpretation | Check with other sellers, no conclusion yet |
Suppose that after four sessions like this, 3 of 4 people say they only message regulars and track timing from memory, and 2 of 4 mention being blocked after sending in bulk. These are illustrative numbers. The conclusion now looks very different from the original “of course”: the problem may be remembering which customers are due to buy, while automatic bulk messages are something sellers actively avoid.
From here, treat it like a feature request: test small first, for example a list of “regulars due to buy again” that sellers message themselves. After launch, measure whether sellers actually use it, instead of only asking whether they like it.
Interview guide and note-taking sheet templates
These two templates work together. The guide follows the four parts of a session described above. The note sheet helps you separate facts from interpretations while you listen. Copy them and replace the parts in square brackets with your own content.
What we need to learn: [one question about behaviour, e.g. how users do task X today and where it costs them effort] Who to meet: people who have [done task X] in [a recent period] 1. OPENING - Thank you for giving us [length] minutes. We want to understand how you [do task X]; there are no right or wrong answers. - We are learning, not selling or presenting anything. - Is it OK if we take notes [and record audio]? Notes stay within the team and will not include your name. You can stop at any time. 2. CONTEXT - Could you briefly describe your daily work related to [task X]? - Where does this task fit in your day or week? 3. THE LAST TIME - When was the last time you [did task X]? - Could you walk me through it from the start: where did you begin? - What did you do next? - What was easy, and what was hard? - What tools or methods do you use for this? 4. DIG DEEPER AND CLOSE - You said “[repeat their exact words]”. Can you tell me more? - Why do you do it that way? - Is there anything about [task X] I have not asked that you think I should know? - Do you know anyone else who does this whom I should talk to? - Thank you. REMINDER TO SELF: do not pitch the idea, do not ask “would you use it”, do not suggest answers, stay silent for a few seconds before the next question.
Participant code: [Participant 1] Date: [date] Interviewer: [name] | Note-taker: [name] Consent to notes: [yes/no] | Consent to recording: [yes/no] FACTS (what they did or said; exact words in quotation marks) - - - MY INTERPRETATIONS (what I infer; check with others) - - NOTABLE EMOTIONS (when, and what they were describing) - HOW THEY COPE TODAY (tools, tricks, manual work) - QUESTIONS FOR THE NEXT SESSION - Check before saving: no real names, phone numbers or personal data in these notes.
After each session, copy the facts into one shared sheet for the whole round, with the participant code on every line. Once you have a few sessions, group similar lines and count people, as described in the note-taking section above.
Common mistakes in user interviews
- Pitching the idea mid-session. As soon as you describe it, the listener switches to giving feedback and compliments. If you really need to explore the idea, save it for a separate session, or use a prototype and watch what they do.
- Asking about the future. “Would you use it?” and “Would you pay?” produce promises, not facts.
- Leading questions. “That's hard, isn't it?” already contains the answer. Ask “what is easy and what is hard”.
- Talking more than listening. Explaining the product, correcting the user, or teaching them the right way to use it during the session.
- Only meeting people who are easy to book. Friends and fans give the most pleasant answers, not necessarily the most honest ones.
- Recording without permission, or putting notes with personal data into AI tools without a policy that allows it.
- Treating one strong story as the conclusion. A great storyteller is still one person. Count people, not how memorable the story was.
Summary
- Users are polite and poor at predicting their own future, so “would you use it?” easily produces a meaningless “yes”.
- Ask about the last time something happened, dig deeper using the person's own words, do not suggest answers, and do not pitch your idea.
- Recruit people who did the task recently, ask before recording, refer to participants by code, and keep personal data out of AI tools unless a policy allows it.
- Keep facts and interpretations apart, then group them and count the people behind each pattern before concluding.
I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.
Frequently asked questions
What should I ask in a user interview?
Ask about specific times something happened, for example “When was the last time you did this, and how did you do it?”. Avoid asking for opinions on your idea, asking what people will do in the future, and questions that suggest the answer.
What is a leading question?
A question that contains or implies the answer the interviewer hopes for, such as “That's really hard, isn't it?”. A more neutral version is “What is easy and what is hard when you do this?”.
How many users should I interview?
There is no fixed number for interviews. The often-quoted 5 users comes from NN/g guidance on usability testing, not interviews. One approach is to start with a few people from the right group and stop when new sessions no longer teach you anything new.
Sources to check
Related articles
- What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
- What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
- Prioritising the backlog when everything is urgent: How to choose between value vs effort, MoSCoW and RICE, separate real deadlines from felt urgency, and send stakeholders a one-page priority note.
- How to say no to your manager and stakeholders: Three ways to say no instead of a flat “no”, how to handle it when the request comes from your manager or CEO, when to escalate, with a sample dialogue and messages for each level.