Jeff Gothelf’s Lean UX book is about applying the principles of lean (startup) to User eXperience.

“Lean UX” is part of the Lean Series: a series of books applying the principles of Eric Ries’ Lean Startup to several domains.

Lean UX applies the principles of both agile, lean, design thinking and lean startup to the process of creating and design any user experience of any product or a service.

“Lean UX” is well-written and has enjoyed attention by many in the UX and lean/agile community. The first edition of the book was published in March, 2013.

Not familiar with agile, lean, lean startup or any of these?

Well, let’s shortly define:

Agile development is a mindset, an approach to product development (and yes, not only software). Agile focuses on delivering what’s valuable for the customer, and makes us work in short time periods. The product is built in small increments, and in an iterative way; meaning we revise, expand and improve the product iteration by iteration.

Moreover, agile stands for a way of working: cross-functional collaboration: all people in 1 team, no distinction between roles. An agile team cultivates and thrives on the mix of everyone’s expertise, open communication, trust, … in other words: real collaborative team work. When needed, an agile organization or company is able to immediately change direction in development (or any other area) at any time, with very low or even no cost.

Learn about the agile values and principles, and check for yourself if you’re really working in agile way.

So, what’s wrong with the way that products (software) are being designed?

Well, in a traditional way of working there exists the waterfall approach: meaning the assumption that upfront work (analysis, specification, design, etc) is required before we can start any construction.

Makes sense, doesn’t it? Let’s be sure and figure out all the details before investing money in construction. The reality proves to be different: most importantly, only when actually using the product or service constructed, you really know and can evaluate its use, its experience. Most of any upfront work done will largely turn out to be waste, because the product or service constructed will require changes to meet the “new” (actual) user needs, meet new market conditions, etc. When using the product (or service), the user finds out what he needs. Hence the plea for an incremental and iterative approach.

The traditional approach to designing a product and its user experience will output many deliverables: wireframes, prototypes, visual designs, style-guides, screen-flows, workflows, etc. Reality shows that many of those ideas and features designed will not make it to the actual final product; and many of those experiences designed (on paper, or even interactively) will require changes when end-users start using the product; or when any constraints arise.

The assumption that the user experience / user interface of a product should be designed upfront (away from construction) in a perfect way is an approach which originates from old habits and a traditional product development thinking. Looking from a lean perspective, this kind of process contains a lot of waste.

The Lean UX book

The Lean UX book shortly explains why Lean UX is needed. Lean UX (likewise agile and lean) itself is a mindset, a philosophy, an approach, an attitude, a way of thinking, a way of working. It defines a cycle, and offers a set of techniques and tactics. For UX people working the traditional way, it will be a considerable change in process and working attitude.

The Lean UX book enumerates the foundations and principles of Lean UX. With design thinking, agile, lean and lean startup in mind, the principles of Lean UX are familiar:

• Small, dedicated, co-located cross-functional teams
• Shared understanding throughout the process
• No gurus, lonely experts; but a whole team approach
• Progress is measured by outcomes, not by output (deliverables)
• Focus on problems and solutions, instead of a set of features
• Remove waste, by minimizing anything in the process that doesn’t directly contribute to value delivery
• Work in small batch sizes, small increments. Avoiding large quantities of work-in-progress
• Continuous discovery
• Interact with your customer, your end-user to get feedback (and to achieve this, you need to get our of the building, get out of your office)
• Externalize the work: show and tell as much as possible
• Value making over analysis
• Value learning over growth
• Permission to fail
• Getting out of the deliverables business: less focus on deliverables, more focus on constructing the product (cf. The agile manifesto)

Lean UX cycle

The Lean UX book describes the basic cycle:

THINK: Declaring assumptions and creating a hypothesis statement

How to start from a problem statement, declaring business and user assumptions and writing hypothesis statements.

MAKE: Creating and running an experiment

How to create and run an experiment with end-users. Experiments can take any form: prototypes or non-prototypes.

CHECK: Get feedback and research

How to organize user tests, and how to learn from feedback.

Lean UX and iterative development

In the last section, the Lean UX book describes how to the steps of Lean UX can be integrated in iterations of agile development. The book also describes what kind of organizational transformation and change in mindset are needed to be effective with Lean UX in your project or organization.

Great into video on Lean UX (at BBC)

[youtube https://youtu.be/F4Mry7L-vwM]