Lean UX is a technique used when working on projects where the Agile development method is used. When development is rapid, there's not enough time to use traditional UX techniques. Fundamentally, all forms of UX aim to deliver a great user experience, but a Lean UX differs in the way you work on a project. It is less focused on deliverables and requires a greater level of collaboration within the team.

Lean UX

Lean UX isn't focused on detailed deliverables. Instead, it is focused on producing changes that improve the product in the present. In practice, you are replacing "requirements" with a "problem statement", leading to a set of assumptions that can result in a hypothesis. Assumptions are generated on a workshop basis. It is understood that assumptions may not be correct and can change as better understanding develops. The team will prioritise assumptions by the risk they represent—the more severe the consequence, the higher the priority.

The need for assumptions

The hypotheses created in Lean UX are designed to test our assumptions. A simple format to create your own hypotheses."We believe that [......] is essential for [.....]. This will achieve [....]. We will have demonstrated this when we can measure [.....]<ul><li>State the belief.</li><li>Why it is important to you.</li><li>Who it is important to.</li><li>What you expect to achieve.</li><li>What evidence you would need to collect to prove that your belief was correct.</li></ul>

Creating a hypothesis in Lean UX

The MVP is building the most basic version of the concept and testing it. The MVPs which show promise can be incorporated into further design and development rounds. This can maximise your resources as it allows for experimentation without "sacred cows."

The Minimum Viable Product (MVP) and Lean UX

User research and testing are based on the same principles as traditional UX. But the approach is often "quick and dirty" as the results need to be delivered before the next Agile Sprint. This means less focus on meticulously documented outputs and more focus on raw data. Responsibilities for research is also more widely spread across the team.

User research and testing

<a href="https://www.interaction-design.org/literature/topics/lean-ux" title="What is Lean UX?" dir="ltr">Lean UX</a> is an incredibly useful technique when working on projects where the <a href="https://www.interaction-design.org/literature/topics/agile-development" title="What is Agile Development?" dir="ltr">Agile development</a> method is used. Traditional UX techniques often don’t work when development is conducted in rapid bursts – there’s not enough time to deliver UX in the same way. Fundamentally Lean UX and other forms of UX all have the same goal in mind; delivering a great user experience it’s just that the way you work on a project is slightly different. So let’s take a look at how that might work.
<h2>Lean UX – What is It?</h2>Lean UX is focused on the experience under design and is less focused on deliverables than traditional UX. It requires a greater level of <a href="https://www.interaction-design.org/literature/topics/collaboration" title="What is Collaboration?" dir="ltr">collaboration</a> with the entire team. The core objective is to focus on obtaining feedback as early as possible so that it can be used to make quick decisions. The nature of Agile development is to work in rapid, iterative cycles and Lean UX mimics these cycles to ensure that data generated can be used in each iteration.
<article>Author/Copyright holder: Vimeo. Copyright terms and licence: Public Domain</article><h2>The Need for Assumptions in Lean UX</h2>In traditional UX the project is built upon requirements capture and deliverables. The objective is to ensure that deliverables are as detailed as possible and respond adequately to the requirements that are laid down at the start of the project.
Lean UX is slightly different. You aren’t focused on detailed deliverables. You are looking to produce changes that improve the product in the here and now – essentially to mould the outcome for the better.
This works in practice by ditching “requirements” and using a “problem statement” which should lead to a set of <a href="https://www.interaction-design.org/literature/topics/assumptions" title="What is Assumptions?" dir="ltr">assumptions</a> that can be used to create hypotheses.
What is an assumption? An assumption is basically a statement of something that we think is true. They are designed to generate common understanding around an idea that enables everyone to get started. It is fully understood that assumptions may not be correct and may be changed during the project as a better understanding develops within the team.
Assumptions are normally generated on a workshop basis. You get the team together and state the problem and then allow the team to <a href="https://www.interaction-design.org/literature/topics/brainstorming" title="What is Brainstorming?" dir="ltr">brainstorm</a> their ideas for solving the problem. In the process you generate answers to certain questions that form your assumptions.
Typical questions might include:
<UL><LI>Who are our users?</LI><LI>What is the product used for?</LI><LI>When is it used?</LI><LI>What situations is it used in?</LI><LI>What will be the most important <a href="https://www.interaction-design.org/literature/topics/functionality" title="What is Functionality?" dir="ltr">functionality</a>?</LI><LI>What’s the biggest risk to product delivery?</LI></UL>There may be more than one answer to each question. That leaves us with a greater number of assumptions than it might be practical to handle. If this is the case, the team can prioritize their assumptions quickly following their generation. In general you would prioritize your assumptions by the risk they represent (what are the consequences of this being badly wrong? The more severe the consequence the higher the priority) and the level of understanding of the issue at hand (the less you know, the higher the priority).
<article>Author/Copyright holder: visualpun.ch. Copyright terms and licence: CC BY-SA 2.0</article><h2>Creating a Hypothesis in Lean UX</h2>The hypotheses created in Lean UX are designed to <a href="https://www.interaction-design.org/literature/topics/test" title="What is Test?" dir="ltr">test</a> our assumptions. There’s a simple format that you can use to create your own hypotheses, quickly and easily.
An example:
We believe that enabling people to save their progress at any time is essential for smartphone users. This will achieve a higher level of sign up completions. We will have demonstrated this when we can measure an improvement of the current completion rate of 20%.
We state the belief and why it is important and who it is important to. Then we follow that with what we expect to achieve. Finally, we determine what evidence we would need to collect to prove that our belief was true.
If we find that there’s no way to prove our hypothesis – we may be heading in the wrong direction because our outcomes are not clearly defined.
One of the big advantages of working like this is it removes much of the “I don’t think that’s a good idea” and political infighting from the UX <a href="https://www.interaction-design.org/literature/topics/design-process" title="What is Design Process?" dir="ltr">design process</a>. Every idea is going to be tested and the evidence criteria clearly determined. No evidence? Then it’s time to drop the idea and try something else.
If everyone can understand a hypothesis and the expectations from it, they tend to be happy to wait to see if it’s true rather than passionately debating their own subjective viewpoint.
<h2>The Minimum Viable Product and Lean UX</h2>The <a href="https://www.interaction-design.org/literature/topics/minimum-viable-product" title="What is Minimum Viable Product?" dir="ltr">Minimum Viable Product</a> (MVP) is a core concept in Lean UX. The idea is to build the most basic version of the concept as possible, test it and if there are no valuable results to abandon it. The MVPs which show promise can then be incorporated into further design and development rounds without too much hassle.
This is a great way of maximizing your resources and one of the reasons that it works so well with Agile development – it allows for a lot of experimentation with no “sacred cows”.
<article>Author/Copyright holder: Jussi Pasanen. With acknowledgements to Aarron Walter, Ben Tollady, Ben Rowe, Lexi Thorn and Senthil Kugalur. Copyright terms and license: All rights reserved</article><h2>User Research and Testing in Lean UX</h2><a href="https://www.interaction-design.org/literature/topics/user-research" title="What is User Research?" dir="ltr">User research</a> and testing, by the very nature of Lean UX, are based on the same principles as used in traditional UX environments. However, the approach tends to be “quick and dirty” – results need to be delivered before the next Agile Sprint starts; so there’s much less focus on heavy-duty, meticulously document outputs and more focus on raw data.
Responsibilities for research also tend to be spread more widely across the whole team so that there’s no “bottleneck” created by having a single UX design resource trying to get the whole job done in tight timescales by themselves. This often gets development resources to do “hands on” UX work and increases the level of understanding and support for UX work within the development team too.
<h2>Summary</h2>This is a very high-level overview of Lean UX and, of course, there’s a lot more to it than you can cover in a short(ish) article. However, these basic concepts should enable you to start heading in the right direction when it comes to implementing Lean UX in your Agile environment.
<h2>References &amp; Where to Learn More</h2>Header Image: Author/Copyright holder: Rosenfeld Media. Copyright terms and licence: CC BY 2.0
Course: <a href="https://www.interaction-design.org/literature/topics/ux-management" title="What is UX Management?" dir="ltr">UX Management</a>: Strategy and Tactics: <a href="https://www.interaction-design.org/courses/ux-management-strategy-and-tactics" dir="ltr">https://www.interaction-design.org/courses/ux-management-strategy-and-tactics</a>

Lean UX is used with projects where the Agile development method is used. This article gives a brief overview of Lean UX and enables you to head in the right direction when implementing Lean UX.

Lean UX has the same goal in mind as other forms of UX, it’s just that the way you work on a project is slightly different. Let’s take a look at how it works.

Stashed ideas

<a href="https://www.interaction-design.org/literature/topics/lean-ux">Lean UX </a>is an incredibly useful technique when working on projects where the <a href="https://www.interaction-design.org/literature/topics/agile-development">Agile development </a>method is used. Traditional UX techniques often don’t work when development is conducted in rapid bursts – there’s not enough time to deliver UX in the same way. Fundamentally Lean UX and other forms of UX all have the same goal in mind; delivering a great user experience it’s just that the way you work on a project is slightly different. So let’s take a look at how that might work.

Lean UX is focused on the experience under design and is less focused on deliverables than traditional UX. It requires a greater level of <a href="https://www.interaction-design.org/literature/topics/collaboration">collaboration </a>with the entire team. The core objective is to focus on obtaining feedback as early as possible so that it can be used to make quick decisions. The nature of Agile development is to work in rapid, iterative cycles and Lean UX mimics these cycles to ensure that data generated can be used in each iteration.

In traditional UX the project is built upon requirements capture and deliverables. The objective is to ensure that deliverables are as detailed as possible and respond adequately to the requirements that are laid down at the start of the project.

Lean UX is slightly different. You aren’t focused on detailed deliverables. You are looking to produce changes that improve the product in the here and now – essentially to mould the outcome for the better.

This works in practice by ditching “requirements” and using a “problem statement” which should lead to a set of <a href="https://www.interaction-design.org/literature/topics/assumptions">assumptions </a>that can be used to create hypotheses.

What is an assumption? An assumption is basically a statement of something that we think is true. They are designed to generate common understanding around an idea that enables everyone to get started. It is fully understood that assumptions may not be correct and may be changed during the project as a better understanding develops within the team.

Assumptions are normally generated on a workshop basis. You get the team together and state the problem and then allow the team to <a href="https://www.interaction-design.org/literature/topics/brainstorming">brainstorm </a>their ideas for solving the problem. In the process you generate answers to certain questions that form your assumptions.

<ul><li>Who are our users? </li><li>What is the product used for? </li><li>When is it used? </li><li>What situations is it used in? </li><li>What will be the most important <a href="https://www.interaction-design.org/literature/topics/functionality">functionality </a>? </li><li>What’s the biggest risk to product delivery? </li> </ul>

There may be more than one answer to each question. That leaves us with a greater number of assumptions than it might be practical to handle. If this is the case, the team can prioritize their assumptions quickly following their generation. In general you would prioritize your assumptions by the risk they represent (what are the consequences of this being badly wrong? The more severe the consequence the higher the priority) and the level of understanding of the issue at hand (the less you know, the higher the priority).

The hypotheses created in Lean UX are designed to <a href="https://www.interaction-design.org/literature/topics/test">test </a>our assumptions. There’s a simple format that you can use to create your own hypotheses, quickly and easily.

We believe that enabling people to save their progress at any time is essential for smartphone users. This will achieve a higher level of sign up completions. We will have demonstrated this when we can measure an improvement of the current completion rate of 20%.

We state the belief and why it is important and who it is important to. Then we follow that with what we expect to achieve. Finally, we determine what evidence we would need to collect to prove that our belief was true.

If we find that there’s no way to prove our hypothesis – we may be heading in the wrong direction because our outcomes are not clearly defined.

One of the big advantages of working like this is it removes much of the “I don’t think that’s a good idea” and political infighting from the UX <a href="https://www.interaction-design.org/literature/topics/design-process">design process </a>. Every idea is going to be tested and the evidence criteria clearly determined. No evidence? Then it’s time to drop the idea and try something else.

If everyone can understand a hypothesis and the expectations from it, they tend to be happy to wait to see if it’s true rather than passionately debating their own subjective viewpoint.

The <a href="https://www.interaction-design.org/literature/topics/minimum-viable-product">Minimum Viable Product </a>(MVP) is a core concept in Lean UX. The idea is to build the most basic version of the concept as possible, test it and if there are no valuable results to abandon it. The MVPs which show promise can then be incorporated into further design and development rounds without too much hassle.

This is a great way of maximizing your resources and one of the reasons that it works so well with Agile development – it allows for a lot of experimentation with no “sacred cows”.

<a href="https://www.interaction-design.org/literature/topics/user-research">User research </a>and testing, by the very nature of Lean UX, are based on the same principles as used in traditional UX environments. However, the approach tends to be “quick and dirty” – results need to be delivered before the next Agile Sprint starts; so there’s much less focus on heavy-duty, meticulously document outputs and more focus on raw data.

Responsibilities for research also tend to be spread more widely across the whole team so that there’s no “bottleneck” created by having a single UX design resource trying to get the whole job done in tight timescales by themselves. This often gets development resources to do “hands on” UX work and increases the level of understanding and support for UX work within the development team too.

This is a very high-level overview of Lean UX and, of course, there’s a lot more to it than you can cover in a short(ish) article. However, these basic concepts should enable you to start heading in the right direction when it comes to implementing Lean UX in your Agile environment.

Header Image: Author/Copyright holder: Rosenfeld Media. Copyright terms and licence: CC BY 2.0

Course: <a href="https://www.interaction-design.org/literature/topics/ux-management">UX Management </a>: Strategy and Tactics: <a href="https://www.interaction-design.org/courses/ux-management-strategy-and-tactics">https://www.interaction-design.org/courses/ux-management-strategy-and-tactics </a>

Bite-sized knowledge
to upgrade
your career

A Simple Introduction to Lean UX

Lean UX

The need for assumptions

Creating a hypothesis in Lean UX

The Minimum Viable Product (MVP) and Lean UX

User research and testing

IDEAS ABOUT

MORE LIKE THIS

7 UX Deliverables: What will I be making as a UX designer?

9 helpful tips for collaborating on a UX writing project - UX WRITING HUB

3 Ways To Increase Your UX Designer Salary (2022)

It's time to

READ

LIKE

A PRO!

Bite-sized knowledgeto upgradeyour career

A Simple Introduction to Lean UX

Lean UX

The need for assumptions

Creating a hypothesis in Lean UX

The Minimum Viable Product (MVP) and Lean UX

User research and testing

IDEAS ABOUT

MORE LIKE THIS

7 UX Deliverables: What will I be making as a UX designer?

9 helpful tips for collaborating on a UX writing project - UX WRITING HUB

3 Ways To Increase Your UX Designer Salary (2022)

It's time to

READ

LIKE

A PRO!

Bite-sized knowledge
to upgrade
your career