TL;DR: Here are 30 AI prompts for user research and interviews, organized across four stages: writing discussion guides, probing deeper in live conversations, synthesizing transcripts, and finding themes across interviews. None of them let AI conduct the interview or invent a participant quote. Consent governs what you can paste, and a fabricated quote is the one failure this genre can't survive.
What can AI actually do for user research, and where does it stop?
User research prompts earn their keep on the parts of the job that are mostly structuring and pattern-finding: turning a research question into a discussion guide, keeping probing questions ready during a live conversation, and finding consistent structure across many transcripts. They are not useful, and should not be trusted, for the parts of the job that require a human in the room: reading a hesitation, building enough trust that someone tells you what actually happened instead of what sounds good, or deciding which contradiction in the data actually matters. The 30 prompts below all assume a person ran the interview. AI's job starts once you have real notes, a real recording, or a real transcript in front of you. That's a different starting point from our guide to AI prompts for literature review: that one works from published papers with no consent question attached, while every prompt here works from a living person who agreed to talk to you under specific terms.
Two more ground rules run through everything below. First, interview recordings and transcripts are personal data almost by definition: a voice, a name, a job title and a specific complaint is usually enough to identify someone even after you remove their name from the page. Consent is what makes pasting that material into a prompt permissible, and consent given for "analysis for this study" doesn't automatically cover "uploaded to a third-party AI vendor." If your consent form doesn't say what AI tools will touch the data, treat that gap as a no until legal or your participants say otherwise. Second, a synthetic user persona, however well built from market data, is not a stand-in for the person you interviewed. It is a hypothesis generator for what to ask next, not evidence about what real users think, and the difference between those two roles is the subject of its own section further down.
How do you write a discussion guide with AI prompts?
A discussion guide sets your questions before you're in the room, when you have the most time to think and the least pressure to improvise. These eight prompts turn a research goal into a guide you can actually run, sequenced from broad framing down to the specific behaviors you need to see evidence of.
1. Research goal to discussion guide
Use when you have a research question and need it turned into an interview-ready guide.
Role: Senior UX researcher writing a discussion guide for a moderator who
has never run this specific study before.
Context
- Research goal: [what decision this study informs]
- Participant profile: [who you're recruiting]
- Study type: [generative / evaluative, moderated / unmoderated]
- Session length: [minutes]
- Known constraints: [remote/in-person, recording policy, observers]
Task
Write a discussion guide sequenced from warm-up to close.
Rules
- Open with 2-3 minutes of low-stakes rapport questions before anything
about the actual topic. A cold start produces guarded answers.
- Move from broad ("walk me through the last time you...") to specific
("show me exactly where you clicked") — never the reverse.
- Write questions as prompts to explore, not as a script to read verbatim.
Note where the moderator should follow curiosity instead of the next line.
- Flag any question that could lead the participant toward an answer, and
rewrite it neutral.
- Do not invent participant answers or expected findings. You have none yet.
Example of the standard I want
Weak: "Don't you find the checkout process frustrating?"
Strong: "Tell me about the last time you checked out on a site like this.
What happened?"
Output
The guide with time allocations per section · 3 questions flagged as
leading, rewritten · what a good session looks like in the first 5 minutes.
2. Screener question set
Use when you need to recruit the right participants and filter out the wrong ones.
Role: Research operations specialist who writes screeners that filter out
professional survey-takers and people who'll say yes to anything.
Context
- Target participant: [who you need]
- Must exclude: [competitors' employees, people who work in research, etc.]
- Study type and length: [context for what you're screening for]
- Recruitment channel: [panel, customer list, social]
Task
Write a screener questionnaire.
Rules
- Never state the study's real topic in a screener question. Participants
learn to answer toward what a study is "about" once they guess it.
- Use behavioral questions ("how many times in the last month did you...")
instead of self-identification questions ("are you a frequent user").
People over-report the identity that sounds better.
- Include at least one question with a hidden wrong answer, to catch
someone answering carelessly for an incentive.
- Mark each question with its purpose (qualify, disqualify, quota).
Example of the standard I want
Weak: "Do you consider yourself tech-savvy?"
Strong: "Which of these have you done in the past week? [list including
one implausible option to catch inattentive responses]"
Output
The screener with purpose tags · the trap question and why it works ·
quota logic if you need a mixed sample.
3. Behavioral vs opinion question rewrite
Use when your draft guide is full of "do you like" questions and you know that's weak.
Role: Interview methodology reviewer. You convert opinion questions into
behavioral ones, because what people did predicts better than what they
say they'd do.
Context
- Draft questions: [paste your list]
- Research goal: [what you're trying to learn]
Task
Rewrite each question to ask about a specific past behavior instead of a
general opinion.
Rules
- Each rewrite anchors to a specific, recent instance ("the last time",
"yesterday when"), not a habit described in general terms.
- If a question can't be made behavioral because the behavior hasn't
happened yet, say so and suggest a proxy behavior instead.
- Keep the researcher's original intent per question; don't change what
it's trying to learn.
- Do not answer the questions yourself.
Example of the standard I want
Weak: "Do you find our search feature useful?"
Strong: "Tell me about the last time you used search here. What were you
looking for, and what happened?"
Output
Rewritten questions paired with the originals · which ones couldn't be
made behavioral, and why.
Run this on a draft guide before your pilot session, not after. It's cheaper to fix a weak question on paper than to notice it produced a shrug in the room.
4. Sensitive-topic question softening
Use when your study touches money, health, or another topic people under-report on.
Role: Qualitative researcher experienced with sensitive-topic interviews.
You know direct questions on these topics get performed answers.
Context
- Topic: [what's sensitive about it]
- Draft questions: [paste them]
- Population: [who you're asking]
Task
Soften the questions without losing what they're measuring.
Rules
- Normalize the behavior in the question stem ("many people..." /
"it's common to...") before asking about it.
- Give a way to answer in ranges or categories rather than exact figures,
where the exact figure is what people evade.
- Note which questions should move later in the guide, after rapport is
established, rather than early.
- Flag any question you can't soften without losing its value, and say why.
Example of the standard I want
Weak: "How much debt do you currently have?"
Strong: "A lot of people are juggling more than one kind of payment right
now. Which of these apply to you? [ranges, multiple select]"
Output
Softened questions · reordering suggestion · questions you couldn't fix.
5. Remote unmoderated study instructions
Use when participants complete tasks without a moderator present.
Role: Research ops specialist writing task instructions for participants
who will have no one to ask if something's unclear.
Context
- Task: [what you want them to do]
- Platform: [tool participants will use]
- Participant technical level: [assume the lowest]
Task
Write the instructions.
Rules
- One action per instruction line. A compound instruction is where
unmoderated sessions go wrong.
- Include what to do if something doesn't work as expected. A participant
with no fallback abandons the session instead of reporting the problem,
which is itself useful data.
- State explicitly what you want them to think aloud, since unmoderated
think-aloud needs prompting a moderator would otherwise supply.
- End with 2-3 debrief questions.
Example of the standard I want
Weak: "Go to the site and sign up, then let us know how it went."
Strong: "1. Open [link]. 2. Click 'Sign up'. 3. As you go, say out loud
what you expect each button to do before you click it."
Output
Numbered instructions · fallback guidance · debrief questions.
6. Stakeholder question intake
Use when multiple stakeholders each want "their" question in the guide.
Role: Research lead consolidating stakeholder requests into a guide that
still fits the session length.
Context
- Stakeholder questions: [paste the raw list]
- Session length: [minutes]
- Research goal: [what actually needs answering]
Task
Consolidate the requests into guide-ready questions.
Rules
- Group requests that are really asking the same underlying thing, and say
which stakeholder each merged question satisfies.
- Cut anything answerable from data you already have instead of an
interview, and say what data source would answer it.
- If the list doesn't fit the session length, cut by relevance to the
research goal, not by whichever stakeholder is loudest, and say what
you cut.
- Do not silently drop a stakeholder's question. Flag every cut.
Example of the standard I want
Weak: [17 questions crammed into a 30-minute guide]
Strong: "Combined 4 stakeholder questions about pricing confusion into one
guide section; cut 3 questions answerable from support tickets."
Output
Consolidated guide sections · what was merged and for whom · what was cut
and where to find that answer instead.
7. Guide translation for a non-native-speaking moderator
Use when the moderator isn't running the session in their first language.
Role: Bilingual research methodologist adapting a guide for a moderator
running sessions in [language].
Context
- Original guide: [paste it]
- Moderator's first language: [language]
- Participant's language: [language]
- Cultural notes: [directness norms, formality expectations, if known]
Task
Adapt the guide for this moderator and this participant population.
Rules
- Translate meaning, not words. A directly translated probe can read as
rude or oddly formal depending on the culture's norms.
- Flag any question that assumes a cultural context participants may not
share, and rewrite it neutral.
- Keep phrasing simple enough that the moderator can deliver it naturally,
not read it like a script.
- Note anywhere directness norms mean a participant is likely to answer
politely rather than honestly, and suggest a follow-up that gets past it.
Example of the standard I want
Weak: [word-for-word translation that reads stilted]
Strong: [natural phrasing with a note: "this population tends to answer
'it's fine' first — plan a specific behavioral follow-up"]
Output
Adapted guide · flagged cultural assumptions · phrasing coaching notes for
the moderator.
The coaching notes matter as much as the translated text. A moderator reading unfamiliar phrasing cold delivers it stiffly, and stiff delivery changes what participants are willing to say.
8. Pilot session review
Use when you ran one test session and need to fix the guide before the real ones.
Role: Research methodologist reviewing a pilot session to fix the guide,
not to draw conclusions from one participant.
Context
- Pilot transcript or notes: [paste it]
- Original guide: [paste it]
- What felt off: [your own notes, if any]
Task
Review the pilot and revise the guide.
Rules
- Flag questions the participant misunderstood, and rewrite them.
- Flag questions that produced a one-word answer with no follow-up, and
add a probe.
- Note if the session ran over or under time, and where to cut or expand.
- Do not treat this single participant's answers as a finding. This is a
guide fix, not a result.
Example of the standard I want
Weak: "The interview seemed to go fine."
Strong: "Question 4 got 'yeah, sure' with no elaboration from the pilot
participant — it's a yes/no question in disguise. Add: 'what
made you say that?'"
Output
Revised guide · what changed and why · one line confirming this is not a
finding.
How do you probe deeper during a live interview?
A good guide gets you into the room; probing is what gets you past the first, rehearsed answer. These seven prompts are meant to be prepared in advance and referenced during or immediately after a session, not run live inside the conversation itself.
9. Follow-up question bank per guide question
Use when you want probes ready before the session so you're not improvising under pressure.
Role: Interview coach preparing probes for a moderator who wants to spend
attention on the person, not on inventing the next question.
Context
- Guide question: [paste it]
- What a shallow answer sounds like: [if you can predict it]
- Research goal: [what this question serves]
Task
Write 3-4 probes for this question, ordered from least to most direct.
Rules
- The first probe should invite more without leading ("what happened
next", "tell me more about that").
- Later probes can get specific, but must not supply the answer inside
the question.
- Include one probe aimed at contradiction: what would you ask if their
answer doesn't match something they said earlier.
- Do not write probes assuming a specific answer already happened.
Example of the standard I want
Weak: "Wasn't that frustrating?"
Strong: "What was going through your mind right at that moment?"
Output
Probes ordered by directness · the contradiction probe · what each is
trying to surface.
10. Silence and hesitation handling
Use when you keep filling silences too fast and cutting off the good part.
Role: Interview coach specializing in moderator habits, not question
wording.
Context
- What you tend to do: [e.g. "I re-ask the question if there's a pause"]
- Study type: [context]
Task
Give me concrete phrases and habits for sitting with silence.
Rules
- Give phrases shorter than the participant's own pause would be, so they
don't read as an interruption disguised as encouragement.
- Distinguish "thinking" silence from "finished" silence, and how a
moderator can tell the difference in the moment.
- Address discomfort directly. Most premature interruptions come from the
moderator's discomfort, not the participant's need for help.
- Keep this actionable for use during a live session, not theory.
Example of the standard I want
Weak: "Just wait longer."
Strong: "After a pause, try a soft 'mm-hm' and count to five in your head
before saying anything else."
Output
Phrases for different pause types · the count-to-five habit · one
sentence on what usually causes early interruption.
11. De-escalating a leading answer
Use when you realize mid-session your own question led the witness.
Role: Interview methodology coach helping a moderator recover from a
leading question they've already asked.
Context
- The leading question you asked: [paste it]
- The answer you got: [paste it]
- What you still need to know: [the real research question]
Task
Give me a recovery question to ask right now.
Rules
- The recovery question must not reference or repeat the leading framing.
- It should invite the participant to re-derive their own answer rather
than confirm or deny yours.
- If the answer is now unrecoverable for this question, say so plainly
rather than pretending a rephrase fixes it.
- One recovery question, not a list. This is for use mid-session.
Example of the standard I want
Weak: "Sorry, ignore that — so was it actually easy or hard?"
Strong: "Walk me through exactly what you did, step by step, from when
you started."
Output
The recovery question · whether this data point is salvageable · what to
flag in your notes about it.
Note the honesty this prompt forces: sometimes the answer really is unrecoverable, and the right output is a note in your synthesis file, not a graceful pivot that pretends nothing happened.
12. Post-session debrief prompt
Use when the session just ended and you want your reactions recorded before you forget them.
Role: Research assistant capturing a moderator's fresh impressions right
after a session, before analysis begins.
Context
- Rough notes or memory: [whatever you can get down quickly]
- Guide used: [paste it, or reference it]
Task
Structure my raw debrief.
Rules
- Separate what the participant said from your interpretation of it, and
label each clearly. This distinction disappears fast if it isn't made now.
- Capture anything that surprised you, even if you can't yet say why.
- Note anything you'd change about the guide or your delivery for the
next session.
- This is not synthesis. Do not draw a conclusion across multiple
participants from one debrief.
Example of the standard I want
Weak: "Users don't like the settings page."
Strong: "Said (participant): 'I couldn't find where to turn that off.'
My interpretation: possibly a labeling issue, not a
users-don't-like-it issue. Check against other sessions."
Output
Said vs interpreted, split clearly · surprises · guide adjustments for
next time.
13. In-session note-taking template
Use when you need a structure to type into live without missing what matters.
Role: Research operations specialist designing a note-taking template for
live use, not after-the-fact.
Context
- Study type: [generative / evaluative]
- Guide sections: [list them]
- Number of note-takers: [1 moderator, or moderator + observer]
Task
Build a note-taking template.
Rules
- Structure by guide section, with a column for verbatim quotes and a
separate column for observations (behavior, tone, hesitation).
- Verbatim quotes must be marked as quotes only when actually typed in the
moment. A note-taker paraphrasing from memory later and presenting it as
a quote is the same fabrication risk as an AI doing it.
- Include a timestamp field if the session is recorded, so a quote can be
checked against the recording later.
- Keep it fast to fill in live. No field should take longer to complete
than the participant takes to answer.
Example of the standard I want
Weak: [free-text notes with quotes and impressions mixed together]
Strong: [table: Section | Timestamp | Verbatim | Observation]
Output
The template · why verbatim and observation are kept separate · the
timestamp rule and why it matters for later verification.
This template is the single-biggest lever for avoiding the fabricated-quote problem later, because it stops a paraphrase from ever getting typed inside quotation marks in the first place.
14. Mid-study pattern check
Use when you're partway through a study and want to know if anything needs to change before you finish.
Role: Research lead doing a mid-study check without jumping to
conclusions before the sample is complete.
Context
- Sessions completed so far: [number], out of [planned total]
- Rough notes from each: [paste summaries, labelled S1, S2, ...]
- Research goal: [paste it]
Task
Check for early patterns and guide problems.
Rules
- Distinguish "worth watching" from "confirmed". With this few sessions,
nothing should be labelled confirmed yet.
- Flag any guide question that's consistently confusing participants, so
it can be fixed before the remaining sessions run.
- Note anything suggesting your screener let in the wrong participants.
- Do not write a findings summary. This is a process check, not a result.
Example of the standard I want
Weak: "Users clearly don't understand the pricing page."
Strong: "3 of 4 sessions so far stumbled on the same guide question
(worth watching, not confirmed). Consider rewording before S5."
Output
Patterns worth watching, labelled as such · guide fixes to make now ·
screener concerns, if any.
The discipline here is refusing to call anything confirmed at session 4 of 10. That refusal is what keeps a mid-study glance from turning into a premature finding someone screenshots into a deck.
15. Interpreter-assisted session brief
Use when a session runs through a live interpreter.
Role: Research operations specialist briefing an interpreter for a
qualitative session, where tone and hesitation matter as much as words.
Context
- Study topic: [what it's about, so the interpreter isn't guessing]
- Guide: [paste it, or key sections]
- What matters beyond literal translation: [e.g. hesitation, sarcasm, idioms]
Task
Write a brief for the interpreter.
Rules
- Ask for consecutive interpretation to preserve pacing that matters for
probing, not summarized relay.
- Explicitly request that hesitation, tone shifts and non-answers be
flagged to the moderator, not smoothed into a clean translated sentence.
- Give the interpreter the guide in advance so they're not translating cold.
- Note any terms that don't translate cleanly and how to handle them.
Example of the standard I want
Weak: "Please translate what the participant says."
Strong: "Interpret consecutively, sentence by sentence. If the participant
hesitates or seems to avoid a direct answer, say so to me even if
you also give the literal translation."
Output
The interpreter brief · terms flagged for handling · a note on what
'flagging hesitation' looks like in practice for this interpreter.
How do you synthesize interview transcripts without inventing data?
This is where the consent and fabrication rules matter most, because this is the stage where pasted text turns into AI output. Every prompt here treats the transcript as the only source of truth: the model extracts and structures what's actually there, and a person verifies.
16. Structured session summary from a transcript
Use when you have a full transcript and need it turned into a usable summary.
Role: Research analyst extracting structure from a transcript. You
transcribe what's there; you do not interpret or improve it.
Context
- Transcript: [paste it, names removed]
- Research goal: [what this session serves]
- Fields I need: [e.g. goals, pain points, workarounds, direct quotes]
Task
Extract a structured summary in the fields listed.
Rules
- Every field must trace to a specific point in the transcript. If it's
not there, write "not discussed" rather than inferring it.
- Quotes must be copied exactly from the transcript, with a location
marker (timestamp or line). A paraphrase presented as a quote is the
same failure as a quote the participant never said.
- Keep the participant's own words for pain points rather than upgrading
them into your terminology. "Kind of annoying" is not "a major
frustration."
- Note anything unclear in the transcript rather than resolving the
ambiguity yourself.
Example of the standard I want
Weak: "The user found the process frustrating."
Strong: "[14:32] 'It's not that hard, it's just that I never know if it
actually saved.' — uncertainty about save state, not difficulty."
Output
The fields as a labelled summary, "not discussed" where applicable, and a
list of anything ambiguous in the source.
The rule against upgrading a participant's own wording is the one writers skip most often, because a stronger word makes a tidier summary. It also makes a summary that no longer matches the recording.
17. Verbatim quote extraction for a report
Use when you're building a report and need quotes you can defend if challenged.
Role: Qualitative analyst pulling quotes for a report. Fidelity to the
transcript is the entire job here.
Context
- Transcript: [paste it]
- Themes or points you're illustrating: [list them]
Task
Pull supporting quotes for each theme.
Rules
- Verbatim only, character for character, including filler words and false
starts. Cleaning a quote for readability changes what it proves.
- Give the location (timestamp or line) for every quote, so it can be
checked against the recording.
- If a quote needs context to be read fairly, add that context in
brackets rather than extending the quotation marks around it.
- If no quote in the transcript supports a theme you listed, say so
instead of stretching a nearby one to fit.
Example of the standard I want
Weak: "I like it."
Strong: "'I mean, it's fine, I guess — I just wish it told me when it was
actually done.' [22:10]"
Output
Quotes grouped by theme with locations · themes with no supporting quote,
flagged.
Before this quote ships anywhere, check it mechanically: copy the fragment you're about to publish and confirm it's a literal, character-for-character match against your own transcript file, not a version you remember writing.
18. Contradiction flag within one transcript
Use when a participant said two things that don't quite line up.
Role: Analyst checking a single transcript for internal contradiction, not
smoothing it into a single tidy narrative.
Context
- Transcript: [paste it]
- What seemed contradictory: [if you noticed something, or "check for it"]
Task
Find and describe any contradictions within this transcript.
Rules
- Quote both sides of the contradiction with their locations.
- Consider whether it's a real contradiction or the participant changing
their mind mid-conversation, which is itself a finding worth noting.
- Do not resolve the contradiction by picking the answer that sounds more
useful. Report both.
- Only use this transcript. Do not compare to other sessions here.
Example of the standard I want
Weak: "The participant was inconsistent."
Strong: "[08:15] 'I check it every day.' [19:40] 'Honestly I forget it
exists most weeks.' Possibly means different things by 'check' —
worth a clarifying follow-up next session."
Output
Contradictions with both quotes and locations · plausible explanation ·
whether it needs a follow-up question in future sessions.
Reporting both sides instead of picking one is the difference between synthesis and cherry-picking, and it is exactly the discipline a rushed deadline tempts a person to skip.
19. Cross-session comparison table
Use when you have several sessions summarized and need them side by side.
Role: Research analyst building a comparison table across sessions. You
make differences visible rather than averaging them away.
Context
- Session summaries: [paste them, labelled S1, S2, ...]
- Dimensions to compare: [what you're comparing across sessions]
- Research goal: [paste it]
Task
Build the cross-session comparison table.
Rules
- Every cell traces to a specific session summary. Empty means not
discussed in that session; mark it, don't leave it blank.
- Keep each participant's own framing in their cell rather than
normalizing everyone into the same vocabulary, and note where two
participants may mean different things by the same word.
- Flag any dimension where sessions genuinely disagree, rather than
picking a majority view to report.
- Do not add participants I didn't give you.
Example of the standard I want
Weak: | S1 | Liked it | S2 | Didn't like it |
Strong: | S1 | 'saves me a step' (own words) | S2 | 'one more thing to
remember' (own words) |
Output
The table · dimensions where sessions genuinely disagree · anything not
comparable across sessions and why.
| Feature | Untraceable summary | Traceable summary |
|---|---|---|
| Claim source | "Users found it confusing" | S2 [08:15], S4 [12:40] |
| Can you check it against the recording? | ||
| Survives a stakeholder asking "which session said that?" |
20. Behavior vs stated preference gap check
Use when what a participant said and what they actually did in the session don't match.
Role: Analyst checking for gaps between stated preference and observed
behavior within a session.
Context
- Transcript and task observations: [paste both — what they said and what
you watched them do]
- Research goal: [paste it]
Task
Identify any gaps between what was said and what was done.
Rules
- Quote the stated preference and describe the observed behavior
separately before comparing them.
- Consider plausible explanations other than "the participant was lying":
task artificiality, a workaround the study didn't account for, or a
preference they hold in general but didn't apply this time.
- Do not assume behavior is always more truthful than words. Sometimes the
task setup, not the participant, is the source of the mismatch.
- Only this session's data.
Example of the standard I want
Weak: "The user said one thing and did another."
Strong: "Said: 'I always check the total before confirming.' [11:02] Did:
clicked confirm without scrolling to the total. Possibly the
claim is generally true but didn't hold under task time pressure."
Output
Gaps identified, with both sides quoted or described · plausible
explanations · what would confirm which explanation.
21. Sentiment without overclaiming
Use when you want a read on how a participant felt without turning one comment into a verdict.
Role: Analyst characterizing sentiment cautiously. Tone in a single
interview is a data point, not a measurement.
Context
- Transcript: [paste it]
- Topic: [what you're characterizing sentiment about]
Task
Characterize sentiment on this topic from this transcript.
Rules
- Describe sentiment in the participant's own terms and intensity, not a
1-5 scale invented for the occasion.
- Note where tone in a recording, if you have it, might read differently
than the transcript text alone suggests, and flag that as unverifiable
from text.
- Distinguish sentiment about the product from sentiment about their own
situation, which participants often blend.
- Do not aggregate this into a number without other sessions to average
against. One transcript is not a percentage.
Example of the standard I want
Weak: "Sentiment: 4/5, mostly positive."
Strong: "Mostly positive about the outcome, notably frustrated about one
specific step (repeated twice unprompted). Not an overall product
sentiment, a specific-step sentiment."
Output
Sentiment description in the participant's terms · what's unverifiable
from text alone · what this transcript alone can and can't support.
Refusing to invent a 1-5 score from one conversation is a small discipline that stops a single loud opinion from quietly becoming a slide titled "user sentiment."
22. Research-goal-to-findings traceability check
Use when you want to confirm your findings actually answer the question you set out to answer.
Role: Research lead checking traceability between the original goal and
the findings before they go to stakeholders.
Context
- Original research goal: [paste it]
- Draft findings: [paste them]
- Source transcripts or summaries: [reference which sessions support what]
Task
Check whether the findings trace back to the goal and the data.
Rules
- For each finding, name which sessions support it, and how many. A
finding from one session should say so explicitly.
- Flag any finding that doesn't clearly trace to the research goal. An
interesting tangent is not automatically a finding worth reporting.
- Flag any part of the original goal the findings don't address at all.
- Do not soften this check to make the findings look more complete than
they are.
Example of the standard I want
Weak: "Users want more customization options."
Strong: "Supported by 2 of 6 sessions (S3, S5); not addressed: the
original goal's second question about pricing perception."
Output
Findings with supporting session counts · findings that don't trace to
the goal · goal questions left unanswered.
23. Disagreement-aware executive summary
Use when your sessions genuinely disagreed and the summary needs to say so.
Role: Research analyst writing an executive summary that keeps
disagreement visible rather than resolving it for a tidy slide.
Context
- Session summaries: [paste them, labelled]
- Research goal: [paste it]
- Audience: [who's reading this summary]
Task
Write an executive summary.
Rules
- Report agreement and disagreement as separate sections, not blended
into an averaged conclusion.
- For disagreement, note what differed between participants (context,
need, prior experience) rather than presenting it as unexplained noise.
- Keep the summary traceable. A reader should be able to ask "which
sessions" about any claim and get an answer.
- Do not resolve a genuine split by picking the majority view as "the"
finding.
Example of the standard I want
Weak: "Overall, users want a simpler process."
Strong: "4 of 6 wanted fewer steps; 2 of 6 (both first-time users)
explicitly wanted more guidance at each step. Likely an
experience-level split worth testing separately."
Output
Agreement section · disagreement section with plausible explanations · one
line noting this needs stakeholder awareness, not a single number.
An executive summary that hides a genuine split is more damaging than a research effort that finds nothing. It tells a team to build for a "consensus" that isn't there.
How do you find themes across multiple interviews?
Thematic analysis is where individual sessions become a finding a team can act on. These seven prompts apply a consistent method across sessions you've already summarized, so the themes trace back to real sessions instead of a general impression of "what people said."
24. Open coding pass
Use when you're at the start of thematic analysis and need a first pass without premature structure.
Role: Qualitative analyst doing open coding. The goal at this stage is
capturing what's there, not organizing it neatly yet.
Context
- Session summaries or transcripts: [paste them, labelled]
- Research goal: [paste it]
Task
Generate open codes for each session.
Rules
- Codes should be short labels close to the participant's own language,
not abstract categories yet. That comes later.
- Every code must trace to a specific session and location.
- Don't collapse similar-sounding codes into one yet, even if they look
related. Premature merging at this stage loses distinctions worth
keeping.
- Only the supplied sessions.
Example of the standard I want
Weak: "Theme: Confusion"
Strong: "Code: 'unsure if action saved' — S2 [14:20], S4 [09:05]"
Output
Codes per session with locations · a flat list of all codes across
sessions, unmerged.
Resist the urge to skip straight to themes. A theme built without this messy middle step is usually a theme someone expected to find, not one the transcripts actually produced.
25. Affinity clustering of codes
Use when you have open codes and need them grouped into candidate themes.
Role: Analyst clustering codes into candidate themes, keeping the
traceability from theme back to individual codes.
Context
- Open codes: [paste the flat list, with session/location tags]
- Research goal: [paste it]
Task
Cluster the codes into candidate themes.
Rules
- Every theme lists the codes and sessions underneath it. A theme with no
listed codes is not a theme, it's a guess.
- Note codes that don't cluster cleanly anywhere, rather than forcing them
into the nearest theme.
- Flag any cluster resting on a single session as tentative.
- Name themes descriptively, not as marketing language for the finding
you'd like to have.
Example of the standard I want
Weak: "Theme: Users love simplicity"
Strong: "Theme: Uncertainty about save state (codes: 'unsure if saved',
'checks twice', 'refreshes to confirm' — S1, S2, S4)"
Output
Candidate themes with underlying codes and sessions · unclustered codes ·
themes resting on one session, flagged.
The rule about naming themes descriptively rather than aspirationally is worth enforcing on yourself as much as on the model. A theme named for the fix you want to ship stops being a finding.
26. Theme saturation check
Use when you want to know if you've interviewed enough people to trust your themes.
Role: Research methodologist assessing saturation, not just counting
sessions.
Context
- Themes so far: [paste them]
- Sessions in order completed: [list, with which themes each one added]
- Planned total sessions: [number]
Task
Assess whether themes have reached saturation.
Rules
- Check whether recent sessions are adding new themes or just confirming
existing ones. Saturation is about the second pattern appearing.
- If saturation looks reached, say at which session and why.
- If it doesn't look reached, say what kind of participant or context
might still be missing.
- Don't declare saturation from session count alone without checking what
each session actually added.
Example of the standard I want
Weak: "We've done 8 sessions, that should be enough."
Strong: "Sessions 6-8 added no new themes, only reinforced existing ones.
Saturation looks reached for this participant segment; not yet
tested with the power-user segment."
Output
Saturation assessment with reasoning · segment or context still untested,
if any.
27. Theme-to-stakeholder-question mapping
Use when you need to show which theme answers which original stakeholder question.
Role: Research lead connecting themes back to why the study was
commissioned in the first place.
Context
- Themes: [paste them, with supporting sessions]
- Original stakeholder questions: [paste them]
Task
Map themes to stakeholder questions.
Rules
- Every stakeholder question gets either a mapped theme or an explicit
"not answered by this study" note.
- A theme can map to more than one question. Say so rather than forcing a
one-to-one match.
- Flag any theme with no clear stakeholder question behind it, and note
whether it's worth reporting anyway.
- Keep the session counts attached so this stays traceable.
Example of the standard I want
Weak: "This answers the stakeholder's question."
Strong: "Stakeholder Q2 (pricing confusion): partially answered by Theme 3
(4 of 6 sessions); the 'why' behind the confusion needs further
study. This study only surfaced that it exists."
Output
Mapping table · unanswered stakeholder questions · themes without a
stakeholder question, flagged.
28. Competing-explanation theme check
Use when a theme could be explained by the product or by something else entirely.
Role: Skeptical analyst checking a theme for alternative explanations
before it goes into a report as a product finding.
Context
- Theme: [paste it, with supporting quotes and sessions]
- Study context: [recruitment method, task design, timing]
Task
Check for alternative explanations of this theme.
Rules
- Consider recruitment bias, task artificiality, timing (a bad day, a
recent incident), and the moderator's own influence as candidate
explanations, not just the product.
- Rate how well the supporting evidence rules out each alternative.
- If an alternative can't be ruled out from this study alone, say what
would rule it out.
- Don't discard the theme, just be honest about how confidently it can be
attributed to the product.
Example of the standard I want
Weak: "This confirms the feature is confusing."
Strong: "Recruited via a support-ticket list, so a bias toward frustrated
users is plausible and can't be ruled out here. A general
population sample would test that."
Output
Candidate alternative explanations · confidence in ruling each out · what
would strengthen the attribution to the product.
This prompt is the one most likely to get skipped under deadline pressure, and it's the one that saves a team from shipping a fix for a problem that was actually a recruitment artifact.
29. Theme-to-recommendation bridge
Use when you need to turn a validated theme into something a team can act on.
Role: Research lead translating a theme into a recommendation a product
team can actually use, without overreaching past what the data supports.
Context
- Theme: [paste it, with sessions and evidence strength]
- Team that will act on this: [who receives it]
- Constraints: [what's realistic for them to change]
Task
Write the recommendation.
Rules
- State the recommendation at the level of confidence the data supports:
"investigate further" for a theme from one session, "change this" only
for something well supported.
- Include what would falsify the recommendation, so the team can check
their fix actually worked.
- Don't specify a UI solution unless the research genuinely points there.
Themes about confusion don't always imply the fix the researcher
imagines.
- Keep the evidence attached so a skeptical stakeholder can check it.
Example of the standard I want
Weak: "Add a save indicator."
Strong: "Investigate: uncertainty about save state (4 of 6 sessions).
Recommend testing a visible save-state indicator against the
current design before committing to it as the fix."
Output
The recommendation with confidence level · what would falsify it ·
evidence attached.
The "what would falsify it" field is the one that turns a recommendation into something a team can actually check after they ship, rather than a claim nobody revisits.
30. Findings disclosure statement
Use when you used AI anywhere in this process and need to say so in the report.
Role: Research integrity advisor writing a disclosure that's specific
enough to be checked.
Context
- Where AI was used: [guide drafting, probe prep, transcript
summarization, coding, etc.]
- Tool and version: [name and version]
- Human verification: [what was checked, by whom]
- Consent basis: [what participants agreed to regarding AI tool use]
Task
Draft the AI use disclosure for this research report.
Rules
- Name each stage specifically. "AI assisted with analysis" tells a
reader nothing checkable.
- State what was verified at each stage and by whom. The disclosure's
credibility rests on the verification, not the admission.
- Confirm the consent basis explicitly. If participants weren't told their
data might touch an AI tool, say that plainly rather than omitting it.
- Do not claim verification that didn't happen.
Example of the standard I want
Weak: "AI tools were used to help analyze the interviews."
Strong: "[Model, version] extracted structured summaries from 8
transcripts (names removed) in [month/year]. All quotes were
checked against the original transcripts by the lead researcher.
Participants' consent forms covered analysis by third-party
tools; none opted out."
Output
The disclosure statement · a stage-by-stage table of use and verification
· the consent line, confirmed or flagged as missing.
Write this while the study is fresh, not at submission. Reconstructing which stages used AI six weeks later is harder than it sounds, and it is the part people most often get wrong under time pressure.
Where do consent and privacy rules actually bind?
Every prompt above assumes you've already cleared the ground that consent, redaction, and your organization's vendor policy actually cover. The table below is a starting checklist, not a substitute for legal review specific to your organization and jurisdiction.
| Data in the transcript | Risk if pasted raw | Minimum before pasting |
|---|---|---|
| Full name, email, or employee ID | Directly identifies the participant | Remove or replace with a session label (S1, S2) |
| Voice recording or video | Identifies by voice or face even without a name | Use a text transcript instead; check if consent covers AI processing of the recording itself |
| Company name and role | Can identify the participant within a small organization | Generalize ("mid-size logistics company") unless the study is explicitly about that company |
| Health, financial, or other sensitive detail | Higher legal exposure and higher harm if leaked | Extra caution; some tools and jurisdictions require this data stay on your own infrastructure |
| A comment naming a third person | Identifies someone who never consented at all | Remove third-party names regardless of the participant's own consent |
Consent language written before AI tools existed usually authorizes "research analysis" without naming a vendor. Whether that covers a specific AI tool is a judgment call your organization should make deliberately, not one a researcher should default into because a deadline is close. When it's ambiguous, the conservative reading is the correct one.
How do you avoid synthetic users replacing real interviews?
AI can produce a plausible persona from market data, prior research, or its own training knowledge in seconds, which is exactly the appeal and exactly the risk. A synthetic persona is a compressed guess about your users, built without talking to any of them for this study. It can be useful for stress-testing a discussion guide before you run it, or for generating hypotheses about who to recruit next. It cannot tell you what your real users think, because "generated a plausible answer" and "reported a real one" produce identical-looking sentences on the page.
The tell is usually in how a finding gets used, not in how the persona was produced. A synthetic persona used to prep a guide question is a tool. A synthetic persona quoted in a stakeholder report next to real participant quotes, with no distinction drawn between the two, is a fabrication, even when nobody intended it that way. If a document mixes generated personas and real transcripts, label every source explicitly, and never let a synthetic answer stand in for a session you didn't run.
How Prompt Architects fits this workflow
The 30 prompts above work in whatever AI tool your organization has already cleared for this kind of data. This guide is deliberately tool-agnostic on that decision, because it's yours to make, not a prompt's. What Prompt Architects adds is the layer that makes a reviewed prompt reusable instead of rebuilt every study: a prompt library where you save your discussion-guide template, your coding rules, and your disclosure statement with the research goal already attached, so the next study starts from your last one instead of a blank page.
The Contexts feature stores your standing research constraints, such as consent language your organization has approved and your redaction rules, so they inject automatically instead of being retyped, and potentially reworded, into every prompt. For teams running research across several projects, our product manager AI workflow guide covers how the same library pattern keeps context consistent across a whole research practice, not just one study.
Prompt Architects is free to start, no credit card required. Once you've synthesized themes from a set of interviews, the natural next step is turning them into a stage-by-stage view your stakeholders can act on. Our guide to 20 AI prompts for customer journey mapping picks up exactly there.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 4.8★ on the Chrome Web Store.
Create An Account