Turn a user problem into research questions

Autor: AILesson9 min de configuraçãoTestado com:ChatGPTRevisado em: 2026-08-28

Resposta rápida

Translate a product team's problem statement into neutral, answerable questions tied to a real decision. Forneça: Problem and decision, Existing evidence, Research constraints. Resultado esperado: A prioritized research-question framework with assumptions, evidence needs, methods, limits, and decision rules.

1

Adicione seu contexto

Seu texto permanece neste navegador. O AILesson Prompts não o envia para um modelo ou servidor.

2

Seu prompt

Campos não preenchidos permanecem visíveis como marcadores de posição, para que você ainda possa copiar e editar o prompt

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.
Experimente no Playground
Privado por padrãoA montagem do prompt acontece localmente no seu navegador. Evite colocar informações confidenciais em qualquer serviço de IA, a menos que sua organização permita.

Da entrada ao resultado

Um exemplo prático

Veja como um contexto concreto transforma esta receita em um resultado útil

Entrada real

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.

Exemplo de saída

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.

Por que isso funciona

  1. 1

    Decision-linked questions prevent research from becoming broad curiosity without an action path.

  2. 2

    Alternative explanations make premature solution and cause assumptions visible.

Verifique o resultado

  • 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?

Use com confiança

Perguntas frequentes

Respostas práticas sobre quando usar esta receita, o que fornecer e onde a revisão humana ainda é importante

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.

Mais maneiras de explorar

Onde esta receita se encaixa

Mantenha o trabalho em andamento