How Might We Template for User Research

A [problem statement](/glossary/problem-statement) describes the problem: "[User] needs [need] because [insight]." A HMW question reframes that problem as a design challenge: "How might we [address the need]?" The problem statement is an input. The HMW question is the output that a team brainstorms against. You typically write the problem statement first, then generate multiple HMW questions from it.

Aim for 15-30 across the group. This is enough to get past the obvious framings (which usually account for the first 5-8) and into more creative territory. Do not try to generate 100. The exercise loses focus after 30 and returns diminish quickly.

Yes. "How might we improve the user experience?" is too broad to brainstorm against. A good HMW question constrains the problem space enough to focus ideation but leaves room for multiple solution approaches. Test your HMW by asking: "Can I imagine at least 5 different ways to address this?" If yes, the scope is right. If you can only think of one way, the question is too narrow (it contains an embedded solution).

Including metrics adds specificity and makes the question more actionable. "HMW reduce time to first value from 14 days to 3 days?" is better than "HMW reduce time to first value?" because it sets a clear target. However, do not over-constrain the metric. "HMW reduce time to first value by exactly 78.6%?" is absurd. Round numbers and ranges work best.

The selected HMW questions become the prompts for your next ideation activity. Write each HMW question at the top of a brainstorming board or as the challenge for a [Crazy Eights](/templates/crazy-eights-template) round. After brainstorming, the best ideas become hypotheses to test. The [experiment hypothesis template](/templates/experiment-hypothesis-template) helps structure those tests. Over time, your archive of HMW questions becomes a map of your product's opportunity space. ---