A Simple Introduction to Lean UX

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

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