What makes Lean UX Lean?  What makes it different enough from other ways of working to merit its own name?

Lean UX is not some essential form of UX.

Some have suggested that Lean UX is about reducing UX work to its essence–that by taking a minimalist approach to our work, we can trim our work down to its essential elements–and that doing this makes our work “Lean.” While I believe there is great value in reducing our work to its essential elements, I don’t think this justifies the name Lean: it doesn’t capture the sense of the word evoked by Lean Startup, which is the connection to Lean Manufacturing and the Toyota Production System

At LUXr, we talk about the 9 Principles of Lean UX. And while they’re all important, for me, #8, “Recognize your hypotheses and validate them,” is the keystone, the one that makes the whole system stand up.

The keystone principle: recognize your hypotheses.

Lean UX replaces requirements statements with testable statements of assumptions. Instead of writing a requirement that says, the site shall incorporate shopping cart functionality, Lean UX teams might say, we assume that a shopping cart is the best way to structure the e-commerce flow on our site. Instead of solutions then, requirements are transformed into questions that teams can ask (and must answer) about their business. Progress is measured in terms of validated learning, rather than features implemented.

The process looks like this:

• First, you declare your assumptions, and express them as a testable hypothesis.
• Then, you write your test–what signal will you get back from the market that will let you know if your hypothesis is true?
• Finally, you ask the question, “what’s the smallest thing I can do or make to test this hypothesis? The answer to this question is your minimum via product, or MVP.

By changing the way requirements are handed to the team, indeed by eliminating them, Lean UX pushes upstream, beyond the traditional realm of technology and design and into business. This forces teams using Lean UX approaches to become more deeply cross-disciplinary. By forcing the requirements process to change in this way, it requires the full participation of the business owners. These folks are no longer handing off requirements. Instead, they become integrated team members who participate in the learning and validation process.

Why Lean?

This approach is embodies the principles of waste reduction and going to the source, key elements of Lean thinking.

• Waste reduction: Lean manufacturing seeks to reduce inventory–but this isn’t manufacturing, it’s design. What’s the inventory in a design sense? In Lean UX, it’s your backlog of untested assumptions–design decisions that you’ve made but haven’t validated. By expressing your design decisions as hypotheses, you express them in a form that is testable–and forces the team to be honest with itself about the material it’s dealing with. And by testing assumptions via an MVP, you are reducing cycle time. You can test hypotheses in hours and days rather than months and years.
• Going to the source: Lean teaches practitioners to look for the root cause of problems–to seek the source of the problem rather than the surface manifestation of the problem. In a design context going to the source means going beyond software requirements generated inside a business. It means engaging with the customer and end user to understand their essential needs, goals and desires. By writing your test in terms of the behaviors you expect to see in your users, you are forced to go to the source for your answers.

Who cares? Why is this a good way to work?

There are lots of benefits to using this system–it’s not a cure-all, and it’s not right for every context–but it’s very good for startup teams. As noted above, by reframing the requirements process into an hypothesis/MVP process, it naturally brings requirements writers into collaboration with designers and technologists, helping to create a more unified team. By providing a structure for evidence-based decision-making, it can take some of the interpersonal thrash out of the decision-making process. By focusing the team around assumptions, it offers a way for teams to get out of their own heads–to stop fantasizing and start getting real.

Surely there’s more?

So yes, Lean UX is collaborative, principled, lightweight and informal, but so are many other approaches to doing UX. It isn’t until you add the hypothesis, test, MVP combination that you get something new–and that merits the association with Lean.

[Cross-posted at joshuaseiden.com/blog]