Method
A framing workshop that aligns on root problem, affected users, and constraints, then converts insights into How Might We prompts.
Why you were brought here
You came here from define the problem / scope / success measures.
Pack = one session you can run now. Workspace = a saved thread for method choice, planning, and shareable outputs.
What Workspace helps you carry forward
Artifact preview
Problem statement
Validate · Moderate
Decide fit before you spend session time.
Room fit check
Best when the team is solving different problems without admitting it yet. This room has enough of the right conditions for the method to hold without extra ceremony.
Primary risk: The room writes inspirational prompts instead of a real problem statement.
The core facilitation flow, with enough structure to run the method confidently in the room.
Standard setup for Mixed in remote delivery.
Total planned time: 120 min
What happens
List observed pains, metric shifts, and customer complaints as raw evidence.
Facilitator does
Ask specifically for evidence: "What have you seen, heard, or measured?" Stop anyone diagnosing causes or proposing solutions. If a participant says "the problem is X," ask: "What did you observe that makes you believe that?" Write the observation, not the interpretation. The symptoms phase produces raw material; mixing it with diagnosis now creates false consensus on the wrong problem.
Participants do
Contribute observations, quotes, data points, and incidents — not theories about why things happen or ideas about what to do. Each note should describe something specific that was seen, heard, or measured.
Output / signal of success
15–25 distinct observed symptoms on the board — specific incidents, customer quotes, metric changes — with no diagnoses or solutions. A person outside the team could read the board and understand what is happening without knowing what the team thinks it means.
Watch for
Participants jump to root causes before the symptom inventory is complete.
Recovery tip
Stop the board. Say: "We're collecting what we've seen, not what we think it means yet. Save the diagnosis — write one thing you personally observed or a direct quote you heard." Restart the timer.
What happens
Cluster symptoms and draft one problem statement with scope, affected user, and evidence base.
Facilitator does
Cluster the symptoms first, then ask: "What single problem would explain most of these clusters?" Draft a candidate statement together. A strong problem statement names: who is affected, what they experience, and what evidence supports it. Reject any statement that names a solution, a feature, or a technology. Reject any statement that could not be falsified by evidence.
Participants do
Challenge the problem statement if it reflects the sponsor's preferred narrative rather than the evidence on the board. The statement must be traceable to the symptoms collected in Step 1.
Output / signal of success
One agreed problem statement on the board naming the affected user, the experienced problem, and pointing to at least two symptom clusters as evidence.
Watch for
The problem statement reflects the sponsor's preferred narrative or the team's existing roadmap direction rather than the evidence gathered in Step 1.
Recovery tip
Ask: "Which symptom clusters on the board support this statement?" If fewer than two clusters point directly to it, the statement is ahead of the evidence. Revise until it can be traced back to what was actually observed.
What happens
Rewrite the problem statement into multiple How Might We questions that open the design space.
Facilitator does
Model the first HMW together before releasing for individual silent generation. Apply the solution test to every prompt: "How might we build a dashboard" is a solution framed as a question — redirect: "What underlying need does a dashboard address? Write that need as the HMW." A strong HMW can be answered in at least three genuinely different ways. If only one answer exists, it's a solution brief, not a prompt.
Participants do
Write HMWs that open the design space rather than pointing toward a specific solution. Before submitting a prompt, test it: can you think of three genuinely different answers? If not, rewrite it.
Output / signal of success
8–15 HMW prompts on the board, each answerable in multiple genuinely different ways, covering different facets of the problem statement.
Watch for
HMW statements embed a specific solution ("How might we use AI to...," "How might we redesign the...") rather than naming the user need or gap.
Recovery tip
Read the HMW aloud and ask: "What specific solution does this point toward?" If someone can immediately name one, the prompt is too narrow. Ask: "What does the user need that would make that solution relevant?" Write that need as the HMW instead.
What happens
Vote on the HMW prompts most worth exploring — meaningful, open, and actionable.
Facilitator does
Give each participant three votes. Write the voting criterion on the board: "Vote for the HMW that would most change what you build if answered unexpectedly." After voting, check that the top 3 prompts are genuinely different from each other. If they're all the same facet of the problem, swap one for the highest-voted prompt from a different cluster.
Participants do
Vote for prompts you'd most want to see answered by a range of creative solutions — not the prompts that point toward the answer you already have in mind.
Output / signal of success
3 HMW prompts selected, each covering a different facet of the problem, each traceable back to the problem statement and the symptom clusters it came from.
Watch for
The room selects prompts that point toward the existing roadmap rather than the most generative exploration territory.
Recovery tip
Ask: "Which HMW would most surprise us if it had a great answer we hadn't considered?" If it's not in the selected set, ask why — and consider swapping the lowest-differentiation prompt for it.
Prepare the room, the evidence, and the working surface so the session can stay focused on synthesis.
At least a handful of concrete observed symptoms — customer complaints, metric shifts, team incidents — that participants have personally seen or heard. Without any observed evidence, the problem statement will reflect team opinion and the session produces a statement the team already had before they walked in. If no evidence exists yet, gather it first.
Current challenge statement
Optional
Known evidence
Optional
Operational context note
Optional
Bring examples, pain points, or service evidence the room can point to quickly.
How Might We board
Optional
Remote facilitation choreography
Required
Pre-plan handoffs, breakout usage, and how people rejoin the main board.
How Might We board
Required
Shared digital board with timer and voting
Required
Keep instructions and voting visible at all times.
Problem framing board
Keep the output usable, then use the recovery guidance when the room starts drifting.
What this does not produce
Problem framing produces a shared problem statement and generative prompts for downstream ideation. It does not validate the problem with users, produce a solution direction, or prioritise which problem to solve relative to others. The HMW prompts produced in this session need a downstream ideation method — they are inputs, not outputs.
Failure mode
Why it happens
The most senior person in the room usually has a preferred problem frame that arrived before the session started. When the group reaches Step 2, social dynamics push the problem statement toward that frame regardless of what the symptom clusters show.
Recover now
If this happens, point at the symptom clusters and ask: "Which specific clusters on the board support this statement?" If fewer than two clusters map directly to it, say: "This statement is ahead of the evidence we collected. Let's write one that can be traced back to what we actually observed."
Prevent next time
Next time, before Step 2, write the evaluation criteria for a strong problem statement on the board: traces to evidence, names the affected user, doesn't contain a solution direction. Use it as a public checklist when reviewing the draft.
Failure mode
Why it happens
Participants with existing solution ideas use the HMW format to legitimise their preferred direction. "How might we use AI to personalise recommendations" sounds like a design question but is a scoped feature brief. This collapses the generative purpose of the method and channels downstream ideation toward one predetermined direction.
Recover now
If this happens, apply the three-answer test out loud: read the prompt and ask the room to name three genuinely different ways to answer it. If only one or two answers exist, the prompt needs rewriting.
Prevent next time
Next time, model a solution-as-HMW and a genuine HMW side by side before Step 3 opens. Keep both examples visible during generation.
Failure mode
Why it happens
When symptom clusters don't converge naturally, there's pressure to write a statement broad enough to cover everything. "We struggle to deliver value at speed" sounds like a problem statement but contains three or four separate problems. Downstream HMWs inherit the vagueness and produce prompts too broad to generate specific solutions.
Recover now
If this happens, stop. Count the number of distinct problems in the current statement. If more than one: split them, have the room vote on which single problem is highest priority for this session, and frame the session as "problem 1 of N."
Prevent next time
Next time, during symptom clustering in Step 2, label each cluster with a draft one-sentence problem. If three or more distinct clusters exist, surface the choice explicitly before writing the combined statement.
Change the shape of the session only after the fit and runbook are clear.
Standard variant for Mixed in remote delivery. Waypoint is adapting timing, facilitation emphasis, prep, and recovery guidance here, but the room still needs final tailoring to the exact stakes and participants.
Use this after you have checked the fit and know you want to carry the method forward.
The pack is the fastest way to run this now. Use the links below when you need prep, sharing, or a saved reference point.
Sources and references used in this method page.
IDEO.org, Human-Centered Design methods.
Validation and usability testing fundamentals.
Reviewed 2026-04-17 by Discovery Waypoint Editorial Team
Related playbooks
These pages translate recognizable external methods into Waypoint-native guidance so the team can borrow the useful part without importing the whole mythology.
A fast decision-clarity play for assigning who drives, approves, contributes, and stays informed before a meeting becomes political fog.
Open when Decision meetings keep circling because ownership and consultation rights are still fuzzy.
Treat the sprint as a compact operating sequence for answering a specific risky question, not as a default wrapper for any ambiguous project.
Open when Risky concepts that need one compressed answer and fast user reaction.
Use the Design Kit as a broad field guide for choosing a move category, then switch back into Waypoint once the team knows the sharper method it actually needs.
Open when A team needs method breadth, especially early in a project or while building HCD literacy.
