Back in June I flew up to Edinburgh for UX Scotland, a new User Experience conference. The highlight for me was a full-day workshop with Jeff Gothelf, author of ‘Lean UX’, the latest book in the ‘Lean Start-up’ series. Being new to Lean UX I wanted to write a post covering some of the basics to help me get to grips with it.
This article isn’t intended as an opinion piece, although hopefully that will follow once I’ve had a chance to put some of the principles into practice. If you’re already familiar with Lean UX please look away now!
What is Lean UX?
Inspired by Lean and Agile development theories, Lean UX helps us focus on the actual experience being designed, rather than deliverables. The workshop showed us how, as UX specialists, we could collaborate more closely with other members of a product team, and gather valuable feedback as early and often as possible. It taught us how to drive the design of a product in short, iterative cycles in order to help assess what works best for both the business and the user.
Traditionally, UX design projects are framed by requirements and deliverables; teams are given set requirements and expected to produce detailed deliverables. Lean UX re-frames the way we approach a project. The goal is not to create a deliverable (e.g. a design specification), but rather to change something for the better – to affect an ‘outcome’.
Lean UX replaces requirements with a ‘problem statement’ and a set of ‘assumptions’, which in-turn form ‘hypotheses’.
An assumption is a high-level declaration of what we believe to be true but not to be taken as a literal fact. Assumptions enable a team to develop a shared understanding and to agree upon a common starting point.
By going through an ‘assumptions declaration’ exercise as a team, designers and non-designers alike are given the opportunity to voice their opinions on how best to solve the problem. Early assumptions respond to questions such as:
- Who is our ‘customer’?
- When and how is our product used?
- What features are most important?
- What is our biggest product risk?
The assumptions are then prioritised by the team; user A is more important than user B, feature X is of far greater value than Y or Z. Prioritisation should be based on the level of risk (i.e. how bad would it be if we were wrong about this?) and understanding of the issue.
By prioritising assumptions according to greatest risk or unknown issues, the sooner we are able to test the accuracy of those initial assumptions.
Forming a hypothesis – from outputs to outcomes
A hypothesis statement uses the format:
We believe that [ doing this / building this feature / creating this experience],
For [these people/personas],
Will achieve [this outcome],
We will know this to be true when we see [this feedback / quantitative measure / qualitative insight ].
We transform assumptions into a series of hypothesis statements so they can be tested. These statements communicate a clear vision for the work and shift the conversation between the team members and their managers from outputs (e.g. “we will create an advanced search feature”) to outcomes (e.g. “we want to increase the accuracy of a user’s first search”).
The hypothesis is a way of expressing our initial assumptions. It should be defined in a way that is testable, in order to measure whether it has achieved the desired outcome.
Expressing assumptions in this way helps build a shared understanding and takes much of the subjective and political conversation out of the decision-making process, instead orientating the team towards the users.
MVPs and Experiments
Lean UX relies upon the notion of MVP (Minimum Viable Product) to help test assumptions – will this tactic achieve the desired outcome? – while keeping the time we spend on unproven ideas to an absolute minimum.
The sooner we can find which features are worth investing in, the sooner we can focus our limited resources on the best solutions for our business problems.
The MVP is then used to run an experiment, the outcome of which will show us whether our initial hypothesis was correct or not, and whether the direction explored should continue to be pursued, refined further or abandoned altogether.
When it comes to testing, Lean UX takes the basic research techniques from traditional UX processes and overlays three important ideas:
- Research is continuous, built into every sprint (e.g. 3 users, every Thursday),
- Continuous activities are bite-sized (quick to organise and ruthlessly focused)
All activities require collaboration in which responsibility for activities such as research, are spread evenly across the team, removing the bottleneck often created by a solitary researcher. By eliminating the step between researcher and developer the quality and depth of learning is increased (in theory).
Hopefully this has helped to introduce some of the fundamental characteristics of Lean UX. Personally I liked the way many aspects were framed, and from my experience of Agile was glad of an approach that put greater emphasis on the user. Although there are a lot of challenges to adopting such an approach I hope to be able to introduce some of the more valuable aspects into our current agile process.
I’d be interested to hear other people’s experiences of Lean UX, especially gaining buy-in from a development team. If you have any thoughts please feel free to share them.