How Might We (HMW) questions reframe problems as opportunities. They're short enough to write on a sticky, optimistic enough to invite creativity, and constrained enough to keep solutions focused. Snap the wall of HMWs and the ideation begins.
Run an HMW session after customer research, after a problem-identification exercise, or at the start of a design sprint to bridge from insight to ideation. HMW questions are the currency of the design sprint's Monday session — they transform raw observations into solvable design challenges.
HMW works at any scale: one person generating prompts for a solo design session, or a full team covering a wall with HMW stickies from a customer research debrief.
The raw material: a user quote, a pain point, a research finding, or a problem statement. Write the observation on one sticky before writing the HMW. 'Users forget their action items within 24 hours of the meeting' is an observation. The HMW translates it into an invitation to solve.
The reframed version: 'How might we make action items impossible to forget in the first 24 hours?' One HMW per sticky. The statement should be open enough to invite multiple solutions but specific enough to exclude irrelevant ones. Aim for 3–5 HMW questions per key observation.
Check each HMW against two failure modes: too broad ('How might we improve the meeting experience?') and too narrow ('How might we add a push notification 24 hours after a meeting?'). Too broad invites unrelated solutions; too narrow is already a solution pretending to be a question. Rewrite both extremes.
After generating the full set, vote on the most promising HMWs — the ones that feel most actionable and most aligned with the core user problem. The top-voted HMWs become the prompts for the next ideation session or design sprint sketching phase.
Write each observation, research finding, or pain point on a sticky and post it on the board. These are the raw inputs — don't filter them yet.
For each observation, write 1–3 HMW questions on separate stickies. Post each HMW above or beside its source observation. Don't evaluate — quantity first. Aim for at least 30 HMW stickies in a typical research-debrief session.
Read each HMW aloud. Flag any that are too broad or too narrow. Rewrite them. A good test: 'Could this HMW be answered by ten completely different solutions?' If yes, the constraint is about right.
Each participant gets 5 dot votes. Vote on the HMWs that feel most important and most inviting. Cluster the top-voted HMWs by theme. These clusters become the focus areas for the next ideation session.
Snap the HMW wall with BoardSnap before the ideation begins. The AI reads every HMW statement and outputs a prioritized list — the design challenge brief that guides the ideation and sketching phases.
A wall of HMW stickies is one of the most valuable artifacts a product team produces — and one of the most commonly lost. The HMW questions represent the synthesis of customer research into design intent. They should be preserved and reused across sessions, not photographed and forgotten.
BoardSnap reads every HMW sticky and outputs the full set as a structured list — organized by theme cluster, with the top-voted questions marked. The design challenge brief becomes a reusable document that feeds the crazy eights session, the solution sketch session, and any future ideation that tackles the same problem space.
The HMW phrasing was developed at Procter and Gamble in the 1970s and popularized in design thinking by IDEO and Stanford's d.school. Google Ventures made it central to the design sprint framework, which significantly increased its adoption across product and UX teams.
Twenty to fifty, depending on the volume of research input. Too few and you haven't fully explored the problem space. Too many and the voting becomes unwieldy. For a typical user research debrief with 5–10 key observations, aim for 30–40 HMW stickies, then vote down to the top 5–10 for ideation.
Yes — an HMW that points to a solution the team has no capacity to build is a distraction. A useful HMW is ambitious but not magical. 'How might we make action items appear in the user's calendar automatically?' is ambitious but buildable. 'How might we make action items telepathically broadcast to team members?' is creative but not actionable. Keep the 'might' grounded in possibility, not fantasy.
Both. HMW questions can be generated from raw observations (bottom-up) or from a predefined problem statement (top-down). In a design sprint, HMWs are generated from observations during the expert talks on Monday, then clustered and voted on to define the sprint target. Outside a sprint, they work from whatever research input you have.
No exporting, no transcription. Snap the board, get the action plan.