Author: Narjeet Soni

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)

The ultimate goal of Lean UX is to deliver a great user experience. It’s a highly practical technique that takes into account three key Lean principles:

First, it helps you remove all the waste from your UX design process. It eliminates heavy documentation and focuses only on creating the design deliverables you need.

Second, it brings a higher level of collaboration and transparency in your process. It even drives developers and engineers to get involved in the design process.

Third, it focuses on obtaining early feedback through experimentation. Instead of relying on a single person’s decision, you test and measure at each step to meet your goals.

What is Lean UX?

Lean UX is more than just a practical technique. It is a mindset shift. It breaks down all the barriers that create silos in a business. It pushes business and technology teams to sit down and create the best possible solutions.

In essence, Lean UX is about overcoming the fear of showing work that you perceive to be ugly or unfinished. It’s about gaining confidence in your ability as a team.

It’s about working towards building a product or service that will require multiple iterations. There is hardly a chance that you will get it right in the first go.

Lean UX is the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way that reduces the emphasis on thorough documentation while increasing the focus on building a shared understanding of the actual product experience being designed.

Core Elements of Lean UX

Here is a toolkit that will help you put together the practice of Lean UX in your company:

1) Start with creating cross-functional teams.

A cross-functional team must have members from every department that are involved in creating your product. Be it software, business, design or product, every team member should be involved from the very start of the project.

Reason? Collaboration becomes a lot easier. Teams become more efficient as there are no handoffs or waiting periods involved. The knowledge and insights from all disciplines are brought in early in the process.

2) Create small, dedicated teams.

There should not be more than 10 people in a team. And if possible, they should all be dedicated to the same project and based in the same office.

Reason? Smaller teams tend to have better communication. And if they are given the same project, they can share their goals and priorities with each other. Their relationships can strengthen even more if they work in the same location. Plus it’s easier to keep a tab on their project status or any changes.

3) Measure your progress.

Don’t focus on features and services. Focus on the goals that they are meant to achieve. Every goal should be measurable.

Reason? If you only focus on features and services, then you are assuming that they will definitely work in the market. By focusing on goals and the progress made towards them, you are able to assess a feature is worth building or not. And in case it is not performing well, you can make a sound decision about discarding or changing it.

4) Assign teams to solve problems.

Assign your teams to solve problems rather than implement given solutions or features.

Reason? When you assign a problem to a team, it has to come up with a solution on its own. This helps the team to build confidence and take ownership of the solution that they build or implement.

5) Cut out all the waste.

Anything that doesn’t add value to the ultimate solution is considered waste. And it should be cut out from the team’s process.

Reason? You want to utilize your resources effectively. You do not want your team to focus on false challenges. The sharper your focus is, the faster you can move towards your desired goals.

6) Create what is necessary.   

Create only those design deliverables that are necessary to move the team forward. Avoid creating a stack of untested and unimplemented design ideas.

Reason? You do not want to slow down your speed of delivery by unnecessarily creating ideas that have not been validated. It’s a waste of time and resources.

7) Learn from your users early on.

If you want to find out what your users are doing with your product, you must start engaging with them during the design and development process.

Reason? If you are regularly in touch with your users, you can validate your ideas much faster. Only your users can tell you whether you are building a product they actually need.

8) Get out of the building.

Gone are the days when user needs were determined in meeting rooms. Now you need to get out of your office building and go to the marketplace to determine the problems your users are facing. The success of your product or service can only be determined by your users.

Reason? Before you spend a lot of time and resources on your idea, you must get feedback from your users to validate what you are building. Do they really need what you are building? The earlier you know what they want, the less time you will waste building something that they don’t need.

9) Encourage the team to learn collectively.

It is essential for a team to collectively develop a deep understanding of its product and users.

Reason? If the team understands its project thoroughly, the less it has to depend on heavy documentation or debrief conversations to move forward in its work.

10) Avoid creating rockstars in your team.

The team must work together without following any experts or rockstars for better collaboration and unity.

Reason? If team members start aspiring to acquire a higher status within the team, they stop sharing their knowledge and often develop big egos. This leads to poor collaboration and dirty office politics.

11) Make your work public.

Use whiteboards, sticky notes or whatever it takes to display your work in progress to your teammates, colleagues and customers.

Reason? This allows transparency and better cross-functional collaboration. Whether you are an introvert or extrovert, you can participate equally without debating or defending your ideas. You let your work speak for you on the board.  

12) Create rather than analyze.

There is definitely more value in creating the first version of your product rather than debating over its pros and cons in your meeting room.

Reason? Often the most difficult questions get answered in the market place rather than the meeting room. Your customers will help you decide whether your product is worth investing in.

13) Learn rather than scale up.

Do not scale up a business or an idea that is untested or yet to be validated. Learning is the most important step. And it comes way before scaling.

Reason? It is risky to scale up an idea that is not tested. It is potentially a waste of time and resources. You can avoid a lot of waste by testing and learning about your business idea early on.

14) You should be allowed to fail.

If you want to come up with the best possible solutions, you need to keep experimenting. You need to keep failing. And you must feel safe doing that. There should be no penalty for failure.

Reason? If you allow your employees to fail and to experiment without inducing the fear of losing their jobs, they are likely to be more creative. They are likely to take more risks and come up with innovative solutions.

15) Get out of the deliverables business

Your design process should be focused on creating design deliverables rather than neat documents with elaborate descriptions.

Reason? The time spent on creating documents could be better utilized on learning your customer needs or creating features that they actually care about. Eventually, it’s not the documents that will fulfill your customer needs. It will be the product you are building.

If you want to create a successful UX team, make sure that you embody these core elements into your process.

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