User Interview Questions That Reveal Real Needs

A useful user interview reconstructs what someone did, not what they imagine they might buy. If your team needs to understand why customers abandon a reporting workflow, asking whether they want a better dashboard will produce agreement without explaining the failure. Start with a specific decision and work backward toward experiences that could inform it.

Define the decision before drafting questions

Write a research question that contains uncertainty: what prevents occasional account managers from sharing monthly results? Separate that from the interview questions participants will hear. Your research question is an analytical objective, not a script to read aloud.

Use the word counter to compare versions of your introduction and prompts. Paste the script, remove unnecessary clauses, and check its length before rehearsing it aloud. A shorter prompt is easier to understand, but word count does not tell you whether a question is neutral.

Choose two or three decisions the study might change. For example, you might reconsider export formats, approval requirements, or sharing permissions. Record what evidence would challenge each current assumption. This prevents confirmation bias from quietly turning the session into a product demonstration.

Recruit around recent experience

Screen for people who performed the relevant task recently enough to recall details. For a monthly reporting workflow, the previous reporting cycle is more useful than an arbitrary requirement that everyone used the product yesterday. Include people who use alternatives or stopped using your service when their experience addresses the decision.

Ask behavioral screening questions before revealing your preferred answers. Instead of asking whether reporting is frustrating, ask when the person last prepared a report, who received it, and what tools were involved. Exclude colleagues who know the intended solution unless internal employees are genuinely the target population.

Plan a modest first round that covers important differences rather than claiming statistical representation. Six interviews with identical job contexts will not explain differences between administrators and occasional contributors. Create a recruitment matrix with role, task frequency, organization constraints, and relevant access needs.

Before scheduling, explain compensation, recording, observers, and data handling. Collect only information you need. The GOV.UK user research guidance provides a useful foundation for planning ethical research. Agree on retention and deletion arrangements with your organization rather than inventing promises you cannot keep.

Build a behavioral discussion guide

Organize a forty-five-minute session into an introduction, context, one detailed recent example, follow-up exploration, and a closing check. Treat those timings as a rehearsal plan rather than a rigid timetable. The richest evidence often comes from following an unexpected handoff.

Open the main discussion with a recent event: “Tell me about the last time you shared monthly results.” Follow the participant's sequence before asking for interpretations. Where did the data come from? What happened next? Who checked it? What made the person stop or switch tools?

Prefer these transformations when editing your guide:

• Replace “Would automatic exports help?” with “How did you get the results into the format you needed?”
• Replace “Was the dashboard confusing?” with “What were you looking for at that point?”
• Replace “Do you always verify totals?” with “How did you check that particular report?”
• Replace “What features do you need?” with “What could you not finish using your usual approach?”

Ask permission before requesting artifacts. A redacted spreadsheet or a recreated message can clarify the workflow without exposing customer information. Do not pressure participants to open production records. Nielsen Norman Group's interview guide explains why interviews reveal attitudes and reported behavior, not direct proof of actual interaction success.

Moderate without selling the solution

Tell participants that the product, not the person, is being evaluated. Make it clear they can skip questions. If stakeholders observe, introduce them and agree that follow-up questions will come through the moderator rather than interrupting the story.

Use neutral follow-ups such as “What happened then?” and “Can you give me an example?” Silence can help someone remember, but avoid stretching it into pressure. Reflect what you heard without adding an interpretation: “You sent the file to finance before the client received it.” Then ask whether you understood correctly.

Keep requests for opinions separate from accounts of events. “I would probably use that” is a hypothesis about future behavior. It is not equivalent to a participant describing a workaround they used three times last month. Mark these evidence types differently in your notes.

If a participant asks whether an upcoming feature will solve their problem, acknowledge the question and return to the current process. Save any permitted product discussion for the end. Use the UX research collection to connect interview findings with later evaluative methods rather than forcing one interview to answer every question.

Turn stories into decision evidence

Debrief promptly. For each important observation, capture the participant code, context, reported action, consequence, and uncertainty. Keep observation and interpretation separate. “Copied totals into a slide” is an observation; “needs presentation integration” is one possible interpretation.

Group evidence by task or obstacle, not merely by question number. Look for negative cases: perhaps direct sharing worked well for teams without approval gates. Differences can identify the real constraint more effectively than a majority theme.

Use traceable findings with anonymized evidence references. A useful finding says that reviewers need to inspect figures before external sharing, explains the consequence of skipping that step, and identifies which contexts support the claim. Avoid turning small qualitative samples into market percentages.

Bring the team two or three implications and the next uncertainty to test. Interview evidence might justify a prototype, while a usability test determines whether people can operate it. Keep execution choices in your broader design workflow, and use the GOV.UK analysis guidance for a practical synthesis process. Store sensitive source material separately from widely shared summaries.

Key takeaways

• Start with a decision and explicit assumptions, not a feature pitch.
• Recruit people with relevant, recent experience.
• Ask for events, sequences, artifacts, and consequences.
• Separate observed evidence from reported expectations.
• Preserve contradictory cases and connect findings to the next test.