Trace behaviors, goals, constraints, and unmet needs to interview evidence without converting requests into requirements. 제공할 내용: Interview records, Study frame, Analysis rules. 예상 결과: An evidence table with observations, need statements, variations, confidence, contradictions, gaps, and follow-up questions.
1
맥락 추가
텍스트는 이 브라우저에 유지됩니다. AILesson Prompts는 이를 모델이나 서버로 보내지 않습니다.
2
프롬프트
채워지지 않은 필드는 플레이스홀더로 표시되므로 프롬프트를 복사하고 편집할 수 있습니다
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.
기본적으로 비공개프롬프트 구성은 브라우저에서 로컬로 이루어집니다. 조직에서 허용하지 않는 한 기밀 정보를 AI 서비스에 입력하지 마세요.
입력에서 결과까지
적용 예시
구체적인 맥락이 이 레시피를 바로 사용할 수 있는 결과로 바꾸는 방법을 확인하세요
실제 입력
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.
예시 출력
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?
효과가 있는 이유
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.
결과 확인
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?
안심하고 사용하세요
자주 묻는 질문
이 레시피를 언제 사용해야 하는지, 무엇을 제공해야 하는지, 그리고 어떤 부분에서 사람의 검토가 여전히 중요한지에 대한 실용적인 답변
What should I prepare before using “Extract user needs and evidence from interview notes”?
For “Extract user needs and evidence from interview notes,” prepare Interview records, Study frame, and Analysis rules. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.
When is the “Extract user needs and evidence from interview notes” result not ready to use?
The result is not ready if it does not yet deliver the stated outcome—An evidence table with observations, need statements, variations, confidence, contradictions, gaps, and follow-up questions—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.
Which AI tools have recorded tests for “Extract user needs and evidence from interview notes”?
The published test record for “Extract user needs and evidence from interview notes” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.
ChatGPT
