How Might We
A reframing question that converts a research insight into an open design challenge — the hinge between what you learned and what you build.
Some problems, stated as problems, cannot be solved — only endured. The question is not what to fix. It is how to stand in front of the same situation and ask something different.
What it is
A reframing, not a question. A hinge, not a brainstorm prompt.
How Might We (HMW) is a structured reframing question that converts a problem statement or research insight into an open design challenge. The format was developed at IDEO and is standard practice in design thinking. Its phrasing is precise: “How” asserts that a solution exists; “might” holds it as a possibility rather than a demand; “we” makes it collaborative. Three words that together create an invitation.
Its power is in the conversion. A problem stated in its own terms (“users abandon checkout because it feels effortful and uncertain”) is locked in the problem’s framing. A HMW question (“how might we make checkout feel effortless and reassuring?”) holds the same reality but opens it into possibility. The insight is preserved; the stance changes from diagnosis to design. This conversion is the mechanism that bridges research and ideation.
HMW is not a brainstorm prompt and not a volume exercise. One well-formed HMW question is worth more than twenty poorly scoped ones. The craft is in the calibration: the question must be specific enough to give creative direction and open enough to allow genuinely different solutions. Too broad (“how might we reinvent online shopping?”) and it gives no direction. Too narrow (“how might we add a progress bar to the checkout page?”) and it has already answered itself. Just right is a question that could be answered in more than one way, none of them obvious.
Scope calibration
The same problem. Three altitudes.
The scope of a HMW question determines what solutions are possible. Too broad and there is no direction. Too narrow and the question has already answered itself. Toggle between the three to see why scope calibration is the skill, not the phrasing.
When to deploy it
A synthesis tool for converting insight into design challenge.
Use How Might We when
- →Research has produced specific, observed insights that need converting into design challenges before ideation begins.
- →The team is stuck in problem mode — diagnosing, analyzing, or reporting the problem rather than opening it into possibility.
- →After affinity mapping has produced insight clusters that need converting into a brief for ideation.
- →At the Define phase of a double diamond or design sprint, where the task is converting Discover findings into a design challenge.
- →When you need a single, shared design challenge that a cross-functional team can align on before ideation.
Do not lean on it when
- ×Research hasn't happened yet. HMW without evidence becomes guessing framed as a design method. The quality of the HMW is a direct function of the quality of the insight behind it.
- ×You already have a solution in mind. Skipping to "how do we build X" wastes the method — HMW exists to open the solution space, not to dress up a decision already made.
- ×The problem is genuinely vague. A HMW question converts a specific insight; without a specific insight there is nothing to convert. Do the research first.
- ×You need prioritization, not reframing. If the team already has good design challenges and needs to decide which to pursue, use a prioritization tool like the ambition matrix.
The honest limit: a HMW question is only as good as the insight behind it. A weak insight produces a weak HMW — one that accurately reframes the wrong thing. The method is a conversion mechanism; the quality of the input determines the quality of the output.
How it works
Five moves, from raw insight to open design challenge.
Start with a specific, observed insight.
HMW converts evidence into possibility. The evidence must be specific: not "users find checkout hard" but "users abandon checkout at the payment step because it feels effortful and uncertain — observed in 11 of 14 interviews." The more specific the insight, the more directional the HMW.
State the problem in its own terms first.
Before reframing, write the problem exactly as observed. Do not edit or improve it. This is the raw material: the observed failure, the real emotional response, the actual gap. Writing it preserves what the research found rather than what the team wants to hear.
Convert to a HMW question.
Apply the format: "How might we [convert the problem into an opportunity]?" Stay close to the insight — the first HMW is usually the most direct reframing. Don't over-engineer it. "How might we make checkout feel effortless and reassuring?" holds the same insight as the problem statement, reframed for possibility.
Calibrate the scope.
Test the question against the three scope levels: too broad (could mean anything, no direction), too narrow (already implies a solution), just right (specific enough to act, open enough to explore). If the question is too broad, narrow it. If it's too narrow, back up one level. The calibration step is where the skill lives.
Select and commit to one or two.
A HMW session should produce one or two well-calibrated design challenges — not twenty. More than two is usually a sign that the scope calibration step was skipped. The selected HMW questions become the brief for ideation: specific enough to give direction, open enough to generate genuinely different solutions.
Best practices
What good looks like — and what prevents it.
When it goes well
- ✓The question is anchored to a specific, observed insight — it converts evidence, not opinion.
- ✓The scope is calibrated: specific enough to give direction, open enough to generate genuinely different solutions.
- ✓The question preserves the emotional truth of the insight without losing it in polished language.
- ✓The team can argue about whether the scope is right — that debate is a sign the question is working.
- ✓It changes the conversation: the team shifts from diagnosing the problem to generating possibilities.
The mistakes, and how to avoid them
Treating volume as output.
Generating twenty HMW questions is not the goal. The goal is one or two well-calibrated, insight-anchored design challenges. Volume without scope calibration produces a long list of possibilities that cannot prioritize anything.
Losing the emotional truth in the reframe.
"How might we optimize the payment flow" and "how might we make checkout feel effortless and reassuring" address the same problem — but the second preserves the emotional observation and opens a different solution space. Abstracting away the human truth is the most common way a HMW goes flat.
Skipping scope calibration.
A HMW at the wrong scope produces either paralysis (too broad) or a dressed-up specification (too narrow). The calibration step — testing the question against three altitudes — is not optional. It is the step where the method actually does its work.
Running HMW without a specific insight.
HMW converts insight into design challenge. Without a specific, observed insight, the method has nothing to convert. Running HMW from a vague problem summary produces vague design challenges. Do the research first; run HMW from what the research found.
Logistics
Running the session from insight to design challenge.
HMW works well individually but is most powerful in a cross-functional group with access to the raw research. The group should include people who were in the interviews, people who will be in the ideation sessions, and at least one person who can push back on scope. The writing of the question is the key step — it is where the reframing happens.
Start from a specific insight, not a general theme
One HMW question per insight cluster. Don't try to reframe twenty insights into one question. A good HMW session converts three to five specific insights into three to five design challenges — a volume the team can work with in ideation.
Write, don't discuss
The first step is writing, not talking. Each person writes their own HMW question for the insight. Writing forces specificity and avoids the gravitational pull toward the group's existing framing. Compare and calibrate after everyone has written.
Run scope calibration explicitly
After writing, place each HMW at a scope level: too broad, just right, too narrow. This step is often skipped — and skipping it is the most common cause of a HMW session that produces nothing useful. Make the calibration conversation visible and explicit.
Aim for one chosen question per insight
After calibration, converge. The group selects the best-scoped HMW for each insight — the one that gives the most direction while leaving the solution space genuinely open. The output of the session is a set of design challenges, not a list of questions.
Remote: works well
HMW is well-suited to remote sessions. A shared digital whiteboard where each participant writes their questions, followed by a structured scope calibration discussion, works reliably. The writing step keeps people from talking each other out of a brave reframe before they've committed it to paper.
AI and this method
AI generates questions. The brave reframe requires something else.
Toggle between modes to see where AI contributes to HMW — and where the distinctive reframe requires the emotional knowledge that only the research can supply.
In-depth example
The same problem, reframed two ways.
A UK government digital team is redesigning the process for notifying government departments after a death. The research is complete. The team runs a HMW session to convert insights into design challenges. The same scenario is run twice: once with a cross-functional team working from their interview notes, once with AI given a domain description.
Scenario — UK Government “Tell Us Once”
Redesigning the process for notifying government after a death — 2012
When someone dies in the UK, the next of kin is required to separately notify a dozen or more government departments: HMRC, DWP, the Passport Office, DVLA, the local council, and more. Each notification is its own form, its own process, its own moment of administering bureaucracy while in grief. A government digital service team is commissioned to redesign it. The HMW session follows a round of in-depth interviews with bereaved people and with bereavement registrars.
What the research surfaced
Bereaved families
The process asks people to navigate a bureaucratic labyrinth at the worst moment of their lives.
Bereaved families
The feeling is not “this is complicated.” It is “the system doesn’t know I’m a person.”
Bereaved families + registrars
Every separate notification resets the clock. You explain the death again. You re-enter the name, the date. You relive it with each new department.
Bereavement registrars
Registrars describe their role as “the one person the family trusts in the process” — not an administrative function.
HMW questions from the session
“How might we help bereaved people navigate their entitlements without having to understand the system?”
Correctly scoped. Specific to the problem. Opens many possible solutions.
“How might we reduce the number of separate government contacts a bereaved person has to make to zero?”
Ambitious but specific. Defines success clearly without mandating the solution.
“How might we make the government’s response to a death feel like care rather than administration?”
CHOSENThe brave reframe. Redefines what the service is for — not reducing steps, but communicating care. This became the guiding question for the “Tell Us Once” design work.
“How might we design a better form for notification?”
ELIMINATEDToo narrow. Already implies a form-based solution. Eliminated in the scope-calibration step.
What the HMW produced
The chosen question — “how might we make the government’s response to a death feel like care rather than administration?” — reframed the design challenge from reducing bureaucratic steps (a technical problem) to communicating care during grief (a human problem). Every design decision that followed — the language of letters, the tone of interactions, the single notification as a service rather than a form — was anchored to that reframe. The Tell Us Once service reduced notifications from twelve or more to one; the HMW ensured the team was designing for the bereaved person, not for administrative efficiency.
Frameworks
Where How Might We shows up.
HMW is a Define-phase tool. It maps to frameworks at the points where the task is converting research findings into a design challenge — the hinge between what was learned in Discover and what gets built in Develop.
Related methods
What to combine with How Might We.
Sources & further reading
The work behind this method.
The Art of Innovation
Tom Kelley and Jonathan Littman (2001)
The book that brought IDEO's methods into public view, including the HMW format as a structured reframing tool. Describes how "How Might We" shifts a team's posture from problem analysis to creative possibility — the shift the phrasing is designed to produce.
Change by Design
Tim Brown (2009)
The HMW method in its broader design thinking context. Brown's framing of design thinking as a human-centered approach to problem-solving situates HMW as the translation layer between empathy and ideation — converting what was learned into a question worth answering.
Sprint
Jake Knapp, John Zeratsky, and Braden Kowitz (2016)
The Design Sprint book codifies HMW as Tuesday's core exercise, positioning it as the mechanism for converting Monday's problem framing into generative design challenges. Practical guidance on running HMW at speed, with scope calibration built into the process.