LEAN UX: What is it and how is it different from others?

Lean UX (user experience) derives a lot from Lean Design, Manufacturing and Product Development, firstly implemented by Toyota, which aims to eliminate both tangible waste-like unused parts- and intangible waste –like time- throughout the manufacturing process. They also involve elements like Simultaneous Development –the process of a car being designed simultaneously by every team, resulting in a more reciprocal work environment rather than a sequential one, significantly reducing: red tape, number of designs that are sent back, and of course, time- and Continuous Improvement (kaizen) –the continuous process of improving the product and the processes in the business- both of which pose a lot of similarities with the elements and mindset of Lean UX. At Otsimo, we are using LEAN UX for every single game or app feature.

So, here is the thing. Normally firms follow a sequential (waterfall) approach to product development, in which you complete %100 of the product development phase (ie analysis) and then pass it to the next guy who then %100 completes the next phase (ie design). When every phase is completed, you then release the product. Sounds pretty straight forward, right? This approach tends to work in more mechanistic organizations focusing on incremental innovations, modifications, and efficiency, where you are likely to know what your customers want and how they want what they want, but is powerless while facing uncertain customer preferences in dynamic environments. This is so, because the preferences of the customer might change even during the product development, and since in this approach it is very very very hard to go back one phase and do rearrangements without causing instabilities across all other phases, the waterfall cannot help but break, and then you have no choice but to go back to square one.

In contrast to the waterfall approach, the Agile method emerged in the 2000s, which was kind of a breakthrough in product development. In this method, instead of completing %100 of a single-phase, you complete %10 of each phase. You then get together with your development team, review the product, identify the necessary steps to be taken, and then you start again from the first phase, building on top of the fractional product you have built, repeating the development processes as many times as necessary (see picture below) until you reach a final product. You may choose to release your product at the end of your first development cycle, or at the very last development cycle. This approach allows for continuous quality improvements from day one, more visibility of the product (you can actually see it coming to life piece by piece) and most importantly, it allows you to be flexible –you can change or rearrange any part of the product without (completely) breaking the whole development cycle.

This approach of course, requires a lot of teamwork and collaboration within the company, and also involves elements like sprints – usually two to four week periods in which the teams work on the most important tasks and advance toward the less prioritized- and also spanned subdivisions of itself like Scrum and XP (Extreme Programming). The Agile methods, work better in situations where customer preferences are still somewhat certain so they know what they want, but they do not know how they want it (or, you do not know how to deliver the value the customer wants from you).

And that point is where Lean UX comes in. In times of drastic uncertainty, when you do not know what customers want and you also do not know how to deliver the value to them, you resort to Lean UX. Taking inspiration from the lean startup methodology and its Build-Measure-Learn cycle, you build a Minimum Viable Product (MVP) around assumptions and hypotheses, then update your MVP by getting insights and feedback from your customer(s), creating a Think-Make-Check cycle. You repeat the cycle as many times as necessary.

Lean UX presents us with an approach that emphasizes customer feedback and customer satisfaction on top of some of the already existing principles of the Agile methodology, like teamwork and continuous processes. It sees the release of a product not as the end, but rather a new beginning every time. You focus on making a final product piece by piece, benefiting from customer insights each time.

What I see as important in this ideology is that you need a really, really good customer (group) that is providing creative feedback for you and your team, of which you can build on and expand your product. If you have a customer group, you must also ensure that the group is diversified enough to represent the bigger market. It is also possible to see similarities between the lead user methodology –a group of experts in their respective areas taking part in a product’s development, either before or in the early stages of the product’s release- and Lead UX.

Of course, this is not all there is to Lean UX or Agile. With each different methodology and ideology, you must also bring a different set of values and principles into the table (for example, Lean UX does not focus on deliverables of a project, whereas Agile UX does) but it would be impossible to discuss this fully comprehensively in anything short of a 25-page research paper. I tried to, in this short, tell you the differences there are between the three product development methodologies, as far as I understood and use them, in the simplest way possible.