Extract user needs and evidence from interview notes
Trace behaviors, goals, constraints, and unmet needs to interview evidence without converting requests into requirements
9 min setupTested with:ChatGPTReviewed: 2026-08-28
1
Add your context
Your text stays in this browser. AILesson Prompts does not send it to a model or server.
2
Your prompt
Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt
Extract user needs and evidence faithfully from the supplied interview records.
Transcripts or notes, participant IDs, timestamps, session context, prompts, corrections, artifacts, consent, and gaps:
[records]
Research questions, sample, recruitment, decision, terms, hypotheses, and excluded interpretations:
[study]
Coding unit, need format, quote permission, privacy, confidence, minimum evidence, negative cases, reviewer process, and schema:
[analysis]
Keep participant report, observed behavior, artifact evidence, moderator prompt, researcher interpretation, and product request separate. Extract recent situations, triggers, goals, current actions, alternatives, breakdowns, constraints, consequences, decision criteria, workarounds, desired progress, and counterexamples with participant and timestamp or locator. Write solution-independent need statements in context, not demographic stereotypes or feature wishes. A request such as “send reminders” is evidence of a proposed solution; infer the underlying need only as a labeled hypothesis supported by behavior and context. Preserve contradictions within and across sessions, silent or missing evidence, sample and recruitment limitations, and moderator-leading effects. Do not count repeated statements by one participant as multiple participants. For each theme give unique participants, evidence locators, supporting and opposing cases, confidence rationale, affected roles and contexts, unknowns, and next validation question. Redact unauthorized personal or customer data. End with facts safe to report, interpretations needing review, and claims the sample cannot support.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.
From input to outcome
A worked example
See how concrete context turns this recipe into a usable result
Actual input
Interview records
P01 12:10: recent client review stayed Ready three days; P01 checked Teams twice and messaged project lead because no accepter was shown. 15:02 says 'email me until I answer.' P02 08:40: Ready overnight was intentional because client was in another timezone; 10:15 says more emails would be noise. P03 19:22: missed a handoff because they expected an @mention; screenshot shows owner but no accepter. Moderator at 20:00 asks 'Would automatic reminders solve that?' P03 replies 'probably.' P04 notes only, no timestamps: uses a daily queue and says delayed Ready items are usually waiting for approval. All recruited from support contacts; short quotes approved, customer names not approved.
Study frame
Question: what situations create long Ready states and what information enables action? Decision: explore email reminder, ownership cue, or neither. Four participants: two owners, one accepter, one requester; UK/Germany. Support recruitment likely overrepresents problems. Define accepter as person authorized to confirm next state. Do not infer market prevalence or feature demand.
Analysis rules
Coding unit is recent handoff instance. Need format: When (context), role needs (progress), so they can (outcome), evidenced by (behavior). Count unique participants, minimum two for cross-participant theme but retain single cases. Include negative cases. Quotes under 15 words with participant/time. Redact customers. Two researchers review interpretations independently.
Example output
Theme 1 — identify who can accept a handoff, medium confidence, 2 unique participants
Evidence: P01 checked Teams twice and contacted a lead because no accepter appeared (12:10). P03 expected an @mention; the artifact showed an owner but no accepter (19:22). Need hypothesis: when a handoff is ready but acceptance responsibility is unclear, the acting role needs to identify the authorized accepter so they can direct the next action without searching across people. This is supported by behavior plus artifact, but roles and frequency need confirmation. Countercase: P04's delayed items usually wait for approval, which may involve known rather than missing authority.
Theme 2 — distinguish intentional waiting from a missed action, medium confidence, 2 participants with different contexts
P02 intentionally waited across timezone (08:40); P04 reported approval waiting. Need hypothesis: when a Ready state continues, roles need the reason and expected next event so they can decide whether to wait or intervene. This does not imply a reminder.
Solution requests and leading effects
P01's “email me until I answer” (15:02) is a feature suggestion, not proof that repeated email meets the underlying need. P02 is a negative case: “more emails would be noise” (10:15). P03's “probably” follows the moderator's leading reminder question (20:00) and is low-quality evidence for demand; do not count it as independent validation.
Safe facts: two participants encountered artifacts without visible accepter information; one reported intentional timezone waiting; one reported approval waiting. Interpretations require dual-researcher review. The sample cannot support prevalence, segment comparison, causal claims, or a recommendation to build reminders. Next question: across a broader consented sample, can recent instances be classified by known/unknown accepter, intentional wait, external approval, missed signal, and other causes?
Why this works
1
Solution-independent need statements keep feature requests from prematurely defining the product answer.
2
Participant-level counting and negative cases prevent loud repetition from looking like prevalence.
Check the result
Does every need trace to behavior and context rather than a feature request alone?
Are unique participants, locators, negative cases, and moderator effects preserved?
Are observation, interpretation, request, and unsupported prevalence clearly separate?
ChatGPT