What is How Might We in UX?
How Might We (HMW) in UX is a way of phrasing a problem as an open question, such as "How might we help new users get started?", to spark ideas.
also calledHMW · how might we questions · HMW statements
Most teams are better at listing problems than solving them. A How Might We question takes a problem you found in research and bends it into an invitation. Each of the three words does some quiet work, and that is why designers keep using it.
- A How Might We question reframes a problem as an open invitation to generate ideas.
- It should come from a real research insight and avoid naming a solution.
- Aim for questions that are neither too broad nor too narrow.
- HMWs are a bridge to brainstorming and prototyping, not a result in themselves.
Why those three words
Each word has a job. How assumes there is a solution somewhere, which gives the team permission to look for one. Might says nothing has to work: this is a possibility, not a commitment, so people feel free to suggest odd ideas. We makes it a shared challenge instead of one person's problem.
Compare two framings. Users abandon the cart because shipping costs surprise them is a finding. How might we make shipping costs feel predictable? is a prompt that gets people thinking about calculators, free thresholds, early estimates and a dozen other things.
The method is often credited to the design firm IDEO and became popular through design thinking, and Google Ventures later folded it into its sprint method.
Writing a good one
The trick is getting the size right. Too broad and it produces mush. Too narrow and the answer is already baked in.
- Too broad: How might we improve the app?
- Too narrow: How might we add a progress bar to checkout?
- About right: How might we help people feel confident they are almost done when they check out?
A good HMW comes from a real insight, not from a hunch. It should be human, specific enough to inspire a few directions, and free of hidden solutions.
If your question contains a feature name, you have probably smuggled in the answer.
Using HMWs in a workshop
Start from your research. Pull out pain points, surprising quotes and patterns from interviews, then turn each into one or more HMW questions on separate sticky notes.
Cluster similar notes, then vote for the handful that feel most promising. Sticking to a few is important, since a wall of forty questions helps nobody.
Then run a brainstorm on each chosen question, giving the team a few minutes of quiet idea generation before discussing. Questions are the fuel and the brainstorm is the engine.
Keep the unchosen questions in a parking lot. Some of them will turn out to matter next quarter.
Where HMW questions go wrong
A common slip is writing them before understanding the problem. If you have not talked to users, you will just produce generic questions that could apply to any product.
Another is overly cheerful vagueness. How might we delight our customers sounds inspiring and leads nowhere.
A third is stopping at the question. HMWs are a bridge between research and ideas, not an output on their own. If you never reach prototypes and tests, you have only written pretty sentences.
When to use them
HMW fits the point where you have synthesized research and are about to ideate. It is less useful when you already know exactly what must be built, or when the real blocker is a business decision rather than a design question.
How Might We (HMW): your questions, answered
What does How Might We mean in design?
It is a question format used to turn problems and insights into opportunities for ideas. By asking "how might we" you signal that solutions are possible, that nothing is final, and that the whole team shares the challenge.
How do you write a good How Might We question?
Start from a specific user insight, then phrase it as an open question about the outcome the user wants, not about a feature. Check that it is not so broad it is useless or so narrow that it already contains the answer.
What is an example of a How Might We question?
From the insight that new users feel lost on their first day, you might write: How might we help new users feel confident about what to do first? It points toward an outcome and leaves room for many different solutions.
When do you use How Might We in the design process?
Use HMW after you have gathered and synthesized research but before you start generating solutions. It sits between defining the problem and ideation, helping the team turn findings into prompts for brainstorming.
How many HMW questions should you write?
Write as many as you like during synthesis, often dozens, then narrow to three to five to explore. Too many questions scatter attention, so group similar ones and vote on the most promising.
More quick answers
Who invented How Might We?
The phrasing is widely associated with Procter & Gamble in the 1970s and was popularized in design by IDEO. Exact origins are debated, so treat the attribution loosely.
What is the difference between a problem statement and an HMW?
A problem statement describes what is wrong and for whom. An HMW turns that into an open question that invites ideas.
Is HMW part of design thinking?
Yes. It usually appears in the define phase, between empathizing with users and ideating solutions.
Can HMW questions be used outside design?
Absolutely. Product, marketing and operations teams use them to frame challenges, though they work best when tied to a real insight about people.
What should come after How Might We questions?
Brainstorming and ideation sessions where the team generates many possible answers, followed by selecting ideas to prototype and test.
A problem statement in UX is a short, clear description of the user problem a team wants to solve, who has it and why it matters, written before design.
Brainstorming in UX is a structured group session where a team generates many ideas for a design problem before judging or choosing between them.
Ideation in UX is the stage of the design process where a team generates and explores many possible solutions to a clearly defined user problem.
Design thinking in UX is a problem-solving approach that starts with understanding people, then defines the problem, generates ideas, and tests prototypes.
Pain points in UX are the specific problems, frustrations or obstacles that users run into when trying to reach their goals with a product or service.
Found this useful? A GitHub star helps other designers find it.