How to write a how might we question, with examples

Write a how might we question by taking one user insight from your research and reframing it as an opportunity: start with "How might we," name the specific person, state the outcome they want, and stop before you name a solution. Keep it open enough to allow many answers, narrow enough to give direction.

"How might we" questions (HMW for short) come out of design thinking. IDEO popularized them and Stanford's d.school teaches them, but the format has spread far past design studios because it does one useful thing: it turns a flat problem statement into a prompt a team can actually brainstorm against. The wording is deliberate. "How" assumes a solution exists, "might" gives permission to fail, and "we" makes it a group job. Below is how to write one that works, answered as the questions people actually ask.

What is a how might we question?

A how might we question is a short, open prompt that reframes a user need or research insight as an opportunity for ideas. It sits between the Define stage of a design thinking process, where you have figured out what the real problem is, and the ideate stage, where you generate options. The problem statement says what is wrong. The HMW asks how we could fix it, phrased so that many different answers are welcome.

You will usually write one after you have synthesized user research: interviews, a journey map, an affinity map, whatever surfaced a genuine need. That need becomes the seed. A finding like "commuters miss their train because the app buries the departure time" becomes "How might we help commuters see their next departure at a glance?" Same problem, but now it is pointed at solutions instead of at blame.

How do you write a how might we question?

Start with the insight, not with a feature you already want to build. Pull one clear user need from your research and write it as a plain sentence: who the person is, what they are trying to do, and what is getting in the way. If you skip this step you tend to write HMWs that secretly describe a solution you already picked.

Then reframe that sentence with the "How might we" stem. Name the user. State the outcome in their terms. Cut any word that assumes a specific answer. A quick test: read your HMW out loud and ask whether a designer, an engineer, and a marketer could each propose a completely different idea. If only one kind of answer fits, the question is carrying a hidden solution and you should widen it.

A four-part checklist keeps you honest. One, does it start with "How might we"? Two, is there a named user in it, not just "users" in the abstract? Three, is the desired outcome stated without a mechanism? Four, could you generate ten unlike ideas from it? When all four are true, feed the question straight into an idea generator and let it produce a spread of options before you judge any of them.

What makes a good how might we question?

A good HMW is user-centered. It talks about the person and their goal, not about your roadmap or your revenue target. "How might we increase upsell conversion" is a business objective wearing an HMW costume; "How might we help a shopper feel confident they picked the right plan" is the version a team can empathize with and design for.

It is also solution-agnostic and jargon-free. The moment you write "with an app," "using AI," or "via a dashboard," you have quietly answered your own question and killed most of the ideas before anyone speaks. Strip the mechanism out. Strip the internal vocabulary out too, because acronyms and KPIs narrow a room's thinking to whatever the acronym implies.

Finally, a good HMW is optimistic and neutral in tone. It should not smuggle in blame ("How might we stop users from misusing checkout") and it should not be so cheerful it is meaningless. Aim for a plain, hopeful sentence a stranger could read once and understand.

How broad should a how might we question be?

This is where most HMWs go wrong, and it goes wrong in both directions. Too broad and you get a wish, not a prompt: nobody can brainstorm "How might we help people fight global warming," because it is the size of a UN summit. Too narrow and you have baked in the answer, so there is nothing left to ideate. The classic scoping example from design thinking teaching walks the line for you.

The right width has a feel to it once you have written a few. You should be able to name the user and the outcome, but not the artifact. If your HMW already contains the noun you plan to build, widen it by one step: ask what job that noun was doing and put the job in the question instead.

How many how might we questions should you write?

Write several. From a single big insight, most teams draft five to ten HMWs at different scopes and angles, then pick the two or three worth ideating on. One insight rarely produces one perfect question on the first try, and writing a batch lets you spot when you are circling the same solution from different sides.

A useful trick is to write the same need at three widths deliberately, the way the table above does, then choose the middle one. Another is to change the actor: "How might we help the shopper," "How might we help the store owner," "How might we help the delivery driver," all from one journey map. Once you have a shortlist, the questions each open their own brainstorm. Take the question about reducing repetitive customer support, for example: instead of only sketching help-center redesigns, you might realize you could answer those repeat questions automatically on your site, which is an idea the narrow "redesign the FAQ page" framing would never have surfaced.

Do not try to ideate on all ten at once. Run each promising HMW through a round of divergent thinking, cluster what comes back, and only then compare. If you want a menu of methods for that divergent round, the standard ideation techniques pair naturally with a well-scoped HMW.

What is the difference between a problem statement and a how might we question?

A problem statement describes the situation and the pain. It is diagnostic and it lives in the Define stage: "New users abandon onboarding at the payment step because they do not trust the site yet." It is precise, it is grounded in research, and on its own it does not invite ideas. It invites nodding.

A how might we question takes that same statement and flips it into a forward-looking prompt: "How might we help a first-time user feel safe enough to enter payment details?" The facts are identical. What changed is the grammar of possibility. The problem statement points backward at a cause; the HMW points forward at solutions and hands the team something to answer.

You need both, in order. Skip the problem statement and your HMWs float free of evidence. Skip the HMW and your problem statement just sits there, well-researched and inert. The reframe is the bridge from understanding the problem to generating options, which is exactly the handoff that design thinking ideation depends on. Once ideas exist, you can score and pick a winner on impact versus effort.

The short version

To write a how might we question, start from a real user insight, phrase it as "How might we help [specific person] [reach a specific outcome]," and remove any word that names a solution. Keep it broad enough to allow many answers and narrow enough to point somewhere, the way "Help people track their personal carbon footprint" sits between a vague wish and a pre-decided smartwatch app. Draft several, pick the best two or three, and use each as the opening prompt for a focused round of ideas.