How Might We Statements: From Insight to Open Question

A How Might We (HMW) statement is an open question that turns a user need into a starting point for ideas. It names a problem worth exploring and leaves room for more than one answer. The IDEO Design Kit method starts with an insight and asks a team to reframe it as a question.

Imagine a fictional user who says, “I never know if my request went through.” A draft prompt could ask, “How might we help people feel sure their request was received?” A second user in the same made-up study says they already get a clear email. The team needs to keep both accounts in view before it chooses a prompt.

Atlas can help compare selected interview notes and cite the lines behind a draft insight. The team still writes and chooses its HMW question.

What a How Might We statement does

“How might we…” turns a finding into a question for ideation. How asks about possible routes. Might leaves space to explore. We gives the team a shared task. The wording does not promise that a solution is known.

The Stanford d.school tool frames these questions as ways to look at a challenge from several angles. The Nielsen Norman Group guide places them after discovery work, when a team has agreed on the problem it wants to address.

A useful HMW has two anchors: a need supported by research and an outcome broad enough to invite varied ideas. “How might we add a green confirmation banner?” names one feature. “How might we make it easier to know that a request arrived?” keeps the need in view while leaving room for a banner, a receipt, or a process change.

The example in this article is fictional. It shows how to check wording; it is not a finding about real users or a tested product.

Start with a checked user insight

Keep the user's words apart from your reading of them. “I never know if my request went through” is an observed statement in the fictional transcript.

“People need a clear receipt” is an interpretation. “Add a green banner” is a proposed answer. Each step carries a different level of certainty. Keep the evidence beside each step.

Open the full source around a quote. Was the speaker using a phone, paper form, or web page? Did they later find a receipt? Did another person describe a different path? A short quote can start a question, but it cannot tell you how common the issue is.

The Washington State service-design guide says to ground HMW prompts in real needs and to try several versions. In a research team, keep the note or transcript line beside the insight so reviewers can check what was said.

An affinity-mapping guide covers the earlier job of grouping related observations. A cluster can suggest a theme.

The team should still inspect the source lines and accounts that do not fit. The prompt should reflect a checked need rather than the largest pile of cards.

Keep the question open and focused

A too broad prompt such as “How might we improve service?” gives a team little to work from. It could mean speed, trust, access, or a dozen other needs. Name the user, moment, and desired outcome more clearly.

A too narrow prompt smuggles in one answer: “How might we show a bright message after every click?” It tells the team what to build before it has explored other routes. Ask what the message was meant to achieve, then write the question around that outcome.

An open but focused prompt might be: “How might we help first-time applicants know when their request has reached the team?” It points to a group, a moment, and a need. The team can still think about email, on-page feedback, staff follow-up, or a simpler form.

The NN/g guidance recommends starting with problems found in discovery and avoiding a favored solution.

IDEO's method steps ask whether the question allows several answers without becoming so broad that the starting point disappears.

Revise a prompt from source evidence

The table below uses invented interviews U-01 through U-03. Line numbers are made up. The users and their request flow are teaching examples. The table shows why a prompt should keep both the main insight and its limits visible.

Table 1: The team should not merge the first and third rows without thought. One person may need proof of receipt; another may need a clear next step. These could lead to two HMW prompts. The second row warns against a claim about all users.

A useful decision note could say: “We will use the receipt question for a first ideation round. U-01 supports it. U-02 shows that some people already get a clear email. We will check device and flow before treating this as a wider pattern. We will keep the next-step question as a separate prompt.”

The note does not rank ideas or declare a winning feature. It records why the wording is narrow enough to be useful and which evidence could change it.

Write several frames before choosing

Write more than one question from the same checked insight. Try the desired outcome, the user's moment, and the barrier.

For the invented receipt example, one frame asks about knowing that the request arrived. Another asks about what to expect next. A third asks what would make the handoff feel clear.

Compare the frames with the source. Which one preserves the user's problem? Which one leaves room for different answers? Which one relies on a guess the team has not checked? The Stanford worksheet offers ways to vary a view of the challenge before a group starts generating ideas.

The team can keep several prompts if the evidence points to distinct needs. It can also mark one as provisional. A negative-case analysis helps when a user's account challenges the draft insight. The goal is to keep a useful question without hiding the exception.

Choose the prompt with the team before ideation. Record the source lines, the chosen wording, and the reason. If people disagree about what the interview means, record that too. A workshop vote cannot settle a question that rests on a misread quote.

Inspect the source in Atlas

Add permitted interviews and research notes to one Atlas project. In chat, select the small source set with @.

Ask: “For this draft insight about request receipts, cite supporting and contrary lines. Keep each speaker separate. Show where the text is silent about device, timing, or what happened next.”

Open the citations and read nearby lines. Check whether a researcher note has been mistaken for a user's words. Compare U-01 with U-02 before turning “unclear receipt” into a team claim. The Atlas source-synthesis guide describes selected-source comparison with inspectable citations.

Save the checked insight, source links, counterpoint, and human-approved HMW wording in a project note. Atlas can assist with source Q&A and notes.

It does not provide a dedicated HMW workshop, select a prompt, or establish team agreement. The research-implications guide covers the later step of stating what a finding may mean for a decision.

Atlas citation-inspection view. The pictured paper does not support the fictional applicant quotes or HMW candidates.

Keep selection with the team

An HMW prompt is a frame for ideas. It is not a measure of how many people have a need, a finding that a design will work, or proof that the team chose the right problem. Those claims need their own research and tests.

The NN/g method guide ends with team review before ideation. The Washington State guide similarly asks teams to test and revise the question. Both put selection in the hands of people who can examine the context.

Atlas cannot recruit participants, assess whether an insight speaks for the target group, run a workshop, or decide the final wording. A cited comparison can make the team's reasoning easier to check; it cannot replace that reasoning.

Take a checked prompt into ideation

Give the team the chosen HMW question, the short source-backed insight, and the counterpoint. Ask for several ways to meet the need. Keep the question visible as the group explores ideas so a favored feature does not quietly replace the user's problem.

If new research changes the insight, rewrite the prompt and note why. The strongest handoff is a question that invites new options and still lets a reviewer trace it back to what users actually said.