What makes it Lean?

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 associate with Lean.

[Cross-posted on the LUXr.co blog]

4 comments Write a comment

  1. Thanks for this article. Very informative. Lean UX is new to me and I’m eager to be sure I understand before I put it into practice. It seems some argue that the hypothesis should be measurable – I don’t think ‘testable’ necessarily implies the practice of measuring the outcome. By measuring I mean recording and analysis some kind of metric or even statistical test (i.e. quantitative) whereas I guess testable could also mean validation through words (qualitative) alone. Do you think that validation through subjective qualitative data only (and I guess some objective i.e. observational data) is acceptable validated learning? Perhaps it really depends on context e.g. project, team, business requirements (e.g. KPIs) etc. I’d be interested to hear your thoughts… :)

  2. Thanks for the comment.

    Because we’re using a rough version of the scientific method–declaring hypotheses, looking for evidence, constructing experiements–there’s a temptation to apply overly rigorous standards. The decisions we’re making here are rarely life and death though. We’re simply trying to decide whether to move forward on a business idea, a design concept, etc. Our goal is to make the process efficient and reduce the amount of time and money we spend on bad ideas.

    So rigor becomes a somewhat subjective call. How much evidence do we need to convince ourselves that something is true or not? What kind of evidence will work?

    In my practice, I advice teams to use both qualitative and quantitive research, depending on the question under consideration. Personally, I’m a huge believer in the power of qualitative research and use it whenever I think it’s appropriate.

  3. Pingback: Whats the difference between Agile Development and Lean UX | Service Catalog Toolkit

  4. First of all, thanks for this article. I’m searching information about Lean-UX everywhere on the net and the more I search, the more I enjoy with this stuff.
    After reading your book (and Jeff’s) I became a fan of Lean-UX and I think it will be the reference as soon as people realise that is THE WAY to the success.

    I’m trying to start with lean-ux in my enterprise and the biggest problem we have is to find the moment that everyone of us in the team “is available to Lean”. How important is to make the process 3-12-1 exactly? How bad would be turn it into a 2-weeks process?

    Thank you very much again because I think technologies need teams with new ideas to be developed in the correct way and innovation is not the easiest way (but it is always the better one).

    I’d be very interested in learning from you.

    Juan.

Leave a Reply

Required fields are marked *.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>