In traditional UX design projects, teams were often given requirements and then expected to create deliverables.

In Lean UX, you don’t create deliverables. Instead, you create outcomes.

You don’t start with requirements. Instead, you start with assumptions.

You create and test hypotheses. And at every step, you measure the outcome.

Lean UX radically changes the way you approach your work. It helps you achieve outcome-focused work. And the key tool to achieve it is: hypothesis statement.

A hypothesis statement is the starting point for any project. It is the simplest way of declaring assumptions in a testable format.

Here are the steps you can follow to achieve a more outcome-focused work in any given project:

1) Declare all your assumptions

As a first step, gather all your team members, including those that may belong to other disciplines but are vital to your project. Ask each member to put down his/her assumptions on the white board. It will give you a common starting point.

The motive behind this exercise is to give every member an opportunity to voice his/her opinion on how best to solve a problem. In doing so, you will possibly see a huge divergence in opinions among team members and a broad set of possible solutions. Don’t worry about it.

2) Define your Problem Statement

So far you might have team members focusing on different problems with different solutions; or solving the same problem with different solutions on the white board.

What a problem statement does is that it gives your team a clear focus. It helps you define important constraints that are essential to any group work.

A problem statement consists of three elements:

a) The goal/s of the product.

b) The problem that the business stakeholder wants to solve (and is most likely failing to do so).

c) The demand for a specific improvement in the product.

Here is a 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 on [these measurable criteria]?

It is not necessary that you will have a clear problem statement at the beginning. You revise it as you go further in the process.

But a problem statement is usually filled with assumptions. An important exercise here is to ask your team to strip off all the assumptions using this worksheet.

Remember that you can adapt or tailor these assumptions/questions depending on the stage/type of your project.

3) Prioritize your assumptions

Now you have already got your list of assumptions on the white board. Next step would be to go through them and put them in an order of priority based on their level of risk. Try and think this way: what would happen if this assumption were false? How bad would it be?

The higher the risk, the higher the priority of that assumption should be. So the assumption that poses maximum risk to your project should be tested first. This does not mean that the rest of the assumptions won’t be tested. You will have to maintain a backlog and test them later as per their priority.  

4) State your hypothesis

You can’t simply test your assumptions. First you need to convert them into a format that is easier to test. That’s called a hypothesis statement.

Here’s a template:

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 measure, or qualitative insight).

In order to fill this template, you would require the following building blocks:

• Outcome

First focus on the problem you are trying to solve. You will see that you already have a few standard, larger outcomes that you want to achieve. Now try and break these into smaller parts.

For instance, let’s say you are looking to get more sign-ups for your service. Now break this broad outcome into something more specific, such as what behaviors will predict greater usage? Would increasing the number of items in your shopping cart help?

Ask your team members to create a list of small, specific outcomes that can help you achieve the larger outcome.

• Personas

Often designers create personas to define their potential users. But if you don’t have a proper methodology to devise personas, here’s what you can use in the Lean UX process.

Create working-personas

Working-personas are created through guesswork done by team members. You start with your initial impression of users, or who you imagine your users would be. You put down the assumptions of all the team members.

And as your project progresses, you find out how accurate your working-personas are and adjust them to your actual users.

This is perhaps the fastest way to create and test personas. Instead of spending months researching and interviewing people, you simply spend a few hours brainstorming with your team and create working-personas. And as the project progresses and you gather more information, your assumptions will be validated, or not.

Use the following template to create working-personas:

In the first quadrant, you just need to fill out your potential user’s name and role. In the second one, you need to fill out basic demographic information such as age, gender, hobbies etc. The more you focus on information that predicts a certain type of behavior, the better your results would be.

For instance, whether a person owns a television may be more relevant for your product than his/her age.

In the third quadrant, you need to fill out the various frustrations that your user might be dealing with and the pain points that your product tries to address. In the fourth quadrant, you put down the potential solutions for those pain points.

Through this process, you might be able to create multiple working-personas. But eventually you must zero in on four key personas that come closest to your users.

• Features

Features are the most concrete way to achieve the outcomes that you have listed above. In the traditional design process, you usually start with features or an idea around a feature and then work backward to try to justify them. But in the Lean UX process, features appear as a result of the needs of the users and businesses.

Start thinking about features only after you have narrowed in on your outcomes and users. Ask your team members to write their ideas of features on the board and have them explain how they think it would drive the user behavior in the desired direction.  

• Gather your material

Once you have gathered all this raw material, you must organize it into a set of testable hypotheses. Use this template to create categories:

You must try and examine what solution is serving which persona. If you find that a single hypothesis drives more than one outcome, then you must split the hypothesis. You want each statement to refer to only one outcome.

The goal of this exercise is to ensure that your ideas are specific enough to carry out meaningful tests.

And once you are done with your list of hypotheses, you are ready to move on to the next step: MVP.

(Reference: Lean UX by Jeff Gothelf and Josh Seiden)