How to Conduct User Interviews That Reveal Real Insights

TL;DR: What You Will Learn

• Recruit the right people, not just whoever is easy to reach
• Ask neutral, open questions about past behaviour, not future intentions
• Spot and avoid your own biases before they contaminate the answers
• Run the session well so people feel safe enough to be honest
• Synthesise findings into patterns your team can act on

Get these five things right, and your next round of interviews will give you evidence, not just opinions.

Why User Interviews Beat Guesswork in Product Decisions

When I sit with a product team and ask why users abandoned a checkout flow, someone usually pulls up a dashboard and points to a drop-off between step two and step three. That number tells us where people leave, but it never tells us why.

That gap is exactly why learning how to conduct user interviews is one of the highest-leverage skills a product person in Singapore can build.

What Interviews Uncover That Dashboards Miss

Analytics show you behaviour at scale. They cannot show you the reasoning, the hesitation, or the workaround a user invented because your feature confused them.

A GovTech team validating a new app flow, say a Singpass-linked service, might see high completion rates in testing. Sit five real users down, though, and you hear one say she assumed the “confirm” button would charge her, so she closed the app and phoned a hotline instead.

That mental model, the belief that confirming means paying, never appears in any funnel chart. It only surfaces when you ask and listen.

Interviews reveal three things quantitative data structurally cannot: the why behind a behaviour, unmet needs people have not thought to articulate, and the mental models users bring to your product. This is the raw material of user-centred design, and it is why understanding the difference between UI and UX matters, because a polished interface built on wrong assumptions is still a poor experience.

When to Interview Versus Survey

I get asked this constantly, so here is the simple rule I use.

Reach for a survey when you already know the questions and need breadth, for example, measuring how satisfied a thousand users are with a redesign. Reach for an interview when you do not yet know the right questions and need depth.

• Interview when you are exploring a problem, testing an assumption, or trying to understand motivation.
• Survey when you want to quantify something you already understand.
• Analytics when you need to know what is happening at scale, before deciding what to investigate deeper.

The three work together. Analytics flag a problem, interviews explain it, surveys confirm how widespread it is.

How Insights De-Risk Roadmap Bets

Rework is expensive, and it is far more expensive after launch than before. Six interviews run before a line of code is written cost a few afternoons. The same problem caught after launch costs engineering sprints, support tickets, and eroded trust, and by then the flow is already in customers’ hands.

Every roadmap decision is a bet. Interviews let you place those bets with evidence about real user needs instead of stakeholder opinion, and that foundation is what the rest of this guide will help you build.

Recruiting the Right Participants for Honest Feedback

The fastest way to ruin a set of user interviews is to talk to the wrong people. When I first learned how to conduct user interviews, I made the classic mistake of interviewing colleagues and friends who happened to be free, then wondered why the feedback felt so polite and so useless.

Convenience sampling feels efficient, but it quietly skews everything. Your friends want to be nice, your colleagues already understand your product, and neither group behaves like a real customer deciding whether to trust their money with you.

Take a realistic case. Say you run an e-commerce SME selling home fragrances, with most of your sales coming through Shopee and Lazada. Your goal is to understand why shoppers abandon their carts, so you need actual marketplace buyers, not people who have never used those platforms.

Writing a Screener to Filter the Right Users

A screener survey is a short questionnaire that filters a broad pool down to people who genuinely match your target user. For the fragrance shop, I would screen for people who have bought something on Shopee or Lazada in the last month, and I would exclude anyone who works in marketing or e-commerce so their answers are not overly analytical.

Keep your screening criteria specific and behaviour-based. Ask what people have actually done, not what they think they might do, because past behaviour predicts future behaviour far better than good intentions.

I usually include a few quiet disqualifiers so people cannot game their way in. For example, mixing in a fake brand name among real marketplace options quickly reveals anyone clicking through just to grab the incentive.

How Many Interviews are Enough

Qualitative work does not need a large sample, but the numbers you hear thrown around deserve a source. The most-cited primary study on interview saturation is Guest, Bunce, and Johnson’s How Many Interviews Are Enough? Field Methods 2006. Working from sixty in-depth interviews, they found the basic elements of core themes for a fairly homogeneous group emerged as early as the first six interviews, and that saturation the point where new interviews stop surfacing new themes arrived by around twelve.

So when I say five to eight interviews per distinct user group, I mean the range where patterns start to repeat, and you get your first real read, not a hard stop. Plan for five to eight, then keep going until you genuinely stop hearing anything new.

It is worth separating this from a figure people often confuse it with. Jakob Nielsen’s well-known “five users” guidance from the Nielsen Norman Group 2000 is about usability testing, ng watching people attempt tasks – where five users expose roughly 85% of usability problems in one homogeneous group. Interviews and usability tests are different instruments answering different questions, so borrow Nielsen’s five for task testing and treat Guest et al.’s twelve as your ceiling when interviewing for depth.

Both sources agree on the caveat that matters most: these numbers only hold for a reasonably similar group. If you serve very different segments, say frequent buyers versus first-timers, treat each as its own group and recruit a fresh set for each rather than lumping everyone together; and if a segment is genuinely diverse, expect to need more. The insights you gather here also feed directly into wider marketing decisions, including building a content marketing strategy that speaks to real buyer language.

Ethical Incentives and PDPA-Compliant Consent

Offer a fair incentive that respects people’s time, such as a modest voucher, without making it so large that people fake their answers to qualify. A GrabFood or shopping voucher for a 45-minute session is reasonable in the Singapore context.

Because you are collecting names, contact numbers, and email addresses, the Personal Data Protection Act (PDPA), administered by Singapore’s Personal Data Protection Commission, applies. You must obtain clear, informed consent before storing anyone’s details, and only use that data for the interview purpose you stated.

Practically, I do three things to stay compliant and ethical:

• State clearly in the screener what you will collect, why, and how long you will keep it.
• Get explicit opt-in consent for both participation and recording.
• Store contact details securely and delete them once the project is done.

Treat participants with the same care you would want as a customer, and you will earn the honest, unguarded feedback that makes the whole effort worthwhile.

Writing Interview Questions That Do Not Lead the Answer

The single biggest mistake I see when people learn how to conduct user interviews is writing questions that quietly beg for the answer they already want to hear. Your job in the room is to listen, not to confirm the assumptions your team walked in with.

Let me show you what that looks like in practice, using a Singapore banking app as our running example.

Open Versus Closed and Leading Questions

A leading question smuggles in your opinion. Ask “Don’t you find this checkout confusing?” and most polite Singaporeans will nod along, because you have told them what you expect.

A closed question, like “Did you like the transfer screen?”, earns you a yes or no and nothing underneath it. You leave with a data point but no story.

Open, neutral questions do the opposite. They hand control to the person and let them fill the silence with their real experience.

Here are a few rewrites I use when coaching teams building banking flows:

• Before: “Isn’t the PayNow feature really convenient?” After: “Tell me about the last time you sent money to someone through the app.”
• Before: “Would you use a savings goals feature?” After: “How do you currently keep track of money you are trying to set aside?”
• Before: “Was the login process easy?” After: “Walk me through what happens from the moment you open the app to when you see your balance.”

Notice that each rewritten version removes the adjective doing the persuading, and it asks the person to describe rather than to agree.

Grounding Questions in Real Past Behaviour

The most reliable questions are anchored in something that actually happened, not in a hypothetical future. This is the core discipline behind Rob Fitzpatrick’s The Mom Test (2013). One of his central rules for customer conversations is to steer people toward concrete things they actually did, rather than their predictions or opinions about the future. Enthusiasm for an imagined future, he argues, tells you almost nothing, because people are consistently rosier about a hypothetical than about their real behaviour.

If you ask “Would you pay for instant overseas transfers?”, people will happily imagine a version of themselves who does. Ask instead “When did you last need to send money overseas, and what did you do?” and you get the messy truth: they used another app, or they called a relative, or they gave up.

I once sat in on interviews for a local bank’s remittance flow where every participant said they wanted lower fees. Only when we asked them to recount their last transfer did we discover the real blocker was uncertainty over when the money would arrive, not the fee at all.

Past behaviour is stubborn and specific. Hypotheticals are polite fiction.

Structuring a Discussion Guide with Warm-Up, Core, and Wrap-Up

A good discussion guide gives you a spine to follow while still leaving room to chase interesting threads.

Start with a warm-up: easy, non-threatening questions like “How long have you banked with them?” or “How often do you open the app in a typical week?” These build rapport and get people talking in their own words.

Move into the core, where you dig into the behaviours you came to understand, one topic at a time, always circling back to “tell me about the last time”.

Close with a wrap-up: “Is there anything about your banking I didn’t ask about that matters to you?” That final open door often surfaces the insight you never thought to plan for.

Write to listen, not to be agreed with, and your questions will do the heavy lifting for you.

Recognising and Removing Bias From Your Research

Here is the uncomfortable truth about learning how to conduct user interviews: the biggest threat to your findings is usually you, not your participants.

Bias creeps in quietly. You walk out of a session feeling validated, but what you actually did was steer polite people towards agreeing with an idea you had already fallen in love with.

The Biases That Corrupt Your Findings

Confirmation bias is the sneakiest. You hear the one comment that supports your product and mentally file away the three that contradict it.

Leading follow-ups do similar damage. Asking “So the checkout felt smooth, right?” tells the participant exactly which answer you want.

Then there is social desirability bias, where people tell you what makes them look good rather than what they actually do. Nobody wants to admit they never read terms of service or that they abandoned your app after two minutes.

Acquiescence bias is the tendency to agree just to keep things pleasant, which is especially strong in cultures where being agreeable is polite. And moderator influence covers everything you signal without words: nodding, smiling wider at answers you like, or leaning in when you hear something you wanted.

A Singapore Founder Who Heard What He Wanted

I once watched a founder here in Singapore run interviews for a new hawker discovery app. He was warm, chatty, and every participant liked him.

The problem was they liked him too much. When he asked, “Would you use something like this?” they nodded and said, “Yah, sounds useful,” because saying no felt rude.

He walked away convinced he had validation. Six months and a real budget later, downloads stalled because “sounds useful” is not “I would pay for this” or “I opened it this week.”

The flaw was never the idea alone. It was that acquiescence and confirmation bias combined to manufacture insight that did not exist.

Practical Habits to Stay Honest Mid-Session

The good news is that a handful of self-check habits will catch most of this in real time.

• Count to five in silence after an answer. People fill the gap with the honest detail they were about to hold back.
• Ask about the last time, not the hypothetical: “Tell me about the last time you looked for supper” beats “Would you use an app for this?”
• Keep your face neutral and your prompts neutral: “Tell me more” and “What happened next?” instead of “That’s great, right?”
• Notice when you feel pleased, and treat that feeling as a warning to probe harder, not a reason to move on.
• Watch for your own nodding. If your head is bobbing along, you are coaching the answer.

Reliable research is built on the same foundation as reliable content: credibility earned through honesty, which is worth understanding through how Google evaluates trust and E-E-A-T.

The whole point of an interview is to surface what is real, not to collect applause. If you leave a session feeling only validated, you probably interviewed your own assumptions.

Running the Session So People Open Up

Once your discussion guide is ready, the real skill of learning how to conduct user interviews shows up in the room. A comfortable participant gives you richer, more candid answers, and that comfort is something you actively create, not something you hope for.

Setting the tone and easing nerves

Most people arrive slightly nervous, worried they will give the “wrong” answer. Your first job is to remove that fear.

I always open by explaining that there are no right or wrong answers, and that I am testing the product, never them. Then I ask an easy warm-up question, like how their day is going or how they usually shop, before touching anything serious.

Body language matters even over video. Lean in slightly, nod, keep your face open, and avoid glancing at your notes while they speak.

Silence is your most underused tool. When someone finishes a thought, resist the urge to fill the gap. Count to three in your head, and often they will keep talking and reveal the honest bit they were holding back.

The Art of the Follow-Up Probe

The magic of a good interview is in the follow-up, not the scripted question. Probing digs deeper without pushing people towards the answer you secretly want a technique Steve Portigal breaks down in depth in Interviewing Users (2nd ed., 2023)

The trap is leading. If you ask “So the checkout was confusing, right?” you have handed them your conclusion. Instead, ask “Walk me through what happened at that step” or simply “Tell me more about that.”

Here are probes I lean on constantly:

• “What were you expecting to happen there?”
• “Why did you decide to do it that way?”
• “How did that make you feel?”
• “Can you give me an example of when that happened?”

Notice these are neutral. They open a door without pointing at a particular room. If you are preparing for a research role, the same neutral questioning shows up in the UX designer interview questions hiring managers ask, so this practice pays off twice.

Watch your time too. Keep a rough eye on the clock and be willing to skip a lower-priority question if a participant is giving you gold on something else.

Recording, Note-Taking, and Roles

You cannot moderate well and capture everything at once, so split the work. Picture a UX team at a Singapore retail brand running remote interviews over Zoom: one person moderates while a note-taker quietly logs quotes and timestamps in a shared doc.

Always get consent to record before you start, and be explicit about how the recording will be used and stored. Under the PDPA, treating participant data with care is not optional, so state clearly that recordings stay internal and are deleted after analysis.

Remote sessions over Zoom or Google Meet save travel time and suit busy working participants, but you lose some subtle cues, so I ask people to keep their cameras on. In-person sessions give you body language and let you observe how someone physically handles a device or an in-store display.

Whichever format you choose, brief your note-taker to stay silent unless the moderator invites a question at the end.

Capturing and Organising What You Hear

The best interview in the world is wasted if you cannot find what someone said three weeks later. So learning how to conduct user interviews properly includes learning how to capture what you hear in a clean, retrievable way.

I have seen teams walk out of a great session, jot a few bullet points from memory, then argue for days about what a user “really meant”. The fix is boring but powerful: capture the raw data faithfully first, interpret it later.

Capture the Words, Not Your Paraphrase

Record the session with permission, and take verbatim notes alongside it. When a user says “I stopped using the app because I could never tell if my payment went through”, write exactly that, not “user found payment confusing”.

Add timestamps as you go. A quick note like “18:42, payment confusion” lets you jump straight to that moment in the recording during synthesis, instead of scrubbing through an hour of audio.

You do not need expensive kit. A phone voice memo, a shared Google Doc for notes, and an automatic transcription tool are enough for most small teams. What matters is discipline, not tooling.

Separate Observations From Interpretations

This is the single habit that keeps analysis honest. In your notes, tag each line as either an observation (what the user said or did) or an interpretation (what your team thinks it means).

I use a simple convention: an “O:” prefix for observations and an “I:” prefix for interpretations. So you might have “O: user hovered over the ‘confirm’ button for ten seconds” and separately “I: they seem unsure the order is final”. The observation is evidence. The interpretation is a hypothesis you can still be wrong about.

A lightweight tagging system helps too. Pick a small set of tags up front, such as “onboarding”, “pricing”, “trust”, “feature request”, and “workaround”, then tag lines as you review the transcript. Six tags you actually use beat thirty you forget about.

Store it Responsibly Under PDPA

Picture a Singapore SME, say a home services booking startup, interviewing ten customers. Those recordings contain personal data, so PDPA obligations apply.

Store recordings and transcripts in an access-controlled folder, not scattered across personal laptops and WhatsApp chats. Note why you are keeping the data and for how long, and delete it once that purpose is served rather than hoarding it indefinitely.

Getting capture right means that when you sit down to synthesise, you are working from what users actually said, cleanly tagged and quickly found, instead of from what your team half remembers and quietly assumes.

Synthesising Findings Into Insights You Can Act On

You have run eight interviews, filled a notebook, and now you are staring at pages of quotes, wondering what any of it means. This is where most teams stall, so let me walk you through how I turn scattered notes into decisions people actually make.

Affinity Mapping and Finding Themes

Start by breaking your notes into individual observations, one per sticky note. An observation is simply what you saw or heard, with no interpretation: “User paused for ten seconds on the verification screen” or “Three participants asked where their documents went.”

Then cluster the notes that feel related and let themes emerge from the bottom up. Do not force categories in advance, because the point is to discover patterns you did not expect.

I once worked with a Singapore fintech team reviewing onboarding interviews. As they clustered notes on a FigJam board, a clear theme surfaced: users trusted the app but abandoned during document upload because they were not sure the upload had worked. That theme was invisible in any single interview and only appeared once the notes sat side by side.

If you want to run this collaboratively in a design tool, you can find a step-by-step Figma tutorial for beginners that covers setting up a shared board your whole team can drag notes around on.

Turning Themes Into Actionable Insights

A theme is a pattern. An insight explains why the pattern exists and what it means for the user.

Here is the distinction I always keep clear for my teams:

• Observation: What happened, factual and neutral.
• Insight: The underlying need or reason behind the pattern.
• Recommendation: The specific change you propose in response.

For the fintech team, the observation was that users abandoned the upload. The insight was that users felt anxious without confirmation that their sensitive documents had been received safely, which matters even more given how seriously Singaporeans treat data handling under the PDPA.

The recommendation followed naturally: add an explicit upload success state and a short reassurance about how documents are stored.

Not every insight deserves your next sprint. I prioritise by impact and reach, asking how many users a problem affects and how badly it blocks their goal. The upload anxiety hit nearly everyone and stopped them from completing signup, so it went straight to the top.

Sharing Findings So Stakeholders Act

An insight that lives in your notebook changes nothing. You need to present it so a product manager or head of ops nods and reprioritises the roadmap.

When the fintech team presented to stakeholders, they did not dump raw quotes. They showed the affinity map, named the three top themes, then paired each insight with a real user quote and a proposed change, ending with a redesigned onboarding flow.

That structure works because it closes the loop. Good questions produce clean observations, observations cluster into themes, themes become prioritised insights, and insights turn into product decisions your stakeholders back.

Keep your synthesis honest and traceable back to what users actually said, and you move from a pile of notes to changes the whole team can commit to with confidence.

Common Mistakes That Sabotage User Interviews

I have sat through interviews that produced pages of notes and zero usable insight. The problem was rarely the participant. It was almost always a small, avoidable mistake baked in before the first question.

Let me walk you through the ones I see most often, and the quick fix for each, so this reads as a checklist you can run before your next session.

The Screening and Scenario Mistakes

Interviewing the wrong people is the fastest way to waste a sprint. Quick fix: write a short screener and disqualify anyone who does not match your target user.

Here is a scenario I have watched play out at a Singapore startup. A small fintech team building a savings app for gig workers was in a rush, so they skipped screening and interviewed whoever their office network could reach.

Most of those people were salaried professionals with stable incomes and existing bank apps they loved. The feedback pointed the team towards features their real users, food delivery riders and freelancers with irregular pay, did not care about at all.

They built a whole sprint around that feedback, then scrapped it. A single screening question about income stability would have saved two weeks of work.

The same discipline applies when you hire for these roles, which is partly why so many portfolios fall flat, as I explain in Why Most UX Designer Job Applications Get Rejected.

The Questioning and Listening Mistakes

Hypothetical and leading questions give you fiction, not evidence. Asking “Would you use a feature that reminds you to save?” invites a polite yes. Quick fix: ask about the last real time they tried to save and what actually happened.

Talking too much is my own recurring temptation. Every second I spend explaining is a second the participant is not revealing something.

Quick fix: ask your question, then stay silent and count to five in your head. The pause almost always pulls out the richer answer.

Ignoring non-verbal cues is subtler. A rider might say a screen is “fine” while frowning and hesitating over a button.

Quick fix: notice the mismatch and gently probe it. “You paused there; what were you thinking?” often opens the most honest part of the conversation.

Here is the checklist in one glance.

The Analysis Mistake

The final trap is cherry-picking quotes to fit the story you already believe. It feels productive because it lets you close the debate, but you are just confirming your own bias.

Quick fix: tag every quote, including the ones that contradict you, and count how often each pattern appears. Let the weight of the evidence decide, not the neatest soundbite.

That bias-free, insight-first mindset is the thread running through this whole guide. Protect it at every stage and your interviews will surface truth instead of flattery.

Conclusion

When we started this article, the problem was guesswork: teams shipping features based on assumptions, then wondering why nobody used them.

The fix runs through everything we have covered. Honest recruiting gets you the right people in the room. Neutral, open questions stop you from planting the answers you hope to hear.

Bias awareness keeps you from nodding along and hearing only what confirms your roadmap. Skilled moderation lets silence do its work so users reveal what they actually feel. Rigorous synthesis turns scattered quotes into patterns your team can act on.

Do all five well and interviews stop being polite chats. They become evidence you can defend in a stakeholder meeting.

Here is my honest nudge: do not wait until you have the perfect discussion guide. This week, recruit three real users, write six open questions, and run one small round.

Maybe you run a fintech app and interview three users who abandoned your onboarding flow. Maybe you work at an SME and speak to three customers who churned. Either way, you will learn more in thirty minutes than in a month of internal debate.

Once you have felt the difference, it is worth building these skills properly rather than by trial and error.

If you want structured practice with real feedback, our UX Design Career Programme takes you through the full craft of user research, interviewing, and synthesis under the guidance of an industry mentor. It is the logical next step to turn one good interview into a repeatable habit your whole team can trust.

Ready to move from guesswork to evidence? Explore the UX Design Career Programme and start running interviews that surface what your users actually need.