User Interview Questions: Get Useful Evidence Without Leading the Participant

Useful user interview questions invite participants to describe recent behavior, context and tradeoffs without revealing the answer the researcher hopes to hear. The goal is evidence that can challenge a product assumption, not a collection of compliments.

This guide focuses on asking and probing. It differs from the UX research repository, which explains how to organize findings after research material exists.

Begin with a research decision

Before writing questions, name the decision the interview should inform. For example: “Understand how operations teams currently recover missing meeting actions so we can decide whether this problem merits further discovery.”

Then list assumptions that could change that decision. Interviews are most useful when evidence can surprise the team. “Do users like our idea?” is not a research decision because politeness and framing can easily produce a positive answer.

Recruit for relevant experience

Define participants by recent behavior or context rather than broad demographic labels. If studying expense approval, recruit people who submitted, reviewed or administered an expense recently. Set a defensible time window so memories are reasonably concrete.

Use a short screener and avoid revealing the desired answer. Collect only necessary personal information, explain how it will be used and avoid excluding people through inaccessible scheduling or interview formats. Recruitment practices may be subject to organisational, privacy and legal requirements; this guide is not a compliance determination.

Open with context and consent

Use a plain-language introduction:

Thank you for joining. We are studying how people currently [topic].
We are testing our assumptions, not testing you, and there are no right answers.
You can skip any question or stop at any time.
[If relevant: explanation of recording, access and retention.]
Before we begin, what questions do you have?

Do not bury recording permission inside general participation language. Explain it separately, and provide a genuine manual-notes option where feasible.

Ask about the most recent example

Recent examples produce more reliable detail than general opinions. Try:

• Tell me about the last time you needed to [task].
• What triggered it?
• Where were you, and what else was happening?
• What did you do first?
• What happened next?
• Which people or tools were involved?
• Where did you pause or change direction?
• How did you know you were finished?

If the participant speaks generally, ask for one specific occasion. Do not correct their terminology or map their story to product features while they are speaking.

Probe decisions and tradeoffs

Behavior becomes useful when you understand why the participant chose one path over another:

• What options did you consider?
• Why did you choose that one at the time?
• What did you give up or delay?
• What information did you need?
• Who else influenced the decision?
• What would have made another option preferable?
• Was that typical or unusual?

“Why?” can sound accusatory when repeated. Alternatives such as “What led to that choice?” or “What was important then?” often invite richer context.

Explore workarounds and failures neutrally

Workarounds signal unmet needs, but not every workaround deserves a product. Ask:

• When the normal process fails, what do you do?
• What have you created or adapted yourself?
• Which part takes the most attention?
• What mistakes are difficult to recover from?
• When do you decide the task is not worth completing?
• Can you show the artifact or steps, with sensitive information removed?

Avoid loaded wording such as “How frustrating is this broken process?” It presumes both emotion and failure. Ask what happened and let the participant evaluate it.

Ask about outcomes, not feature wishes

When a participant requests a feature, explore the job beneath it:

• What would that enable you to do?
• When did you last need that outcome?
• How do you achieve it today?
• What is inadequate about the current path?
• Who benefits if this improves?
• How would you recognize a useful result?

Do not treat a feature request as a commitment to use or buy. Stated preference is evidence of a perspective, not proof of future behavior or market demand.

Replace leading questions with neutral versions

Also avoid double questions. “How did you find and share the file?” should become two questions so the participant can describe each step.

Use a copyable 45-minute interview script

USER INTERVIEW — 45 MINUTES

Research decision:
Participant relevance:
Interviewer:
Note owner:

1. Introduction, rights and consent — 5 min
2. Role and relevant context — 5 min
3. Most recent example — 12 min
4. Decisions, tools and workarounds — 10 min
5. Outcome and unmet needs — 7 min
6. Participant questions and close — 6 min

Core questions:
1.
2.
3.

Optional probes:
- What happened next?
- Can you give me an example?
- What made that important?
- Was anything different that time?

Researcher assumptions to watch:

The script is a research aid, not proof of ethical, legal, accessibility, safeguarding or professional sufficiency. Adapt it with qualified oversight where the topic or population requires it.

Record only what participants agreed to

For an in-person interview, a recording can preserve exact language and reduce split attention when the participant has explicitly agreed. Explain purpose, access, retention, withdrawal handling and any downstream tools before starting. Stop when asked and avoid collecting unnecessary sensitive material.

Need a reviewable source for an agreed in-person user interview? Kuno supports visible conversation capture and draft notes that researchers can verify against the source. Explore Kuno

Recording is not mandatory for good research. A trained note-taker and participant-approved recap may be more appropriate.

Debrief before memory becomes interpretation

Immediately after the session, separate four layers:

Observed behavior or event:
Participant statement:
Researcher interpretation:
Question for future sessions:

Mark exact quotations and verify them against the authorized source. Do not “clean up” a quote until it changes meaning. The objective summary guide helps preserve evidence while reducing noise.

Assign any promised participant follow-up to a named owner and date. The meeting follow-up guide provides a simple way to close agreed actions without adding research interpretation to the participant communication.

Synthesize patterns without erasing disagreement

Group evidence by research question, behavior and context. Track counterexamples and participants for whom the pattern does not apply. A small qualitative sample can reveal mechanisms and language, but it should not be reported as a population statistic.

Use note taking and outlining to structure raw material after capture. Connect each finding to source evidence, confidence and product implication. Keep personally identifying details out of broad insight summaries unless genuinely necessary and authorized.

Improve the guide after each interview

After every session, remove questions that produced rehearsed generalities, revise wording that confused participants and add probes for unexplored evidence. Do not change the core question merely to make answers more favorable.

Track interviewer effects as well: interruptions, excessive explanation, approving reactions and product advocacy. The strongest guide is not the longest one. It creates enough consistency to compare evidence while leaving room for the participant’s reality to change the researcher’s mind.

Preserve the participant’s meaning, then verify the interpretation. Kuno can support consented in-room capture, while researchers remain responsible for fair questioning, privacy and every finding. See Kuno