Learn how to build a validation board, problem statement and broad hypotheses
What
After concluding your secondary customer research and interviews, you'll have findings. Your findings at this stage aren't empirical, and they're still just unproven observations. You'll need to build a problem statement based on what you observed. Then you'll need to prioritize your team's unknown and riskiest assumptions. Place these assumptions into what we're calling a validation board. Your team will keep returning to this board as it progressively creates hypotheses that solve the customer's problem.
Why
It would help to have a shared understanding and agreement of your findings and assumptions. Building a solid foundation underneath your problem statement and broad hypotheses is critical. It's vital to move ahead together here. The more inclusive this is, the better solution ideas you'll get in the subsequent Design Studio. Because people will have shared ownership in the outcomes because they believe in the problem they're trying to solve.
How to do it
Step 1. Write the problem statement
As a team, use this template via 18f, to write your problem statement.
We have observed that [product/service/organization] isn't meeting [these goals/needs], which is causing [this adverse effect]. How might we improve so our [product/service/team/organization] is more successful based on [these measurable criteria]?
If you have trouble writing a narrow problem statement, brainstorm all the project's possible goals, needs, and measurable criteria first. Then work as a group to select the most important ones and build your problem statement from there. This process may reveal multiple problem statements. Your team will need to work to figure out which problem to pursue and how to scope the statement, so there are some constraints around what the team is taking on.
Step 2. Identify assumptions
Thinking about your problem statement, map out all your assumptions (everyone should contribute—reject no ideas) about needs, users, and potential solutions. These are suggested brainstorming questions that help get at some common assumptions:
Identify need solution assumptions
- I believe the following customer wants and needs can be solved by doing the following:
- I think the #1 value a user wants to get out of my service is:
- I think the user can also get these additional benefits:
- I think I will acquire the majority of my users through the following:
- I think my biggest product risk is:
- We will solve this through the following:
- What systems will our solution need to interact with?
- What other assumptions do we have that, if proven false, will cause our project to fail?
Identify customer assumptions
- What problems does our product solve?
- When and how is our product used?
- What features are important?
- How should our product look and behave?
- What are our design principles?
- What will the touchpoints be?
Step 3a. List assumptions
- Unknown assumptions: The ones your team is most unsure about — to learn quickly about possible risks.
Step 3b. List the riskiest assumption
- Risky assumptions: Assumptions that — if proven wrong — would cause the project to fail.
Step 4. Write the broad hypotheses
Then as a team, write out your broad hypotheses using this structure via 18f.
We believe that [doing/creating/building this] for this [proto-persona/persona] will result in [this outcome]. We'll know we're right when we see [this signal/metric].
Remember, to be successful; you must have real qualitative/quantitative KPIs that you can measure with the necessary tooling in place. *KPIs can be everything from a system usability scorecard measurement, an NPS UX score, a shift in sentiment after establishing a baseline, a comprehension or task analysis assessment, and more.
Step 5. Keep pivoting through assumptions
Once you've ideated against solutions that solve your problem statement and broad hypothesis, repeat the same steps, picking the following riskiest assumption to solve.
To learn more, see my team's UX research write-up for MURAL.
