Turn a user problem into research questions

Auteur: AILesson9 min de préparationTesté avec:ChatGPTRévisé: 2026-08-28

Réponse rapide

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

1

Ajouter votre contexte

Votre texte reste dans ce navigateur. AILesson Prompts ne l’envoie ni à un modèle ni à un serveur.

2

Votre prompt

Les champs non remplis restent visibles sous forme d’espaces réservés, afin que vous puissiez quand même copier et modifier le 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.
Essayer dans le Playground
Privé par défautL’assemblage du prompt se fait localement dans votre navigateur. Évitez de placer des informations confidentielles dans un service d’IA, sauf si votre organisation l’autorise.

De l'entrée au résultat

Un exemple détaillé

Voyez comment un contexte concret transforme cette recette en résultat utilisable.

Entrée réelle

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.

Exemple de sortie

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.

Pourquoi cela fonctionne

  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.

Vérifier le résultat

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

Utilisez-la en toute confiance

Questions fréquentes

Des réponses pratiques sur le bon moment pour utiliser cette recette, ce qu’il faut fournir et les cas où une vérification humaine reste nécessaire.

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.

Faites avancer votre travail