# Use "How might we" to ideate > Learn how to turn problem statements into How might we questions that open up ideas instead of shutting them down. Source: https://uxspot.io/how-might-we

What is "How might we"?

How might we template — the phrase followed by a blank to turn a pain point into an opportunity, with prompts to amp up the good, remove the bad, flip it, or break it into pieces

"How might we" (HMW) is an ideation technique that reframes a problem statement as an open question, turning a frustration into an opportunity for design.

By the time you reach ideation, your research has produced problem statements: clear descriptions of who your user is, what they need, and why. The trouble is that a problem statement points backwards, at what is broken. An HMW question points forward, at what could exist.

Say your problem statement reads: "Amal is a busy parent who needs a faster way to order groceries because shopping in-store takes time she doesn't have." Rewritten as an HMW, it becomes: "How might we help busy parents get groceries without a trip to the store?" Same insight, but now it invites answers instead of sympathy.

A good HMW question doesn't contain a solution — it creates space for many possible solutions. That distinction is the whole point of the technique. "How might we build a delivery app?" has already decided the answer. "How might we save parents time on groceries?" could lead to delivery, curbside pickup, a standing subscription, or something nobody has thought of yet.

Why the three words matter

The phrase sounds casual, but each word was chosen deliberately, and swapping any of them changes how a team behaves.

How assumes the problem is solvable. You're not asking "could we?" or "should we?" — those questions invite debate about whether to try at all. "How" skips the doubt and moves the team straight to searching for answers.

Might gives everyone permission to fail. "How will we" or "how can we" demand ideas that already work. "Might" lowers the stakes: an idea is allowed to be half-formed, impractical, or plain silly. In ideation, a wild idea that fails is more useful than a safe idea nobody bothered to say out loud.

We makes the problem a team effort. It's not the designer's problem or the engineer's problem — it belongs to everyone in the room, and everyone's ideas count. That shared ownership matters later, when the team has to commit to building one of these ideas.

Writing a good HMW

The hardest part of the technique is calibrating scope. An HMW that is too broad gives the team nowhere to start; one that is too narrow has already made the design decision for them. Compare these three, all written from the same grocery problem statement:

Too broad: "How might we make life easier for parents?" You could answer this with anything from meal kits to childcare reform. It's inspiring, but it doesn't connect to your research or your product.

Too narrow: "How might we add a one-tap reorder button to the checkout screen?" This isn't a question — it's a feature request wearing a question mark. There's exactly one answer, so there's nothing to ideate.

Just right: "How might we help busy parents restock the groceries they buy every week with minimal effort?" It's anchored in a real user and a real need, yet it leaves the solution wide open.

A quick test: if you can imagine five genuinely different answers to your HMW, the scope is probably right. If every answer sounds the same, widen it. If the answers span your entire industry, tighten it.

Reframing techniques

Staring at a problem statement and waiting for the perfect HMW rarely works. Instead, use these classic reframing moves to generate several HMWs from a single problem, then keep the strongest ones. Our running example: parents find the weekly grocery shop stressful and repetitive.

Amp up the good

Find whatever already works in the experience and ask how to make more of it. If parents enjoy discovering a new snack their kids love, you might write: "How might we make the weekly shop feel like discovering treats rather than restocking supplies?"

Remove the bad

Take the worst part of the experience and imagine eliminating it entirely. If the pain is rebuilding the same list every week: "How might we remove list-building from the weekly shop altogether?"

Explore the opposite

Flip the problem on its head and see what the reversal reveals. Instead of making shopping faster: "How might we make time spent on groceries something parents look forward to?" Opposites rarely become the final direction, but they shake loose ideas the obvious framing hides.

Question an assumption

Identify something everyone treats as fixed and remove it. Everyone assumes someone has to choose the groceries: "How might we fill a family's cart without anyone picking items at all?"

Break the problem into pieces

Split one big problem into smaller HMWs you can attack separately: "How might we help parents remember what ran out?", "How might we make paying effortless?", "How might we handle the items that are out of stock?" Small, specific HMWs often produce more usable ideas than one grand question.

Running an HMW session

HMW writing works best as a short, timeboxed group activity. Give everyone the problem statements and research insights, hand out sticky notes (physical or digital), and set a timer for around ten minutes. Each person writes as many HMWs as they can, one per note, working silently so nobody anchors on the loudest voice in the room.

In an HMW session, quantity beats quality — you can filter weak questions later, but you can't filter questions nobody wrote.

When time is up, post every note on a wall or board and group similar questions into themes. Read them aloud, merge duplicates, and rewrite any that smuggled in a solution or drifted away from the user.

Then narrow down. Dot voting is the usual tool: each person gets two or three votes to place on the HMWs they find most promising. Pick the HMWs that sit at the intersection of user need, team excitement, and business relevance — those are the ones worth sketching. Two or three winners is plenty; they become the prompts for your sketching exercises, where the questions finally turn into concrete ideas on paper.

Takeaways

"How might we" turns problem statements into launchpads: solvable, safe to attempt, and owned by the whole team.

Write your HMWs from real research, keep them broad enough for many answers but narrow enough to start, and use reframing techniques to generate options before you commit. Then let the team vote, take the best few into sketching, and start answering the questions you just asked.