Glossary

Assumption

An assumption, in the context of the LeanUX methodology, is formed out of the given problem and is a statement that is assumed to be true. Each individual of your team comes up with their own solution to the given problem from their own perception of the world, some may be fact others assumptions. These assumptions can be based on type of users who will use the product or situations where your product will be used (context) or assumed barriers of the use of the product.

Hypothesis

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%.

We believe that [doing this/building this feature/creating this experience]
for [these people/personas] will achieve [this outcome].

MVP (Minimum Viable Product)

MVP doesn’t just comprise of few features but instead, it comprises of important features that are usable, and convey the value of the product to users.

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.

Problem Statement

The team needs to have a starting point for their process. Many find it helpful to start with a problem statement. The problem statement gives your team a clear focus for their work.
It also defines any important constraints. You need constraints for group work. They provide the guard rails that keep the team grounded and aligned.
A problem statement must have the following elements, a target user, a specific context (time and place) and a desired outcome.

Validation