UX glossary · engl. Lean UX
Lean UX
Lean UX is a way of working in which teams turn assumptions into hypotheses and test them with small experiments. Shared learning replaces heavy documentation.
Imagine a team spends three months on a detailed concept for a new feature: personas, wireframes, a 60-page specification document. After launch, it turns out hardly anyone uses the feature. The assumption behind it was never tested.
Lean UX is an alternative to exactly this way of working.
Explained simply
Lean UX is a way of working in which a team turns its assumptions about users and the product into testable hypotheses early on and checks them with small experiments. Instead of handing over long documents, design, development and product management work closely together and learn in short cycles. “Lean” doesn’t mean “cheap” here. It means not putting effort into things that help nobody.
Think of cooking for a dinner party. Before you make a new recipe for twenty guests, you’d rather try it out on a small scale first. If it doesn’t taste good, you haven’t lost much and you know what to change.
The approach was popularized by Jeff Gothelf and Josh Seiden, mainly through the book “Lean UX,” first published by O’Reilly in 2013. The third edition came out in 2021 and works with the Lean UX Canvas, among other things: a template that helps teams structure the problem, goals, users, solution ideas and hypotheses together on a single page.
The three foundations
Gothelf and Seiden describe three roots. From UX design and design thinking comes the focus on the needs of the people who use a product. From agile software development come collaboration, working results over extensive documentation and the willingness to change plans. From Lean Startup by Eric Ries comes the build, measure, learn loop.
A central idea is the focus on outcomes over outputs. An output is what a team delivers, such as a feature. An outcome is the change in people’s behavior that results from it, for example more customers completing an order without help. Success is measured by the outcome.
Hypotheses often follow a simple pattern, roughly: we believe this solution will lead to this result for these people, and we’ll know we’re right when we see a specific measurable signal. You can read more in Lean UX: Trend or Real Improvement?.
An example
Here’s an example: a team suspects that people using a fitness app want an AI-generated training plan. Instead of building the whole feature, they add a “Create my plan” button that initially only leads to a short survey and a waiting list.
After two weeks, it’s clear how many people tap the button and what they’re hoping for. Based on that, the team decides whether and how to continue. These kinds of minimal versions are called a minimum viable product.
In practice
- Write down your assumptions. Collect as a team what you only believe about users and the product, then prioritize what’s riskiest.
- Test small and fast. A clickable prototype, a landing page or a conversation is often enough to check a hypothesis.
- Learn together. Review test results as a whole team instead of passing reports around. The original book is listed under Lean UX, and many methods for small teams are collected in Lean UX für kleine Teams (in German).
Related terms
Minimum Viable Product, Prototype, User Research, A/B Testing