How to write hmw statements?
Why are they called "How Might We's?"
People have been using HMW statements for years to spark innovation, but they can be done incorrectly, just like many other models. How can something so open-ended go wrong?
First, HMW statements can be too broad and vague:
The problem with vague and broad HMWs is that they give minimal direction or inspiration. These statements are meant to spark ideas you can later test with users. Without any focus, where should you start? A good HMW statement helps you focus on solving a problem.
HMW statements can also be too narrow:
When HMW statements are too narrow, we lose all the incredible, innovative ideas that can come from them. With too much focus, we are stuck on one particular solution already. We want several different ideas to test at the end, so focusing too much on one solution will limit creativity and innovation.
So how to do it right? Here are the steps I always take when generative HMW statements:
A point-of-view (POV)/problem statement allows you to focus on your users and their needs. From your research, you should identify the essential needs or pain points of your users. You can create this by combining three elements: user, need, and insight into a fill-in-the-blank.
A model to use for this is: user (fill in user) needs to (fill in need) because (fill in insight)
For example, a person expecting their first child (user) needs to set up an investment savings account (need) because they want to plan for their child's future education but are overwhelmed by choice and how to set up a proper savings account (insight).
Once you have a POV/problem statement, you can begin to brainstorm How Might We statements. Break the larger problem into smaller, actionable pieces.
If our research showed people expecting their first child need to set up an investment savings account but are overwhelmed by choice, we could break this down into a few areas:
After breaking down the problem statement/POV into smaller chunks, you start writing How Might We statements for each of these ideas.
There is a fantastic model you can use to generate HMW statements, and that is: How might we for so that .
Essentially, you put "How might we" in front of these smaller ideas.
Once you brainstorm as many HMW statements as possible, you can decide what to move forward next.
If you are in a group, you can vote on the one to use, or if you are working alone, you can either poll some colleagues or choose the one you think would be best to explore next.
HMW statements may be difficult to come up with sometimes, and you might find it challenging for yourself and others. My best advice is to break the bigger problem down and then start writing HMW in front of every aspect of the problem. It's okay to write some that are too narrow or too broad since you can assess them after. Just write!
If you are still feeling stuck, Stanford's d.school suggests ways to make the most HMW by changing the questions' goal. Here are their suggestions, plus examples for you to follow.
POV/problem statement: People who like to listen to podcasts need to be able to easily bookmark or save interesting parts of podcasts while commuting because having to find these points afterward is time-consuming and difficult.
Not all of these are perfect and even doable, but using these prompts will help if you are stuck in the brainstorming stage of writing statements! Keep it creative and exciting, then cut back on what doesn't make sense after. As in improv, always remember "Yes, and..."
After completing this unit, you’ll be able to:
A How Might We (HMW) statement turns your challenge framing into a question that can be solved. It turns problems into opportunities for generative thinking and organizes how you think about the problem and possible solutions. It starts with a call to action, and in moments of ambiguity, it guides you in how to push your design.
The format is three simple words, but it’s also intentional. How suggests that the problem can be solved, Might allows us to imagine or explore possibilities without committing to them, and We acknowledges it’s going to take a collaborative effort.
A good How Might We statement unifies the team with a common purpose, jump starts the strategy design process with a question that generates many different solution pathways, and inspires teams to think creatively. It puts designers in a question-framing mindset and makes them challenge any assumptions. It turns the problem into an opportunity and assumes that no one can solve it alone. But most importantly, it reminds designers to place humans at the center of the solution.
A key craft of the strategy designer is creating and refining HMW statements throughout the strategy design process. Because they are used to clarify the opportunity for design, they are regularly revisited throughout the strategy design process and have different uses at different phases.
A good How Might We question is essential to arriving at a good solution because it allows for focus and creative exploration. Here’s how you craft a successful HMW statement.
If your HMW question doesn’t bring you closer to solving your design, it’s useless. Use these questions to help you assess the HMW’s effectiveness.
Developing a good HMW statement isn’t easy. It’s an iterative process, requiring several rounds of reframing. When coming up with HMW questions, don’t be afraid to go for quantity and then test them out. And watch out for these pitfalls.
A pro tip for refining a How Might We statement when you face pitfalls is to:
With your How Might We statement in hand, your team has a common purpose and can use their energies to find multiple creative solutions to the design challenge. Speaking of team, we help you put together the right project team to solve your challenge in the next unit. But first, let’s see how Cloud Kicks is doing with its supply chain challenge.
At the end of a discovery, the team should come together, agree on the top things it found out, and use this knowledge to frame design challenges. To prevent individuals from suggesting their pet solutions, which might have little resemblance to the problems found, construct How might we questions that frame the problem(s) for ideation.
A How might we (HMW) question can generate lots of creative ideas. Here are some examples of How might we questions:
The How might we template was first introduced by Procter & Gamble in the 1970s and adopted by IDEO. The technique has become popular in design thinking and is used by design teams worldwide.
While writing HMW questions seems straightforward, there’s slightly more than meets the eye. The better you write them, the better the ideas that they prompt.
Some teams generate HMWs that are not specific to what they’ve learned. For example, How might we improve the user experience of the product? is not specific to what you might have uncovered in your discovery research. This question can result in ideas that don’t address the root problems and the insights you uncovered.
Once you and your team have carried out your discovery research, agree on what the top findings were. Use these to craft HMW questions, as in the example below.
It can be easy to limit your thinking and embed solutions in your HMW questions. But doing so restricts the pool of possibilities, and fewer ideas are generated. In the example below, the first HMW suggests a particular type of solution, whereas the second is agnostic about any particular solution.
The problem with the first HMW question is that only solutions related to communication will be generated. With the second HMW, further possibilities could be generated such as filing taxes automatically for users or removing multiple forms and only having one form that presents users with tailored questions based on the user’s responses.
When writing HMW questions, ask yourself if you could rewrite them in a broader way? The broader the HMW, the more ideas can be generated.
Although we want HMWs to be broad, make sure not to go too broad that you lose sight of the problem you’re trying to solve. For example, How might we redesign the submission-drafting process? would be too broad.
To avoid solving symptoms of the problems rather than the root problems themselves, ask yourself whether your HMW question focuses on the desired outcome. In the example below, the first HMW question loses sight of what we really want to achieve.
While it’s true that we want to cut costs for unnecessary contact, the high cost is a symptom of the root problem (users are unsure about the application process, and therefore call us). We really want to solve the problem of why users are calling us, which the second HMW question addresses. The desired outcome of our design efforts should be increased user confidence in the application process.
Another problem with the first HMW question is that it can result in a solution like making the contact number on the website harder to find, rather than creative solutions that increase user confidence.
In a similar vein to point 4, stating your HMW questions positively can generate more ideas and also encourage creativity.
If you find yourself using negative verbs like ‘reduce,’ ‘remove,’ ‘prevent,’ ask yourself if you can frame things more positively by using positive action verbs, like ‘increase,’ ‘create,’ ‘enhance,’ ‘promote’ and so on.
Spend time with your team writing and selecting your HMWs before you begin ideating. You can have everyone contribute an HMW; then go through the following checklist to select or improve the best version:
There’s no limit on how many HMW questions you should produce. The more you have, the more ideas you’ll garner. If you find yourself with too many, ask yourself whether there is any overlap between them and see if you can combine some into one broader HMW. The other alternative is to prioritize your HMWs in terms of their impact on the project’s success.
- Write down your problem statement.
- Draft your design challenge using the phrase “How Might We.” For that first draft, take your problem statement and add “How Might We” to it.
- Identify the impact.
- Test the design challenge.
- Refine the problem and impact.
- Try again.