How Might We? The question that turns problems into opportunities

Most organisations jump straight to solving problems before taking the time to frame them properly. The questions you ask shape the quality of the ideas you generate, and one of the simplest tools for doing this well is the “How Might We?” question. Used across business, education, government, and the arts, it turns a challenge into an invitation to explore, and helps surface solutions that a more direct approach would miss.

Let’s imagine you’ve built something, or you’re about to. Maybe it’s a new service, a website, a program, an event series, an exhibition, or a product. Maybe it’s working but not as well as you’d hoped. Maybe you’ve spoken to some customers and you’re sitting on a pile of information you’re not sure what to do with. Or maybe you haven’t done any of that yet and you’re not sure where to start.

As an example, let’s imagine that a small music venue notices ticket sales declining, particularly among under-35s. They do the right thing: they talk to people. They survey past attendees, interview regulars, and speak to people who used to come but stopped. After a few weeks they have notebooks full of observations, a stack of survey responses, and a very interesting picture of how people experience the venue.

Then everyone sits in a room and stares at each other.

This situation is more common than most people admit, and it’s not a research problem. The research is done. What’s missing is the step between gathering information and knowing what to do with it: ensuring you know what problem you’re actually solving before trying to create solutions.

Many small businesses and creative organisations skip this step. You finish your research, you have a pile of insights, and the pressure to act kicks in. So you make a call, usually based on whatever thread felt most urgent in the last conversation, and you start building. Sometimes you get lucky. More often you end up solving the wrong problem very efficiently.

There are a couple of tools borrowed from the design world that help enormously here. They come from design thinking, a problem-solving approach developed by designers and engineers and refined over decades by organisations like IDEO and Stanford’s d.school. But you don’t need to be a designer or know anything about Design Thinking to use them. They work for any kind of problem: a product that isn’t landing, a service that’s losing customers, a program that isn’t reaching its audience, a team that can’t agree on direction, and even for something new that doesn’t even exist yet.

The two tools are synthesis, which is turning raw research into a clear problem worth solving, and How Might We (HMW) questions, turning that problem into a creative brief that generates great ideas. If you haven’t done the research yet, have a read of the importance of empathetic research. This article picks up where that leaves off. Once you’ve worked through synthesis and HMW, user testing covers what to do with your ideas.

What you’ll find here:

• The design squiggle: why this feels messy
• Tame problems and wicked problems
• From research to insight: synthesis
• Can AI help with synthesis?
• Point of View statements: a useful framework
• How Might We questions: turning problems into possibilities
• Two formulas, one idea
• Writing good HMW questions
• From HMW questions to ideation
• What this looks like in practice

The design squiggle: why this feels messy

The Process of Design Squiggle, created by designer Damien Newman, is one of the most honest illustrations of what the design process actually feels like. On the left: a tangled, chaotic mess of loops and lines representing the early stages of research and synthesis, full of uncertainty, noise, and half-formed ideas. On the right: a single clean line, the final resolved design or solution. The journey between the two is the squiggle.

The reason this resonates with anyone who has done real design work is that the messy part is unavoidable. You cannot skip from the left side of the squiggle to the right by thinking harder or having a better brief. The mess is the process, and synthesis and problem definition are how you navigate through it.

Back to the music venue: they have notebooks full of observations. Some people stopped coming because parking is difficult. Others because they didn’t know what was on. Some because they felt the venue skewed older in its programming. Some because a friend had a bad experience with the ticketing system three years ago and the word spread. These aren’t all the same problem. Synthesis is the work of figuring out which of these threads actually matters, what they have in common, and what to do about it.

Tame problems and wicked problems

Not all problems are the same, and understanding the difference matters for how you approach definition.

A tame problem can be clearly stated and solved. The solution is right or wrong, and once solved, it stays solved. Scaling a recipe from 6 to 60 people is a tame problem: multiply the ingredients and adjust the logistics. Adding an extra checkout step to your website is a tame problem. Fixing a broken link is a tame problem. Once it’s fixed, it’s fixed.

A wicked problem is ill-defined, unique, and never truly solved in a final sense. Fixing one part may create problems elsewhere. There’s no template to follow and no single right answer. Why is classical art losing younger audiences? Why is attendance declining at a regional theatre? Why does a software platform that cost a fortune sit unused by most of the staff? These are wicked problems.

Most problems worth solving in design thinking are wicked problems. The music venue’s declining under-35 attendance isn’t a single fixable thing. It’s a knot of interconnected issues: programming, awareness, social norms, digital presence, pricing, experience. That’s exactly why jumping to a solution before defining the problem properly is so dangerous. There’s no algorithm to fall back on, and building the wrong solution costs real time and money.

From research to insight: synthesis

Synthesis is the process of making sense of everything you’ve gathered. It’s messy, it’s non-linear, and it feels uncomfortable in ways that are unfamiliar if you’re used to more structured work. That discomfort is normal. It’s not a sign something is wrong – it’s the squiggle doing its thing!

A simple approach that works:

Download everything first

Before looking for patterns, get everything out of your head and your notes and into one place. Post-it notes on a wall, cards on a table, a shared digital board like Miro or FigJam. One observation per note. Don’t filter yet. Just get it all out.

Look for clusters

Start moving things that seem related near each other. You’re not trying to label them yet, just noticing what belongs together. Some observations won’t fit anywhere. That’s fine.

Find the tensions and contradictions

The most useful insights rarely live in what everyone agrees on. They live in the contradictions. The audience member who says they love the venue but hasn’t been in two years. The staff member who says the software is easy to use but avoids using it. The customer who says price isn’t a factor but always waits for discount nights. Contradictions are where the interesting questions hide.

Move from observation to insight

An observation is what you saw or heard. An insight is what it means and why it matters. “Several interviewees mentioned they didn’t know what was on until the week of the event” is an observation. “By the time people find out about a show, it’s too late for most of them to actually come” is the insight. That’s the thing you can do something about.

Ask: So what?

For each cluster or theme, push past the obvious. “Under-35s aren’t buying tickets” is an observation.

So what? They don’t know what’s on.

So what? They’re finding out too late to plan around it.

So what? The venue’s entire communication strategy is built around channels that don’t reach them until the week of the show.

Now you have something to work with. The venue doesn’t have a ticket sales problem, they have a timing and channels problem. The ‘so what’ chain keeps pulling you away from the symptom and toward something you can actually do something about.

Can AI help with synthesis?

Yes, with an important caveat.

AI tools like Claude, ChatGPT, or Gemini can be very useful in synthesis, but not as a replacement for thinking. Where they help is in saving time on the mechanical parts: clustering observations, identifying recurring themes across interview transcripts, spotting language that keeps coming up, or giving you a first-pass grouping to react to and refine.

Where they don’t help is in making the judgement calls that matter: which theme is actually significant, which contradiction reveals something real about human behaviour, which insight points to a problem worth solving. Those calls require your experience, your knowledge of the context, and your understanding of the people you spoke to. An AI hasn’t met your users.

A practical approach: paste your interview notes or survey responses into an AI tool and ask it to identify recurring themes or group observations by topic. Use the output as a starting point for your own synthesis, not a conclusion. The patterns it surfaces may be useful. The insights you draw from those patterns are yours to make.

Point of View statements: a useful framework

If you’ve studied Design Thinking through the d.school at Stanford, you’ll have encountered the Point of View (PoV) statement. It’s a structured sentence that captures your user, their need, and your insight: [user] needs [need] because [insight].

Take the music venue again. Online interest is strong, people follow the venue, engage with posts, save events. But ticket sales among under-35s keep falling. Research reveals it isn’t that they don’t know what’s on. It’s that an unknown act at full price feels like a risk when there are a dozen other ways to spend that money and that night with a guaranteed good time.

The PoV that emerges: under-35s need a way to feel confident a night out is worth the cost before they commit, because the certainty of a cheaper night in outweighs the gamble on a band they’ve never heard of.

That’s precise, human, and full of tension. It doesn’t say “post more on Instagram” or “lower all ticket prices.” It points at something far more specific: the gap between cost and confidence. Every solution that follows has to address that gap. That could be solutions like more video previews of upcoming acts on the venue’s social media so people can hear the music before committing. It could be a lower-stakes way to sample the venue, a money-back guarantee on a first visit, or something else entirely. The point is the venue is getting closer to defining and solving the actual problem.

In practice, many designers and strategists use the underlying thinking without always writing it up in that exact formula. What matters is that you’re clear on:

• who you’re designing for
• what they need
• and why meeting that need matters.

Whether that clarity lives in a formal PoV statement or in a shared understanding in the room is less important than having it at all.

How Might We questions: turning problems into possibilities

How Might We (HMW) questions are one of the most practically useful tools in the design thinking toolkit. The technique was originally developed at Procter and Gamble in the 1970s and later adopted and refined by IDEO and the d.school as the standard bridge between the Define and Ideate stages of the design thinking process.

HMW questions shift you from problem thinking to solution thinking.

Let’s imagine a scenario in everyday life.

Problem thinking: I’ve locked myself out of the house.
Solution thinking: How might I get inside without breaking a window or waiting hours for a locksmith?

The first version is a dead end. It just states the situation. The second version opens up actual paths: a spare key with a neighbour, a window that’s unlocked, a locksmith app with a faster callout time, calling whoever else has a key. The reframe doesn’t solve the problem itself, but it turns “I’m stuck” into “here are some directions to try.”

Now looking at a more commercial application of solution thinking:

Problem thinking: our ticketing system is confusing and people abandon it before completing a purchase.

Solution thinking: how might we make the ticket buying experience for first-time visitors straightforward so that they can complete it in under two minutes?

The shift matters because problem thinking closes things down. It describes what’s wrong. Solution thinking opens things up and invites ideas. The same situation, reframed as a question, suddenly has ten possible answers instead of one obvious fix.

The phrasing does specific work:

“How” implies there’s a way. It’s optimistic without being naive.

“Might” creates permission to speculate. Not “how will we” or “how should we,” both of which put pressure on the answer. “Might” keeps the space open.

“We” makes it collaborative. It’s an invitation to solve together rather than a brief handed down from above.

Two formulas, one idea

There are two common ways to structure an HMW question. Neither is the correct one. They’re different framings of the same underlying thinking, and the formula matters far less than whether the question is focused, human, and open enough to generate genuinely different ideas.

The action-oriented formula

How might we [do something] for [main user] so that [problem is solved]?

The insight-driven formula

How might we [intended experience] for [primary user] so that [desired effect]?

The action-oriented version tends to work well for concrete, operational problems. The insight-driven version tends to work better for more complex, ambiguous problems where the “so that” clause does real work in holding the human goal in view.

Some examples, each grounded in a real problem type your organisation might face:

Awareness and engagement

Problem: Young adults don’t know what’s on at the venue until it’s too late to plan around it.

“How might we surface upcoming programming for younger audiences so that they can decide to attend with enough lead time to actually come?”

Software and internal tools

Problem: We spend a lot of money on software no one knows how to use.

“How might we rationalise our software tools for our staff so that we reduce costs and improve how people work day to day?”

Revenue and sustainability

Problem: The theatre relies too heavily on ticket sales and attendance is declining.

“How might we develop alternative revenue streams for the theatre so that a single bad season doesn’t threaten the whole organisation?”

Freelance creative business

Problem: Clients often don’t understand the value of the discovery phase and push to skip straight to execution.

“How might we structure our onboarding for new clients so that the research phase feels like an investment rather than a delay?”

You’ll notice none of these prescribe a solution. The HMW question is a creative brief, not a design spec. The answer to the awareness question might be a better email list, a social media strategy, a partnership with a ticketing platform, a “what’s on” SMS service, or something nobody has thought of yet. That’s the point.

Writing good HMW questions

A good HMW question is balanced. Too broad and it generates unfocused ideas that could apply to almost any problem. Too narrow and it smuggles a solution into the question and forecloses the creative space you’re trying to open.

Too broad: How might we improve our customers’ experience?

That could mean almost anything. It won’t generate useful ideas because it doesn’t point at a specific problem.

Too narrow: How might we add a progress bar to step three of our checkout?

That’s already a solution dressed up as a question. The design decision has been made before ideation has begun.

About right: How might we help first-time ticket buyers feel confident enough to complete their purchase without needing to contact us?

That points at a real problem, keeps a human being at the centre, and leaves the solution space genuinely open.

Some tests for a good HMW question:

Could it generate ten different ideas? If most ideas it generates are variations on the same thing, the question is probably too narrow.

Does it contain a verb that implies a specific solution? “How might we add…”, “How might we build…”, “How might we show…” are all signs the solution is already baked in. Try reframing around what the user needs to feel or be able to do rather than what you would have to do.

Does it keep a real person in the centre? “How might we help [specific user] do [specific thing]” will almost always outperform “how might we improve [feature or system].”

You don’t need just one. A single round of synthesis usually generates several HMW questions. That’s fine. More questions mean more angles on the problem, and in ideation you can vote on which ones to pursue first.

From HMW questions to ideation

Once you have a set of HMW questions, you have a creative brief. Each question is an invitation to generate ideas, and you can run ideation sessions, brainstorms, or structured creative exercises against each one.

A few things that help:

Vote on which questions to pursue first

If you have eight HMW questions and limited time, give each person in the room three votes and let them mark the questions they find most important or interesting. The questions with the most votes go first.

Use time as an accelerator

Take one HMW question, set a timer for five to eight minutes, and generate as many ideas as possible without filtering. Quantity before quality. Suspend judgement. The goal is volume, not quality, at this stage. Then move to the next question. This keeps ideation sessions focused and stops the conversation drifting.

Include people who don’t usually have a say

The best ideation sessions include voices from across the organisation, not just the people who will be responsible for delivery. Someone from a different part of the organisation will ask the question nobody thought to ask. We’ve seen a front-of-house usher come up with a marketing idea in a single session that ended up reshaping an organisation’s entire digital strategy. That’s not unusual. It’s what happens when you stop assuming the people closest to the problem are the best placed to solve it.

Come back to the HMW questions when you’re stuck

If an ideation session stalls or starts going in circles, returning to the question and reading it aloud often resets the room. The question is the anchor.

For a deeper look at what happens after ideation, including prototyping and testing ideas with real people, our user testing article covers how to take ideas into the real world before committing to a full build.

What this looks like in practice

When Meeum was engaged through Creative Australia’s Digital Specialist in Residence program to help Regional Arts WA build a digital home for the Regional Arts Network (RAN), the first phase was entirely research. No predetermined solution, no assumptions. We conducted stakeholder interviews with RAWA staff, board members, and all of the member organisations across Western Australia, asking what wasn’t working, what people wished existed, and what they’d realistically use day to day.

The picture that emerged was consistent: organisations wanted a central hub for documentation and communication, something simple, warm, and usable on mobile, with no learning curve. A solid foundation they’d actually log into was worth far more than a feature-rich platform nobody touched.

From that synthesis, we shaped a single HMW question to guide the rest of the project:

“How might we improve digital connections, resource sharing, and information access for the RAN, while boosting visibility and communicating their impact to a wider audience?”

That question had two parts, and they led to two different pieces of work: a rebuilt public-facing presence on the RAWA website, covered in the Regional Arts WA website case study, and a members-only intranet for the network itself, covered in the Regional Arts Network intranet case study.

The HMW question didn’t tell us what to build. It told us what problem we were solving, for whom, and why it mattered. Everything that followed came from that single, well-formed question.

The pattern is consistent across projects of very different sizes and types. Define the right problem first. Open it up with the right question. Then generate ideas.