Framework ⚡ Medium

How Might We

Three words that turn problems into possibilities — the reframe that unlocks creative problem solving.

Ideation Problem Framing Design Sprints Workshop Facilitation Creative Thinking Collaborative Design

01 — TL;DR

Two sentences.

How Might We (HMW) is a problem-reframing technique — originating at Procter & Gamble in the 1970s and popularised by IDEO and the Stanford d.school as a cornerstone of design thinking practice — in which insight statements, user pain points, and design challenges are reformulated as open questions beginning with "How might we…," where "how" signals that solutions exist to be found, "might" signals that any idea is worth exploring without immediate judgement, and "we" signals that the challenge belongs to the whole team rather than to any individual. For product designers and design teams, HMW questions serve as the bridge between research and ideation: they transform raw observations about user problems into productive creative challenges that are specific enough to generate relevant solutions but open enough to avoid presupposing the form those solutions should take.

The technique's power comes from its calibration mechanism — the ability to make a HMW question wider (more conceptual, more open) or narrower (more specific, more constrained) depending on the creative space the team needs. A HMW question that is too narrow ("How might we add a progress bar to the checkout flow?") presupposes the solution and closes down creative exploration. A HMW question that is too wide ("How might we make users happier?") provides no useful direction. The productive middle ground — "How might we make users feel confident about their decision at checkout?" — is specific enough to be actionable but open enough to invite solutions ranging from copy changes to interaction design to trust signals to process redesign. Finding this productive middle ground is the core skill the HMW technique develops.

02 — When to Use

Apply this when…

→ A research synthesis session has produced insight statements or affinity clusters and the team needs to convert insights into design challenges before ideation begins

→ A design sprint is being run and the team needs a shared HMW question to work from — Google's design sprint methodology explicitly uses a single HMW question as the sprint challenge

→ A team is generating solutions prematurely — jumping to "we should build X" before the problem has been properly framed — and a HMW reframe can slow the process down productively

→ A problem statement has been written but feels either too broad or too constrained — the HMW calibration exercise can help the team find the right level of specificity

→ A workshop needs a structured opening question that will generate diverse creative responses from a mixed group of participants

→ A stakeholder-defined requirement feels like it is presupposing a solution — converting it to HMW format often reveals the underlying user need more clearly

When NOT to apply it

Skip it when the team is in execution mode and the problem is already well-defined — HMW is a divergence tool for definition and ideation, not a refinement tool for delivery. Skip it when the solution space is genuinely constrained by technical, legal, or safety requirements that make open-ended exploration inappropriate. Skip it when the team is experienced and has already done effective problem framing — HMW is most useful when teams are struggling to frame, not as a ritual applied regardless of need. Skip it when time is too short for genuine divergent exploration — a HMW session with no time for actual ideation is a wasted exercise.

03 — How It Works

The mechanism

How Might We works by changing the grammatical and semantic structure of a problem statement in a way that changes the cognitive mode of the people engaging with it. A problem statement ("Users are abandoning the checkout") describes a situation — it invites diagnosis. A HMW question ("How might we make users feel confident enough to complete checkout?") invites solution generation. The question form activates a generative cognitive mode rather than an analytical one, and the careful calibration of the question's scope determines how constrained or open that generation is.

The underlying practice — IDEO, Stanford d.school, and Google Design Sprints

The HMW technique was developed at Procter & Gamble by Min Basadur in the 1970s and adopted and popularised by IDEO in the 1980s and 1990s as part of their human-centred design process. The Stanford d.school embedded it as a core design thinking tool, and Jake Knapp's Google Design Sprint methodology — documented in "Sprint" (2016) — uses a single HMW question as the central challenge that an entire five-day sprint team works to answer. The technique's widespread adoption across design, innovation, and product development reflects its practical utility: simple enough to explain in two minutes, structured enough to produce consistent results, and flexible enough to apply to any type of design challenge.

What it means in practice — the HMW anatomy and calibration

A well-formed HMW question has three properties. It contains a verb that describes the user experience being designed for rather than the feature being built ("feel confident" not "see a progress bar"). It avoids presupposing the solution — the question describes the desired outcome, not the mechanism for achieving it. And it is calibrated to the right level of specificity — neither so broad that it provides no direction nor so narrow that it closes down the creative space. The calibration exercise is the most practically useful skill in HMW practice: take any HMW question and practice making it one step wider (remove a constraint) and one step narrower (add a constraint) to understand the range of creative space available around the current formulation.

The counter-intuitive nuance — more HMW questions is usually better than fewer

The most common HMW mistake is treating it as a process of finding the one right question. In practice, HMW sessions generate many questions — often 20-50 in a well-run workshop — and the value comes from the range and variety of questions generated rather than from any individual question. Generating many HMW questions forces a team to look at the same problem from multiple angles: the user's emotional experience, the technical constraint, the business context, the social dynamic. The best HMW questions often come from unexpected angles. The selection of which HMW question to take into ideation is a separate and important decision, but it cannot be made well without a rich set of candidate questions to choose from.

How to measure it — question quality and ideation output breadth

HMW quality produces two measurable outcomes in a design process. Question calibration quality measures whether the selected HMW question is generating diverse, relevant solutions in ideation — a well-calibrated question produces solutions that vary in form while remaining relevant to the challenge; a poorly calibrated question produces either very narrow solutions (too specific) or solutions that have no clear relevance to the user problem (too broad). Ideation output breadth measures the range of solution types generated in the ideation session — a good HMW question should enable solutions spanning copy, interaction design, information architecture, and process design rather than converging on a single solution type.

HMW + POV — the Define-to-Ideate bridge

How Might We and Point of View (POV) statements are complementary tools used in sequence. A POV statement captures a specific user, their need, and the insight behind why that need exists: "[User] needs [need] because [insight]." A HMW question is derived from a POV by asking what design challenge the insight implies: if the insight is "users feel overwhelmed by the number of choices at checkout," the HMW is "How might we make the decision at checkout feel simple rather than overwhelming?" POV statements are convergent (capturing a specific insight); HMW questions are divergent (opening the creative space implied by that insight). Used in sequence — research → affinity mapping → POV → HMW → ideation — they form the Define-to-Ideate bridge in the Design Thinking process.

04 — Real Example

Airbnb's "How might we make any guest feel at home?" and the trust reframe

Airbnb's early growth challenge was fundamentally a trust problem: potential guests were reluctant to stay in strangers' homes, and potential hosts were reluctant to let strangers into their homes. The product team's initial framing of this challenge was narrow and feature-focused — how do we add better verification, better reviews, better insurance? These framings presupposed solutions in the trust infrastructure category.

The reframe that produced their most impactful early solutions came from a different HMW question: "How might we make any guest feel at home in any space?" This question shifted focus from systemic trust infrastructure to the emotional experience of the guest — what does "feeling at home" actually require? The question opened up a solution space that included photography quality (professional photographs of listings dramatically increased booking rates, because guests could feel confident about what the space looked like), personal profiles (hosts and guests with detailed profiles felt more like real people than anonymous strangers), and the messaging system (the ability to communicate with a host before booking reduced anxiety about the unknown). None of these solutions were obvious from a "how do we build better verification infrastructure?" framing — they emerged from the emotionally-focused HMW reframe.

Airbnb · 2008–2010 · Trust-problem reframe

Emotional HMW reframe opens solutions a feature-focused framing closes down

Trust reframe → photography + profiles + messaging

05 — In the Wild

Test yourself & see real examples

No examples yet — be the first.

Spotted a product where the solution clearly came from a well-framed creative challenge — where the design feels like it is answering a human question rather than implementing a feature spec? Or one where the design is technically correct but missing the point of what users actually need? Submit what you observed.

✓ Reviewed before publishing ✓ Your name on every example you submit ✓ Violation or fix — both welcome

Seen HMW applied well or a product clearly answering the wrong question? Help grow the evidence base.

06 — Common Mistakes

Where teams go wrong

✗ Writing solution statements disguised as HMW questions. The most common HMW mistake is embedding the solution in the question — "How might we add a progress indicator to the onboarding flow?" when the actual challenge is "How might we help users understand where they are in the onboarding process?" The first presupposes a progress indicator; the second opens the creative space to step counters, visual maps, conversational confirmation, and any other mechanism. Diagnostic: if the question can only be answered by one type of solution, it is a solution statement in disguise. A well-formed HMW should be answerable by at least three meaningfully different solution types.

✗ Setting the question scope too early in a group session. Teams frequently spend their HMW time debating and refining a single question rather than generating many questions and selecting from them. The generative phase and the selective phase should be explicitly separated: first generate as many HMW questions as possible without judgement (diverge), then evaluate and select the most productive question (converge). When teams conflate the phases, they debate the first question proposed rather than exploring the range — often ending up with a mediocre question no one objected to rather than the best question from a wider set.

✗ Ignoring the insight that generated the HMW question. HMW questions are most powerful when grounded in a specific research insight — a direct observation, a usability pattern, an interview finding. When generated in the absence of insight ("let's brainstorm HMW questions about checkout"), they reflect the team's assumptions about the problem rather than observations about actual user experience. The sequence matters: insight first, HMW second. A HMW derived from "users told us they feel embarrassed when their card is declined in front of others" produces different solutions than a HMW derived from "checkout conversion is low."

✗ Generating HMW questions and never returning to them. A well-run HMW session produces 20-50 questions, of which the team selects 1-3 to take into ideation. The unselected questions are frequently discarded rather than retained as a resource. In practice many of them are useful for later sprint phases, for framing different parts of the design problem, or for future projects addressing adjacent problems. Capturing HMW questions systematically — in a shared document, project wall, or research repository — and returning to them when the design direction changes multiplies the value of the original session.

07 — Variations & Related Principles

Connected ideas

How Might We is the ideation bridge in the design thinking toolkit. Its closest relationships are with the frameworks that precede and follow it in the design process.

The most important pairing is How Might We with a genuine research insight. The technique is a bridge — its value depends entirely on what it is bridging from. A HMW question grounded in a specific, surprising research observation will generate more creative and more relevant solutions than one generated from assumptions or generic knowledge of the problem domain.

08 — 10-Min Exercise

Run it right now

⏱ 10 minutes · Solo or with your team · No prep

The HMW Reframe Exercise

1. Write down one user problem you are currently working on — a specific observation from research, a pattern from user feedback, or a recurring support ticket theme. Write it as a plain observation: "Users are doing X" or "Users struggle with Y."

2. Convert it into three HMW questions at three different levels of specificity:

Narrow (close to observation, close to a specific solution): "How might we [specific mechanism] so that [specific user] can [specific action]?"

Medium (the user's experience and goal, not the mechanism): "How might we [user experience outcome] for [user] when [context]?"

Wide (the underlying human need, not the product context): "How might we [fundamental human need] that [insight about why this matters]?"

3. Read all three versions. The narrow version probably sounds like a feature request. The wide version probably sounds too abstract to act on. The medium version is likely your productive HMW question.

4. Now take your medium HMW question and generate five radically different types of solutions — not five variations of the same idea, but five genuinely different mechanisms that could answer the same question. If you cannot generate five different solution types, the question is probably still too narrow.

10 minutes