Turn a user problem into research questions

작성자: AILesson9 분 소요테스트::ChatGPT검토일: 2026-08-28

빠른 답변

Translate a product team's problem statement into neutral, answerable questions tied to a real decision. 제공할 내용: Problem and decision, Existing evidence, Research constraints. 예상 결과: A prioritized research-question framework with assumptions, evidence needs, methods, limits, and decision rules.

맥락 추가

텍스트는 이 브라우저에 유지됩니다. AILesson Prompts는 이를 모델이나 서버로 보내지 않습니다.

Problem and decisionExisting evidenceResearch constraints

프롬프트

채워지지 않은 필드는 플레이스홀더로 표시되므로 프롬프트를 복사하고 편집할 수 있습니다

Turn the supplied user problem into neutral, decision-relevant research questions.

Observed problem, workflow, decision, deadline, stakeholders, options, and consequences:
[problem]

Analytics, feedback, research, support evidence, samples, dates, contradictions, and gaps:
[evidence]

Population, recruitment, methods, sample capacity, time, budget, ethics, privacy, accessibility, and exclusions:
[constraints]

Separate observation, interpretation, assumption, product hypothesis, and decision. Rewrite the problem as a provisional statement without implying a cause or solution. Inventory what is known, how it was measured, whose experience is represented, competing evidence, and what remains unknown. Generate research questions about current behavior and context, triggers, goals, workarounds, breakdowns, variation, consequences, mental models, decision criteria, accessibility, and response to concepts only where relevant. Avoid questions whose wording presupposes pain, demand, feature desirability, causation, or a single correct solution. For every question state which product decision it informs, priority, evidence needed, suitable method, population, analysis unit, plausible alternative explanations, limits, and what result would change the decision. Remove questions that are merely interview prompts, metrics without a question, or too broad for the constraints. End with a research sequence and unresolved stakeholder choices.

Playground에서 사용해 보기

기본적으로 비공개프롬프트 구성은 브라우저에서 로컬로 이루어집니다. 조직에서 허용하지 않는 한 기밀 정보를 AI 서비스에 입력하지 마세요.

입력에서 결과까지

적용 예시

구체적인 맥락이 이 레시피를 바로 사용할 수 있는 결과로 바꾸는 방법을 확인하세요

실제 입력

Problem and decision: Product team says 'users need automatic reminder emails because tasks are overdue.' Observed workflow: small-team managers create requests, owners update status, and accepters close handoffs. Decision in six weeks: build automatic email reminders, improve in-product ownership visibility, or run no feature project. Stakeholders: Product, Support, Engineering, Privacy. A wrong decision consumes one quarter of capacity.
Existing evidence: Analytics, last 60 days: 31% of active workspaces had at least one task remain in Ready over 48 hours; event does not distinguish intentional waiting. 42 support tickets mention reminders, but 18 request fewer notifications. Eight prior interviews: five described unclear accepter, two forgot status, one had approval delay. Interview sample recruited from support contacts. No email-consent or accessibility research.
Research constraints: Can run 12 interviews, analyze existing event paths, and test two low-fidelity concepts in four weeks. Active users in UK and Germany. Recruit across workspaces with and without overdue events; include keyboard and screen-reader users. No production experiment, sensitive profiling, or contacting users without approved consent. Legal/privacy review concept before testing.

예시 출력

Provisional problem: some Ready-state handoffs remain open beyond 48 hours, but current evidence does not establish whether they are overdue, why they remain open, or whether another notification would help.

Priority 1 — What distinct situations produce Ready durations over 48 hours, and how do owner, accepter, approval dependency, intentional waiting, and forgotten status differ across them? Decision: whether any feature intervention is warranted and which workflow point it should address. Evidence: event-path segments plus interviews sampled from both long-duration and comparison workspaces. Alternative explanations include scheduled waiting, missing accepter, external approval, event-tracking error, and forgotten update. A dominant missing-accepter pattern would favor visibility exploration; deliberate waiting would weaken both feature options.

Priority 2 — How do people currently notice, interpret, and act on a handoff that is not moving? Decision: whether the breakdown is awareness, authority, evidence, or process. Method: recent-instance interviews using artifacts where participants consent. Do not ask “Why don't reminders work?”

Priority 3 — What costs and benefits do affected roles anticipate from in-product ownership cues versus email reminders, including notification load, privacy, consent, accessibility, and ability to act? Decision: which concepts merit further testing. Method: two balanced low-fidelity concepts after Privacy review; task-based comprehension and action questions, not preference voting alone. Include accepters and owners plus assistive-technology users.

Priority 4 — Which current events can validly measure intentional versus problematic delay? Decision: instrumentation work before a later experiment. Audit definition, missing events, and analysis unit at handoff rather than workspace percentage alone.

Sequence: analytics definition audit; 12 stratified recent-instance interviews; synthesize causes and variations; legal/privacy review; counterbalanced concept tasks. Stakeholders must predeclare what evidence supports build, instrument, investigate, or no feature. The 42 reminder tickets and 18 fewer-notification tickets are directional, not prevalence estimates.

효과가 있는 이유

1
Decision-linked questions prevent research from becoming broad curiosity without an action path.
2
Alternative explanations make premature solution and cause assumptions visible.

결과 확인

Does each question inform a named decision without assuming an answer?
Are population, evidence, method, analysis unit, and limitations explicit?
Would a plausible result actually change the product choice?

안심하고 사용하세요

자주 묻는 질문

이 레시피를 언제 사용해야 하는지, 무엇을 제공해야 하는지, 그리고 어떤 부분에서 사람의 검토가 여전히 중요한지에 대한 실용적인 답변

What should I prepare before using “Turn a user problem into research questions”?

For “Turn a user problem into research questions,” prepare Problem and decision, Existing evidence, and Research constraints. 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 “Turn a user problem into research questions” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—A prioritized research-question framework with assumptions, evidence needs, methods, limits, and decision rules—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 “Turn a user problem into research questions”?

The published test record for “Turn a user problem into research questions” 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.

더 많은 탐색 방법