THINK: assumptions and hypothesis
Instead of expressing “requirements” we consider assumptions and we declare hypothesis statements. A hypothesis statement is a way of expressing assumptions in a testable form.
Reality often shows that the creators of a product or services are not sure what a user actually needs or wants, or how it should work, with regard to the user experience. But quite often organizations, or companies simply proceed with their idea for functionality or user experience, without input what the user needs (or what the user thinks about it), and without checking (testing) with the end-user throughout the development process.
Quite frankly, organizations which have been in business for many years (decades) think (with some level of arrogance) to know what the customer wants and how the experience should be – but this arrogance will bounce back with failure: an unhappy end-user will trash the product and its experience if it deemed to be unfit.
A hypothesis statement will require experiments to find out if which assumptions are right or wrong.
A first step is to list any assumptions: an assumption is a declaration of what we assume to be true. But it’s not considered a requirement, until we actually have facts and figures to support it. Assumptions comprehend both business and user assumptions. A possible way to start listing assumptions is to start from a problem statement. Problem statements are full of assumptions. When assumptions are listed, it’s crucial to select the ones that are the most uncertain.
A main principle of Lean Startup is to expose the highest risk first, so we can learn. The exercise of listing assumptions and hypothesis should be done with the whole team: everyone involved, so you can create a shared understanding from the start.
A hypothesis statement has the following format:
Note: This is a possible format, and there’s no obligation to follow this blindly, as long you understand the purpose and you have the different elements.
Outcomes (objectives) and metrics
It is essential to focus on outcomes first: what are we trying to achieve, what kind of objectives? What kind of user needs? Instead of directly thinking about features (solutions), we focus on outcomes. When creating the product, the progress will be measured against the outcomes. To be able to measure, you need to define a set of metrics. A good approach to this, is Objective-Key-Results.
Features (functionalities, stories, …)
Features exist to serve the needs that have been identified. To fulfill an outcome, you think about creating a certain feature (solution, functionality, story). It’s important to have the outcome first defined, and next think about possible features.
It is essential to know something about the customer, the end-user you’re creating the product for. Personas are a well known technique to make the end-user visible.
The clue is to approach the creation and validation of personas the lean way: personas are not the output of great research upfront, but are created and evolve like the product evolves. Personas created with lots of work upfront, and not updated afterwards are essentially throw-away personas: they become useless as soon as they are outdated, and concern a source of waste.
We prefer to create “ad-hoc” or “proto”-personas: these represent the best guess as to who is using the product and why. A proto-persona contains the information (demographics, behaviours and needs) of a certain type or segment of end-user relevant to the product being designed.
Lean UX book
Materials in this post are based upon readings on the topic of Lean UX.
Lean UX book by Jeff Gothelf.
Read more about the Lean UX cycle.
Read more about the Lean UX book.