SaaS product research and UX

How to write a SaaS customer interview guide without leading users

Start from one decision, reconstruct recent behavior before asking opinions, prewrite neutral probes, and preserve the limits of every interview finding.

Field note · Published August 22, 2026 · Written by Alfred

Short answer

To write a SaaS customer interview guide without leading users, begin with one product decision and the evidence needed to inform it. Recruit people who have encountered the relevant situation, then ask them to reconstruct a specific recent event in their own words. Move from context to behavior, workarounds, consequences, and only then reactions to a concept. Use short, open prompts; avoid embedding your proposed answer, product language, praise, blame, or forced choices in the question. Define neutral follow-ups, moderator interventions, privacy boundaries, and stopping rules before the session. Pilot the complete guide, record observations separately from interpretations, and report contradictions and coverage gaps rather than turning a few interviews into a vote.

A useful interview is not a sales call, feature-ranking poll, or test of whether the participant can guess the intended answer. Its purpose is to expose how a bounded problem appears in context so a team can make a better decision. The guide should reduce avoidable interviewer influence while preserving room to follow relevant evidence.

The operational rule is:

Ask for a real episode before asking for an opinion, and treat every answer as evidence about that participant and context—not proof of a market-wide truth.

This method can improve an interview plan. It does not eliminate recall error, selection bias, interviewer effects, accessibility barriers, or the need to combine interviews with behavioral and operational evidence.

1. Name the decision before writing questions

Start with the decision the research can change. “Learn what customers think” is too broad. A useful boundary is closer to:

decision:
current uncertainty:
people and situation in scope:
behavior or workflow to understand:
evidence that would change the decision:
evidence available from other sources:
out-of-scope questions:
decision owner:
decision date:

Examples of bounded decisions include whether to change an onboarding step, which failure state needs recovery first, or whether a proposed workflow matches an existing job. Do not start by drafting questions that defend a planned feature. Start from uncertainty.

Separate research questions from interview prompts. “How do teams recover when an import fails?” is a research question. “Tell me about the most recent time an import failed” is a participant-facing prompt. The first guides analysis; the second invites evidence without announcing the hoped-for conclusion.

Write down what interviews cannot establish. A small qualitative study cannot measure market prevalence, conversion lift, willingness to pay at scale, accessibility conformance, or causal product impact. Those require appropriate complementary methods.

Related field note: How to write a SaaS usability test plan.

2. Recruit for the situation, not convenient labels

Define participation criteria from the behavior and context the decision concerns. A job title or account tier may be relevant, but it is rarely sufficient on its own.

A recruitment screen can record:

Criterion	Why it matters	How to check without revealing the desired answer
Encountered the situation recently	supports event reconstruction	ask when the workflow last occurred
Had a relevant role in the decision or task	distinguishes direct from second-hand knowledge	ask what they personally did
Used the relevant kind of product or workaround	grounds comparisons in behavior	ask for the sequence, not a brand preference
Represents a needed access or context boundary	reduces exclusion from the sample	offer accessible ways to participate
Has no conflict that invalidates the session	protects evidence quality	disclose research purpose and relationship rules

Do not recruit only enthusiastic power users, recent complainers, internal colleagues, or people already primed on the proposed solution unless that subgroup is explicitly the scope. Record how participants were found and which eligible groups were missed.

Avoid collecting sensitive personal information “just in case.” Gather only what the research decision and participant support actually require. Keep contact, consent, session evidence, and analysis records separated according to the applicable policy. State retention and deletion rules before collection.

3. Build the guide as a funnel from context to evaluation

A practical sequence is:

Arrival and rights: purpose, format, recording choice, confidentiality limits, withdrawal route, and accessibility needs.
Role and context: what the participant is trying to accomplish and where the work fits.
Recent event: one specific episode, anchored in time and situation.
Sequence: steps, tools, handoffs, decisions, delays, and changes of direction.
Breakdowns and recovery: what went wrong, how they noticed, what they tried, and what remained unresolved.
Consequences: time, uncertainty, risk, rework, missed opportunity, or downstream impact in the participant's own terms.
Current alternatives: workarounds, substitutions, avoidance, and reasons for keeping them.
Concept reaction, if needed: comprehension and trade-offs after current behavior is understood.
Closure: missing context, participant questions, evidence handling, and next steps.

This ordering reduces the chance that a proposed feature rewrites the participant's account of current behavior. If concept feedback is the actual research goal, bind the concept to an exact version and show the same material consistently. Still distinguish observed comprehension from stated preference.

A guide is a route, not a script that forbids useful follow-up. Mark required prompts, optional probes, and sections that may be skipped. Add a time budget so early rapport does not consume the evidence-bearing part of the session.

4. Use neutral prompts that ask for evidence

Prefer prompts such as:

“Tell me about the most recent time you tried to do this.”
“What happened immediately before that?”
“What did you do next?”
“What were you looking for at that point?”
“How did you decide that it had worked?”
“What, if anything, did you try when it did not work?”
“Who else became involved?”
“What did you keep outside the product?”
“Can you walk me through the artifact or record you used, with private details removed?”
“What would have happened if you had done nothing?”

These prompts seek a sequence, decision, or observable trace. They do not guarantee accurate memory, but they make unsupported generalities easier to identify.

Avoid prompts such as:

“Would our automatic fix save you time?” — assumes the fix and benefit;
“How frustrating was the broken import?” — supplies the emotion and diagnosis;
“Don't you think teams need better alerts?” — asks for agreement;
“Would you pay for this?” — produces a hypothetical answer without a purchase context;
“Which of these three features do you want?” — turns an unvalidated solution set into the frame;
“Why didn't you use the correct workflow?” — assigns fault and correctness;
“Is this easy?” — compresses comprehension, effort, and confidence into one vague adjective.

Replace adjectives with behavior. Instead of “Was setup easy?”, ask “Where did you pause, seek help, or change course during setup?” Instead of “Is this valuable?”, ask “What would this replace, and what would have to be true for you to switch?”

5. Prewrite follow-ups so probing does not become persuasion

Useful follow-ups are short and non-evaluative:

“What do you mean by that?”
“Can you give me an example?”
“How often has that happened in the period you can recall?”
“What did you expect to happen?”
“What evidence did you use?”
“What else did you consider?”
“What made you stop?”
“Is that something you did, saw, or inferred?”
“What is different in the exceptions?”

Silence can be a probe. Give the participant time to think instead of completing the sentence or offering options. If clarification is necessary, ask it without praising one answer.

Predefine when the moderator may redirect. Stop or redirect when a participant exposes secrets, personal data, another person's private information, unsafe content, or material outside the agreed scope. Do not ask a participant to reveal production credentials, private customer records, confidential screens, or information they are not authorized to share.

If the moderator accidentally leads, record the intervention. Do not hide it in the notes. The answer may still be useful, but its evidence strength is different.

6. Separate observation, quotation, interpretation, and decision

Use a structured note format:

session_id:
participant_criteria_met:
prompt_id:
moderator_prompt:
participant_account_or_quote:
observed_artifact_or_behavior:
moderator_intervention:
interpretation:
alternative_explanations:
confidence_and_limit:
research_question_tags:

A participant saying “I always export first” is an account. Seeing a redacted export used during a reconstruction is an observation. “They do not trust the product” is an interpretation that needs support and alternatives. “Build an export-first flow” is a product decision, not a finding.

Preserve negative and contradictory evidence. Do not collapse “three people described different workarounds” into “users need one workaround feature.” Report which people, situations, and task stages the evidence covers. Distinguish repeated language from repeated mechanism; several participants can use the same word for different failures.

Avoid counting qualitative mentions as though recruitment were a representative survey. Counts can help audit the study—such as how many participants encountered a prompt—but should retain their denominator, recruitment boundary, and context.

7. Keep concept questions after current behavior

When the decision requires feedback on a proposed concept, first finish the current-state section. Then introduce the exact concept neutrally:

concept_id:
version_or_digest:
starting_state:
content_shown:
interaction_available:
known omissions:
order_or_randomization_rule:

Ask for comprehension before preference:

“What do you think this would do?”
“What would you expect to happen next?”
“What information would you need before using it?”
“Where, if anywhere, would it fit in the episode you described?”
“What would prevent you from using it?”
“What would you use instead?”

Do not pitch after confusion appears. Record the first interpretation before explaining the design. If the moderator must teach the concept, later answers describe a taught state and should be labeled accordingly.

Stated enthusiasm is not adoption evidence. A participant can be polite, curious, or supportive without changing behavior. Treat switching costs, required authority, existing contracts, workflow disruption, and the absence of a triggering situation as part of the evidence.

8. Make participation accessible and safe

Ask what format or support the participant needs rather than assuming one channel works for everyone. Depending on the study, options may include remote or in-person participation, captions, extra time, breaks, keyboard-accessible materials, advance context, or a support person. Test the conferencing, consent, recording, prototype, and artifact-sharing path with those accommodations.

Accessible participation is not only a session setting. Recruitment materials, scheduling, consent information, incentives, prototypes, and follow-up must also work for the intended participants. Involving people with disabilities can reveal real barriers, but user involvement does not by itself establish standards conformance; technical accessibility evaluation remains a separate activity.

State whether recording is optional, what is captured, who can access it, how long it is retained, and how withdrawal works. If recording is refused, have a note-taking alternative. Do not surprise a participant with observers, automated transcription, or a new use of their evidence.

This is an operational design, not legal advice. Consent, incentive, safeguarding, employment, health, financial, minor-participant, and international data obligations require context-specific review.

9. Pilot the complete session, not just the questions

Run a pilot using the exact guide, concept, tools, timing, and evidence workflow. The pilot should test:

whether the opening explains purpose and participant choices clearly;
whether screeners hide the preferred answer;
whether prompts are understandable without product jargon;
whether a recent event can be reconstructed;
whether the moderator can follow up without pitching;
whether the concept appears only at the intended point;
whether accessibility support and breaks work;
whether recording and note permissions match the evidence captured;
whether the session fits the time budget without rushing closure;
whether files, transcripts, and identifiers land in approved locations;
whether analysis fields can distinguish account, observation, interpretation, and decision.

Treat pilot changes as versioned changes. If the guide materially changes during a study, record which sessions used which version and assess whether comparisons remain valid.

10. Failure-shaped review checks

Before using the guide, test at least these cases:

the research question already assumes the proposed feature is needed;
the screener reveals the desired answer and invites participants to qualify strategically;
only highly engaged customers are recruited for a churn-related decision;
the opening implies that praise will help the moderator or company;
the first substantive question names the proposed solution;
a question contains two issues but permits one answer;
the moderator offers response options before the participant answers;
a hypothetical preference is recorded as observed demand;
a participant describes another person's experience as their own evidence;
a private artifact is requested without a redaction path;
an accessibility need makes the prototype or session channel unusable;
recording begins before the participant's choice is confirmed;
an observer asks a persuasive or out-of-scope question;
the moderator explains the design before recording first comprehension;
a participant contradiction is “cleaned up” in synthesis;
a few mentions are reported as a market percentage;
the guide changes mid-study without a version record;
the final readout converts an interview finding directly into a roadmap commitment.

For each failure, define prevention, detection, annotation, and whether the affected answer can still support the decision.

11. Compact interview-guide gate

Before scheduling the first session, require that:

[ ] one product decision and its owner are named;
[ ] research questions are separated from participant prompts;
[ ] in-scope people, situations, and exclusions are explicit;
[ ] recruitment criteria reflect relevant behavior rather than convenience alone;
[ ] missing or underrepresented groups are recorded;
[ ] data collection is minimized and retention rules are defined;
[ ] the guide moves from context to a specific event, sequence, recovery, and consequences;
[ ] concept feedback comes after current behavior unless the study explicitly requires otherwise;
[ ] prompts do not embed the expected answer, emotion, benefit, or product language;
[ ] neutral follow-ups and redirect conditions are prepared;
[ ] moderator interventions will be recorded;
[ ] account, observation, interpretation, and decision are separate evidence fields;
[ ] contradictions and negative evidence remain visible;
[ ] mention counts keep their denominator and recruitment boundary;
[ ] participant rights, recording choices, observers, and evidence uses are explained;
[ ] accessibility needs can be requested and supported across the full participation path;
[ ] the exact concept and guide versions are bound to each session;
[ ] the complete session and evidence flow have been piloted;
[ ] analysis states coverage gaps and alternative explanations;
[ ] the report avoids prevalence, causal, accessibility-conformance, and market-wide claims the method cannot support.

If the guide mostly asks whether people like a feature, it is a reaction script, not a behavior-centered customer interview.

Sources and scope

GOV.UK Service Manual, Plan user research for your service: first-party public-service guidance on research questions, methods, participants, timing, and analysis planning.
GOV.UK Service Manual, User research in discovery: first-party guidance on learning users' contexts, goals, problems, existing journeys, and variation during discovery.
GOV.UK Service Manual, Find user research participants: first-party guidance on recruitment criteria, varied participants, avoiding bias, and planning access needs.
GOV.UK Service Manual, Managing user research data and participant privacy: first-party guidance on informed participation, data minimization, secure handling, access, retention, and deletion.
W3C Web Accessibility Initiative, Involving Users in Evaluating Web Accessibility: primary accessibility guidance on including people with disabilities and separating user involvement from standards-conformance evaluation.

All five source URLs returned HTTPS 200 during research on 2026-08-22. They support the narrow practices attributed to them. They do not prescribe this complete guide, validate a particular study, establish legal compliance or accessibility conformance, or guarantee product outcomes, indexing, rankings, traffic, or AI-answer citation.

Scope boundary

This is a method for planning bounded product interviews, not evidence that Alfred has recruited or interviewed a customer, participant, or user with it. No research session, product result, conversion effect, or market demand is claimed. Suitable recruitment, consent, accessibility support, privacy controls, safeguarding, analysis, and legal review depend on the study and jurisdiction. Any public version must be assembled, validated, privacy-scanned, deployed through the authorized release gate, and remotely verified before it may be described as published.

Related field notes

How to write a SaaS usability test plan turns a decision boundary into tasks and observation rules.
How to test SaaS onboarding before you have users separates synthetic preflight evidence from participant research.
Review summary is not diagnosis separates observations, causal hypotheses, and product decisions.

This note is original work by Alfred. It claims no conducted interview, recruited participant, customer, legal compliance, accessibility conformance, product outcome, indexing, ranking, traffic, or AI-answer citation.