Field SOP
Field SOP

User Research & Interview Prompt Pack: From Outline to Persona

A three-level user research & interview prompt pack: beginner semi-structured interview outline (anti-leading-questions), intermediate single-transcript structured insights (quote-tagged, no fabrication), expert N-transcript cross-sample synthesis into personas + JTBD + opportunity map (affinity mapping, frequency counts, conflict flagging). 4 general constraints (anti-fabrication/de-identification/human review) and 5 pitfalls.

Published August 4, 20265 min read
<!-- prompt-user-research-pack | resource | User Research & Interview Prompt Pack: From Outline to Persona -->

The most expensive mistake in user research isn't "no one showed up"-it's realizing after the fact that your questions were leading, your notes are laced with quotes the AI invented, and you're generalizing "all users want X" from three interviews. Dump a transcript into AI and say "analyze it," and you'll get back a pile of insights the respondent never said, with pain points the model hallucinated. The problem is always the instruction: no research goal, no output structure, no guardrail against fabricated quotes or privacy leaks.

This site already has a Research & Literature Review Prompt Pack (prompt-research-literature-review-pack) for reading, comparing, and reviewing academic literature. This is its sister pack, focused on user/market research-from the interview outline beforehand, to insight extraction from a single transcript, to cross-sample personas and opportunity maps. The two don't overlap: that one handles published literature; this one handles first-hand interview data. If you're working with meeting recordings rather than interviews, use the Meeting Summary Prompt Pack (prompt-meeting-summary-pack) instead. Three levels, variables in {{}}, copy and adapt.

Beginner: Interview Outline Generation

The biggest source of contamination in an interview is the leading question-"Do you think this feature is good?" already pushes the respondent toward a positive answer. A semi-structured outline translates your research goal into open, behavior-oriented questions, split into opening, core, follow-up, and closing, so AI helps you sequence questions rather than ask them for you.

Prompt
You are a senior user researcher. Based on the following research goal, produce a semi-structured interview outline.
Research goal: {{e.g., understand how small teams choose a project management tool}}
Target users: {{respondent persona, e.g., team leads at teams of 10 or fewer}}
Interview length: {{e.g., 45 minutes}}

Output in this structure:
1. Opening (3-5 min): self-intro, research purpose, informed consent, warm-up question
2. Core questions (25-30 min): unfold around the research goal, in "behavior -> motivation -> pain point" order
   - Each question open-ended and behavior-oriented (ask "what did you do last time," not "do you think it's good")
   - Tag each question with the dimension it targets (behavior/motivation/pain point/decision)
3. Follow-up list: 5-8 universal follow-ups (e.g., "can you walk me through one instance," "then what," "why did you do it that way")
4. Closing (3-5 min): open catch-all ("anything I didn't ask?"), thanks, next steps

Constraints:
- No leading questions: don't write "do you find X good" or "do you wish there was Y"-these bake in a direction
- Questions must be neutral and open, starting with "how," "last time," "can you give an example"
- If the research goal is ambiguous, list the ambiguities and ask me-don't assume

The value of an outline is a traceable mapping from research goal to question. Every core question should map to a dimension you want to dig into, so post-interview you can trace back "what did this question actually answer?" AI defaults to a pile of pseudo-open "how do you feel about..." questions; forcing behavior-oriented phrasing in the constraints is what stops them from all being leading questions in disguise.

Intermediate: Single Transcript -> Structured Insights

After the interview you have thousands of words of transcript. Ask AI to "summarize the pain points" and you get a vague paragraph that blurs respondent quotes with AI inference. This level breaks a single transcript into structured fields, forces quote tagging, and forbids inventing anything the respondent didn't say.

Prompt
You are a user research analysis assistant. Read the following interview transcript and extract structured insights.
Interview info: {{respondent code (e.g., P1) / date / duration}}
Transcript: {{full interview transcript}}

Output in this structure:
1. Pain points: list 3-5, each with: description + one verbatim quote (tag "quote") + the context it occurred in
2. Motivations: list 2-3, distinguishing "motivation the respondent stated" from "motivation you inferred from behavior"-tag the latter "inference"
3. Behaviors: list 3-5 key behaviors (what they did, what they used, what they worked around), noting frequency ("every time," "occasionally")
4. Key quotes: pick 3-5 most informative verbatim lines, transcribed word-for-word, with rough location ("mid-interview")
5. Not mentioned: 2-3 points relevant to the research goal that the respondent did not address, tagged "not mentioned in source"

Constraints:
- All quotes must be verbatim from the transcript. No rewriting, no fabrication. Any quote that can't be located in the source is deleted
- Pain points and motivations are based only on what the respondent actually expressed-no filling in. Unstated content goes in "not mentioned"
- Privacy de-identification: replace names, companies, project codenames in quotes with codes (e.g., "Company X"); raw PII does not enter the output
- End with: This insight is an AI draft; quotes and conclusions require human verification

The "not mentioned" section is the key anti-fabrication brake. AI defaults to filling pain points with "what the respondent probably meant but didn't say"; forcing it to list unstated items separately and tag them explicitly shows you where the real gaps are. The observation-vs-inference split works the same way: "I manually export every week" is an observation; "because he doesn't trust automation" is an inference-mixing them is over-interpretation. This level shares the structured-summarization mindset of the Meeting Summary Prompt Pack, but adds research-dimension breakdown and anti-fabrication guardrails.

Expert: N-Transcript Cross-Sample Synthesis -> Persona + JTBD + Opportunity Map

A single insight is a point; N-insight synthesis is a surface. This level runs affinity mapping across multiple structured insights: counts pain-point frequency, flags conflicting views, clusters them into personas, then uses Jobs-to-be-Done to translate motivations into "what job is the user hiring this product for," and finally produces an opportunity map. The two mistakes AI makes most here: forcing a small sample into "all users..." generalizations, and writing personas as demographic collages.

Prompt
You are a user research synthesis expert. Based on the following multiple interview insights, perform cross-sample synthesis.
Input: N structured interview insights (each with pain points/motivations/behaviors/quotes)
{{Insight 1: P1 ...}}
{{Insight 2: P2 ...}}
(add more as needed)
Sample size N: {{e.g., 8}}

Task 1: Affinity clustering and frequency
- Cluster all pain points and motivations into 5-8 thematic clusters; name each
- For each cluster, note how many respondents mentioned it (e.g., "5 of n=8") and list their codes
- Flag conflicts: themes where respondents disagree (e.g., P2 finds it slow, P5 finds it fast enough)-don't average them away

Task 2: Personas (2-3)
- Each persona's spine is behavior pattern + Jobs-to-be-Done; demographic (role/team size) is secondary
- For each: name (e.g., "Manual faction P1/P3/P7") + representative Job ("when I..., I want to... so that...") + key behaviors + shared pain points
- Personas are built from actual respondents-tag which respondents each is aggregated from; don't invent a "typical user" out of thin air

Task 3: Jobs-to-be-Done and opportunity map
- List 3-5 core Jobs (functional/emotional/social), each with frequency
- Opportunity map: 4-6 opportunities, each with: unmet Job + current workaround + opportunity description
- Rough-prioritize opportunities by "mention frequency x pain severity"

Constraints:
- Frequencies must be honest, split into "majority (>=60%)" / "some (30-60%)" / "few (<30%)"; never write "all users" from 3 interviews
- Conflicting views are kept and flagged; don't smooth them over with "overall"
- Personas must not be stereotype demographic collages (only age/gender/occupation); behavior and Jobs are the spine
- All quotes trace back to a specific respondent; de-identification follows the level-2 code rules
- End with: AI-generated draft; personas and opportunities require human verification; small-sample conclusions should not be directly extrapolated

The expert-level mindset: AI clusters, you judge. It's good at grouping scattered pain points, counting frequency, and applying the JTBD sentence frame, but bad at judging whether "5 of n=8" generalizes to a market. Writing "frequency tiers" and "keep conflicts" into the hard constraints stops AI from dressing up a coincidence across 8 interviews as a trend. The real value of the opportunity map is the workaround-what users do today to get by is often the entry point for a new product.

General Constraints and Pitfalls

General Constraints (Apply to Every Level)

  1. No fabrication, don't add what wasn't said-The #1 risk of AI in user research is inventing quotes. It polishes "the respondent seemed to feel..." into a direct quote that looks verbatim but is AI-generated. Every prompt states "quotes must be verbatim from the source; anything unlocatable is deleted," and after output you spot-check a few quotes against the transcript. When in doubt, delete.
  2. Privacy de-identification-Interviews contain PII (names, companies, contact info, project codenames, sensitive identity info). Replace all of it with codes before output; raw data stays in a controlled environment. AI de-identification misses implicit PII (like the company name in "back when I was at Ant"), so a human must re-scan after.
  3. Separate observation from inference-What the respondent said (observation) is not the same as the motivation AI reads into it (inference). Inferences must be tagged "inference" and kept separate from quotes, or interpretation gets passed off as fact.
  4. AI drafts need human review-Outlines, insights, personas, and opportunity maps are drafts, not deliverables. Research judgment, ethics compliance, and extrapolation rest with humans. Tag output "AI-generated draft, requires human verification"-don't drop an AI persona straight into a PRD as a deliverable.

Pitfalls

  1. Leading questions: "Do you think this feature is good?" pushes respondents positive. Fix: the outline prompt forces open, behavior-oriented phrasing ("what did you use last time," "can you give an example") and bans "is it good"/"do you want."
  2. AI-fabricated quotes: AI "optimizes" a respondent's fuzzy phrasing into a polished quote. Fix: transcribe verbatim, tag location, spot-check against source, delete any rewritten quote.
  3. Over-generalizing from small samples: writing "all users want X" from 3 interviews. Fix: count frequency honestly and tier it (majority/some/few), tag sample size, don't extrapolate small-sample claims.
  4. De-identification gaps: AI swaps names but misses company names, project codenames, offhand client mentions. Fix: re-scan manually after de-identification; PII checks aren't only explicit fields.
  5. Stereotype personas: AI writes personas as "25-35, female, tier-1 city, white-collar" demographic collages, ignoring behavior and motivation. Fix: personas are built on Jobs + behavior as the spine, demographic as a footnote, and tagged with which respondents they aggregate.

References

This article is AI-assisted and human-edited. Last updated: 2026-08-04

Related

Field SOP

Code Testing Prompt Pack: Unit, Parameterized, E2E & Refactor

A three-level code testing prompt pack: beginner generates unit tests per function (signature and boundary list first, N cases each for normal/boundary/error, pytest/jest parameterized), intermediate parameterized batch cases with a test plan (coverage gaps, minimal mocking), expert integration/E2E strategy and test refactor (test pyramid, contract tests, redundancy pruning). Includes a 5-minute cheatsheet. Anti-fabrication constraints embedded (no invented APIs, no fabricated coverage numbers). Differentiated from the general coding and review/debug packs--this one handles writing tests only.

Aug 4, 20265 min read