Research

Turn a user problem into research questions

Translate a product team's problem statement into neutral, answerable questions tied to a real decision

9 min setupTested with:ChatGPTReviewed: 2026-08-28

Add your context

Your text stays in this browser. AILesson Prompts does not send it to a model or server.

Problem and decisionExisting evidenceResearch constraints

Your prompt

Unfilled fields remain visible as placeholders, so you can still copy and edit the 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.

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

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.

Example output

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.

Why this works

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