Design Cycle with Lean UX
As mentioned earlier, Lean UX starts with finding solution to the problem and then measuring the feedbacks and enhancing the previous solutions based on these feedbacks.
Problem Statement & Assumptions
As I mentioned in 4 Common Mistakes UX Designers Should Avoid During Product Design Process, whenever your team encounters a problem statement, focus on “Why” and not “How”. This will guide you to form assumptions.
An assumption is formed out of the given problem and is assumed to be true. Each individual of your team (collaborative) comes up with their own solution to the given problem out which assumptions are created. These assumptions can be based on the answers to — the type of users who will use the product or situations where your product will be used or uncertainties that might hamper the use of the product and so on.
Diverse teams will be able to come up with multiple answers to the above cases. This suggests the need of prioritizing the assumptions based on — the level of knowledge of the problem you have and the level of consequences that might occur in case the assumption goes wrong. Assumptions with high risk associated with them or the ones, your team has little knowledge about have high priority.
Also, it’s quite obvious that, the assumptions can prove to be wrong at some time in future but they can be changed whenever it happens.
After brainstorming on problem statements and amalgamating different ideas from your team members, you create hypotheses. The hypotheses are used to test your assumptions.
As stated by Interaction Design Foundation, you state a belief, its importance and the personas it is important to. Then you talk about your expectations and a final result that will prove your belief.
For example, “We believe adding one click signup using Facebook will be a useful feature for busy users who have Facebook account as it will save their time. This will increase our user signup rate by 20%.”
In the above example, belief is adding one click signup using Facebook will be useful; personas are busy users who have Facebook account; importance is will save user’s time; expectation is will increase our sign up rate; and result that will prove belief is increase signup rate by 20%.
One of the positive aspect of writing hypothesis is you can conclude that you are heading in the wrong way if at any time you are unable to find any way to prove your hypothesis.
MVP (Minimum Viable Product)
After your team completes the hypotheses for the assumptions, you start with the Minimum Viable Product or MVP.
According to Wikipedia,
MVP is a product with just enough features to satisfy the early customers and to provide feedback for future updates.
This definition brings us back to where we started — build, measure, learn. You build a MVP using all the ideas your team brainstormed and the hypotheses created, then ask your users for their valuable feedbacks and finally, use those feedbacks to update your assumptions and eventually the product.
MVP doesn’t just comprise of few features but instead, it comprises of some features that are usable, solve the problems of the user and have some UX attached to them.
MVP can also be a Low fidelity (Lo-Fi) prototype for example, paper prototype or digital prototype which your users can interact with and view different screens as a result of there actions.
In Lean UX, the starting point is having a clearly written hypothesis statement. This gives your entire team a clear focus for their work. It keeps everyone aligned and sets the right constraints. In order to arrive to a well written hypothesis statement here are some of the steps:
- Declare Assumptions – A high-level declaration of what is believed to be true.
- Hypothesis – Specific descriptions of assumptions that target your product
- Outcomes – Metrics that can help validate your hypothesis. These can be both qualitative and quantitative
- Personas – Users for whom we are trying to solve the problem
- Features – The product changes or improvements that may solve our problem
First, based on specific user and business assumptions you want to write a problem statement using the follow template:
[Our service/product] was designed to achieve [these goals]. We have observed that the product/service isn’t meeting [these goals], which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based [these measurable criteria]?
Next, you want to come up with some user assumptions by asking the following questions along with your team:
- Who is the user?
- Where does our product fit in hi work or life?
- What problems does our product solve?
- When and how is our product used?
- What features are important?
- How should our product look and behave?
After stating the assumption for both your users and prioritizing them based on level of risk. The final step is to write a hypothesis statement using the following format:
We believe [this statement is true].
We will know we’re [right/wrong] when we see the following feedback from the market:
[qualitative feedback] and/or [quantitative feedback] and/or [key performance indicator change].
Most of the time the main hypothesis can be hard to test when building out specific features. To break the hypothesis down further, you can create sub-hypothesis to test specific features using the following format:
We believe that
[doing this/building this feature/ creating this experience]
for [these people/ personas]
will achieve [this outcome].
We will know this is true when we see
[this market feedback, quantitative measures, or qualitative insights].
Once your hypothesis statements are written. The next step includes deciding on the Key Performance Indicators that can validate your hypothesis for each feature build. This should again be done collaboratively. I’ll talk more about how to determine the right KPI to measure success in the next post. Stay tuned!
Lean UXProduct Management