If you're feeling lost after rounds and rounds of user interviews and usability testing sessions and just need to rise above water for clarity of direction, this might be a useful article for you.
Why create a How-Might-We statement?
A How-Might-We statement is a common tool used to anchor the team on a north star for the product. A north star strategically unfolds feature ideas, ranging from content flows and structures to small nifty UI designs that enable delightful experiences. It is simply a statement that begins with a "How Might We".
What made me use this tool?
The multi-disciplinary team (where I led the experience vision) had to take a step back and ask ourselves the existential question of why we exist. We had gone through about 15 usability testing sessions with users and found recurring issues that questioned the "Viability" of our "Minimum Viable Product". We were just not meeting the mark. We had to push to pause button and step away from the build-build-build-ship mentality. (I recommend reading the book The Build Trap)
The issues were clear, but we were hungry for clarity on how to move forward. I tuned into my own compass and thought from a lens of outcomes. I repeated my own UX mantra - "a product is successful when it is used, usable and useful". Grounded on the mantra, I proceeded to craft a How-Might-We statement by allowing intuition to flow. What are the key words that must be included? What is our strategic approach? What is the secret sauce to make the product a must-have? These were questions that guided my outcome-based thinking.
Below is an image of the HMW statement I crafted for our product (a public search platform for rules and regulations in the Singapore finance/fintech industry) and how I associated parts of it to answer the metrics of used, usable and useful.
To elaborate a bit further, here is my understanding of the 3 metrics.
1. Product is used
Product must first and foremost, be used. This is usually based on market/business need. Is there a need for your product and is your design giving at least a hint that it can fulfill the need. Are you showing the value upfront? Or will the user bounce out just after taking 30 seconds to figure out what you are all about.
Once you provide an impression that convinces them to try it out, a user will attempt to use it. Even if the product is hard to use, a user with a strong need will make the effort to get something out of the product. If the user is unable to achieve their goal even with all the effort mustered, then the product has failed. My team faced such a failure when we realised that layman people were not able to read legalese wording fom the regulatory content that we pulled into FinReg.
2. Product is usable
When the product fulfills the basic utility of being used, it needs to be designed to be usable. It needs to be easy to use, through intuitive navigation and content presentation that follows a user's train of thought. It needs to have the features that facilitates the user's intended workflow and, be presented in the typography and colour scheme that elicits the right feeling.
In mcase, the team needed to first translate the legal-jargon-filled content material from regulatory bodies into a categorisation that was suitable for layman startup folks. Thereafter, we needed to introduce the legal jargons to users in a way they can draw the relevance to their business context.
3. Product is useful
Does the product change the lives of your user? This is the last and most difficult to achieve metric to score. This is the metric that differentiates good from great products. This is the metric that will get a user to switch from their current solution to yours. The success here is that through a short period of time (usually multiple uses of your product), a user can see a change in their own productivity or wellbeing.
This, for us meant that users can see our platform as trustoworthy, as they can consume the content and apply it in their business setup and conduct, and thereafter see that we are legit. This belief will make us the go-to-platform, that they will recommed to others.
Parting words
Clarity of outcomes is much more important that output. Don't get carried away and build 1000 features out of which most of them are not used. If you're losing sight of what success means to the team, then I suggest you take some time away from building and relook at the problem you want to solve and chart a refreshed direction with a How-Might-We statement.
Good luck!