A good How Might We question turns a specific user difficulty into an invitation to explore several solutions. Start with an evidence-backed problem, name the outcome you want to make possible, and remove any feature that prematurely dictates the answer. Then check that the question is narrow enough to guide a useful sketching session.
Within a design-thinking process, this question connects understanding a problem with generating ideas. It is a prompt for exploration, not proof that the problem exists or permission to build the first idea the team likes.
Start with a finding, not a requested feature
Write the situation in ordinary language before adding “How might we.” Who is trying to do something? What makes it difficult? What evidence supports that account? If those answers are missing, the wording exercise may simply disguise a stakeholder’s preferred feature.
For example, imagine workshop members borrowing equipment for a weekend project. In this fictional finding, they cannot tell whether a listed drill kit includes a compatible battery and charger. They ask staff before reserving. The problem is uncertainty about the kit’s usefulness, not necessarily a missing chatbot, recommendation engine, or equipment filter.
IDEO.org’s Design Kit recommends forming How Might We questions from insights, checking that they allow several answers, and adjusting their breadth. A question should create a useful starting point without choosing the solution in advance.
If your starting material is a pile of interview notes, first use research affinity mapping to establish a defensible pattern. Repeatedly rewording an unsupported claim will not turn it into an insight.
Build the question around a useful outcome
A practical draft is: “How might we help [people in this situation] achieve [outcome] despite [important constraint]?” Use this as scaffolding, then simplify. Not every question needs all three parts written out if the workshop brief already makes them clear.
For the borrowing example, try: “How might we help a member judge whether a kit contains what their project needs before reserving?” The question leaves room for better descriptions, photographs with context, a short comparison guide, or contact with staff. It does not require a particular interface.
Keep fixed operational limits in the accompanying brief. If the workshop cannot guarantee specialist accessories or provide individual project advice, say so. A prompt that silently assumes those services may generate concepts the team cannot honestly offer.
Examples: too broad, too narrow, and useful
| Draft question | Problem with the framing | More useful version |
|---|---|---|
| How might we improve equipment borrowing? | Includes finding, payment, collection, returns, and much more. | How might we help a member judge a kit’s suitability before reserving? |
| How might we add an AI kit recommender? | Chooses the mechanism before understanding the uncertainty. | How might we make the differences between suitable kits easier to understand? |
| How might we make people stop calling staff? | Defines success around the organization and assumes calls have no value. | How might we help people answer routine suitability questions while keeping staff help available for unusual needs? |
| How might we make borrowing effortless for everyone? | Promises an undefined outcome across incompatible situations. | How might we help first-time borrowers decide what information they need before choosing equipment? |
These are alternative directions, not four prompts to combine into one sentence. Select the direction supported by your evidence and the decision the team can make. A longer question is not automatically more precise.
Check the scope by trying possible answers
Before inviting a large workshop, ask two colleagues to suggest a few substantially different responses. This is a quick framing exercise, not a vote on the product. If every answer is the same button or feature, the question may already contain a solution.
If the answers range from rebuilding the workshop to changing payment providers, inspect whether the question is too broad. Bring it back to the person, situation, and decision. For the borrowing example, kit suitability is in scope; the entire business model is not.
A second check is whether the prompt changes when you remove the evidence. “Improve engagement” could be attached to almost any product. “Help a first-time borrower identify the accessories their kit includes” carries information about a real task, even before a solution appears.
Choose one prompt for the next round
Review candidate questions against three practical criteria: evidence, relevance to the current decision, and room for alternatives. Write a short reason for the selection. Avoid using a popularity vote to settle whether the underlying user need is real.
For a product discovery workshop, show the chosen prompt alongside the supporting finding and the constraints. Keep other promising questions in a visible parking area. They may deserve another session, but they should not keep changing the task halfway through this one.
A team can arrange those elements on a Mockitt canvas: evidence, candidate questions, selected question, and possible responses. Keep the evidence visually distinct from ideas. Someone arriving later should be able to see why the question was chosen without mistaking an early sketch for a committed requirement.
Move from a question to ideas you can examine
Once the prompt is stable, use a short sketching exercise such as Crazy 8s to explore different responses. Encourage changes in the underlying approach, not just the position of a button. For kit suitability, one concept could show the included parts, another could compare project requirements, and another could route unusual cases to staff.
Keep each idea connected to the outcome in the question. A visually impressive tool catalog may be irrelevant if it never explains which accessories come with a kit. Ask what the person would learn or be able to decide after seeing the proposed response. Use a concept test when the open question concerns the idea’s value, before investing in detailed interaction.
Before prototyping, identify the uncertainty that would make the idea fail. Perhaps people cannot interpret the equipment pictures, or the workshop cannot keep the information current. Use prototype assumption mapping when several unresolved beliefs need to be separated before choosing a test.
Revise the prompt when evidence changes the task
After a discussion or study, the team may learn that kit contents were not the main concern: the real difficulty was knowing whether the tools were suitable for the project’s materials. Revise the question and retain a note explaining why. Do not keep polishing a concept merely because it answered the earlier prompt well.
The useful output is one clear question, its evidence, its boundaries, and a next activity. That is enough to help a team explore deliberately without turning the wording exercise into a project of its own.