Design@AXA. Stakes in lean UX

When I joined my new company, LEAN UX was the first book I was asked to read. I agreed of course. I had read it already but it was in November 2015, just before a dramatic events hurts me personally and he book didn’t let the footprint it deserved in my memory. So that was a good catchup with the fantastic principles developed by Jeff Gothelf.

Indeed. I don't have to be convinced of the benefits of following this approach in product development. Not only because it is a more enjoyable and less painful way to make good products real but also because all the successful digital projects I had been involved in until now have always been, at some point, officially or not, managed this way. 

An interesting thing with the lean methodology is that it describes a process that leads to its own creation. An inductive approach based on insights extracted from real life experience and multiple iterations of testing and learning. Not theory but practical, based on real life problems and actionnable solutions.

Below my interpretation of the Lean UX process. I may not affirm it represents exactly what the book states as it has been interpreted with my own professional experiences. 

Everything starts with a phase that I called ? inception ?. An intention to change something in the world, confirmed or initiated by direct observations. Physical immersion is key to create an empathy and a deep understanding of users pains points and helps to identify opportunities. Practical knowledge of real users life and context also helps to define assumptions : things we believe to be truth. Basically, they replace the requirements and will help to define the objectives that will lead the product development from start to the end. Excepted if at some point the tests phases demonstrate that one of several of our assumptions are not true. 

Design phase starts on ? wicked problems ?. Problems that are not only ill-defined or tricky but their solutions are also not available through some technical knowledge. This is were we initiate a succession of build and tests rounds. Each of them starts from some insights from the real world leading the build of a products that will be tested in order to validate some hypothesis. Keeping track of the hypothesis is essential to maintain the UX gains from one round to an other. Step by step, the product grow, from a ? pretotype ? a very basic mockup allowing to validate a few hypothesis to a prototype that can be a partially interactive mockup to a partially developed product, and eventually ends up with a product that can be release from a friends and family audience and then to a public version. 

More the product development is advanced, more complex it is, more hypothesis we have to validate and more insights we can get. The first level of testing starts within the team, by sharing ideas and challenging the drafted solutions in a design studio. Prototypes and then prototypes can be evaluated in guerrilla testing that are some informal and cheap users tests set within the organisation or outside the office. Structured users tests require a bit more of logistic and are more useful when the product reach a certain level of definition. Once the product starts to be usable by real users, it is essential to collect usage data in order to validate hypothesis with quantitative insights. 

4 stakes in lean UX 

1. Falling in love with your ideas : It requires from a designer some humility to accept to be challenged and re-challenged all along a project. Ideas that appears to be awesome at some point can be dismantled by users or can no longer works because of a change in an other part of the product. Lean UX valorises speed of execution and efficiency. It's a pragmatic approach for problem solving. 
2. Loosing the UX and UI consistency : Set as quick as possible robust graphic user interface style guide (GUI) and UX principles that will helps to maintain the global consistency all along the iteration steps. It will allow to make the graphic assets delivery faster and will make the unavoidable rework less painful.
3. Breaking whats already worked : Keep track of your hypothesis. Highlights the validated ones. Every feature should be related to at least one hypothesis. Every new round of build add new hypothesis to the existing ones. Every testing session must include the validation of the latest build phase hypothesis as well as the check of the previous ones. 
4. Releasing too early : In mature markets audience for innovative products is often limited. Making early adopters angry because of an immature product can be very expensive. Some researches show that acquisition is 3 times more expensive than loyalty and regaining an unhappy customer is 12 times more expensive.