16/04/2018 A Simple Introduction to Lean UX | Interaction Design Foundation

A Simple Introduction to Lean UX

1 MONTH AGO | 4 MIN READ

Lean UX is an incredibly useful technique when working on projects where the Agile development
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 – What is It?

Lean UX is focused on the experience under design and is less focused on deliverables than
traditional UX. It requires a greater level of collaboration 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.

Author/Copyright holder: Vimeo. Copyright terms and licence: Public Domain

The Need for Assumptions in Lean UX

In traditional UX the project is built upon requirements capture and deliverables. The objective is to
https://www.interaction-design.org/literature/article/a-simple-introduction-to-lean-ux 1/4
16/04/2018 A Simple Introduction to Lean UX | Interaction Design Foundation

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 assumptions 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 brainstorm their ideas for solving the problem. In the process you
generate answers to certain questions that form your assumptions.

Typical questions might include:

Who are our users?

What is the product used for?
When is it used?
What situations is it used in?
What will be the most important functionality?
What’s the biggest risk to product delivery?

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

Author/Copyright holder: visualpun.ch. Copyright terms and licence: CC BY-SA 2.0

Creating a Hypothesis in Lean UX

The hypotheses created in Lean UX are designed to test our assumptions. There’s a simple format
https://www.interaction-design.org/literature/article/a-simple-introduction-to-lean-ux 2/4
16/04/2018 A Simple Introduction to Lean UX | Interaction Design Foundation

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 nd that there’s no way to prove our hypothesis – we may be heading in the wrong direction
because our outcomes are not clearly de ned.

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 in ghting from the UX design process. 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 Minimum Viable Product and Lean UX

The Minimum Viable Product (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”.

Author/Copyright holder: Eric delcroix. Copyright terms and licence: CC BY-NC-SA 2.0

User Research and Testing in Lean UX

User research 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
https://www.interaction-design.org/literature/article/a-simple-introduction-to-lean-ux 3/4
16/04/2018 A Simple Introduction to Lean UX | Interaction Design Foundation
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.

Summary
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

https://www.interaction-design.org/literature/article/a-simple-introduction-to-lean-ux 4/4