At AppSaloon we always try to improve our way of working. To do so, we reach out to external knowledge. This time, I read “Lean UX” by Jeff Gothelf and Josh Seiden. A truly inspiring book that applies lean & agile principles to improve the user experience in a much more effective way than the common UX process. In this blog post, I will explain the key principles of Lean UX and how we will aim to use them in some of our future projects.

Falling in love with the problem, not the solution

It can feel good to have an idea you believe is innovative or fun. Even the best designers will come up with ideas that, after further research, are just not suitable for the particular problem you want to address. Due to several possible limitations like time, budget, resources or just not solving the problem at all, it might be better to move away from this solution. Being emotionally invested in this idea will make it hard to do so. That’s why it’s important to fall in love with the problem, not the solution. This will keep you focused on what really matters: solving the problem. Plus, it will make you flexible in regard to which ideas to develop.

Fast and collaborative teams

In a lean UX process, multidisciplinary teams work together in a highly collaborative way and deliver small batches of work every two weeks. They don’t waste time on endless documentation, deliverables and briefings. Teams are aware of each other's work and discuss their problems, findings, ideas etc. on a daily basis. Every two weeks, the team plans the batch of development, research or discovery they will be conducting in the coming two weeks. 

There is no desire for a BDUF (Big design upfront) since this only means more work and less flexibility. The design should be created in batches and in close collaboration with development. This facilitates direct feedback from the developer to the designer and will reduce the time wasted on the design of features or interfaces that are not possible to make or to just too time-consuming. Other than that, not having a fixed BDUF will enable the team to respond quickly to new insights.

A lean UX team relies on a design system to be able to rapidly develop the required interface. They will do this based on wireframes or sketches. While the front-end developer develops the interface, the designer will work on refining the design which can then be easily implemented. Working simultaneously will allow the designer and developer to regularly engage and discuss their ideas and insights.

Sometimes your stakeholders will require a design to give them a glimpse of what the product might look like. After the purpose of this design has been fulfilled it should be thrown overboard.

Continuous learning and shared understanding

Lean UX team members all know the targeted users, user outcomes and business outcomes of the products they are working on. Their understanding of these factors evolve over time, together. They achieve this shared understanding by designing and researching together and regularly. 

The designers lead several design sessions with development teams and users. This can be an informal chat or a formal design studio workshop.

Researchers lead weekly research sessions with the team and users. This allows the team to minimize the time between concept & feedback. In order to move forward quickly, the team tests what they have at that point in time. Thus, there is no need to plan for or wait for the product to have a particular form in order to conduct research.

It’s important for all team members to understand there are no gurus or hero’s in a lean UX team. A lot of things we know is based on assumptions that need to be validated. There is no designer, manager or client that knows the absolute truth and thus should, therefore, be followed blindly. Testing is our hero.

Moving from doubt to certainty

At the beginning of the lean UX process, stakeholders and team members gather to collect the hypotheses that will form the basis of the process. After conducting research, these initial hypotheses will change and the collection will expand as new hypotheses arise. 

All hypotheses have a level of certainty that indicate the level of effort you should apply in research to validate it. The “Truth curve” below shows the types of research that are suitable to apply relative to the level of certainty. When there is no evidence for a hypothesis, you are situated in the fantasy stage. The more evidence you have of the hypothesis the more effort you can put in research, an MVP (minimal viable product) or develop the actual product.

Lean UX at AppSaloon

While reading this book I got really excited to apply these new methods and principles. I gave a presentation to my colleagues explaining lean UX, and they were an interested audience. Some questions arose like: ‘which of our projects this process would be suitable’ and ‘how to set a budget’. 

I believe for this process to work, there needs to be a clear return on investment of the product you are working on. If a website’s only purpose is to inform the customers of your product or service, the improvements to this website will be of small value. When compared to a website or tool which, itself, is one’s source of income, the value of continuous improvements increases greatly. I believe the lean UX process will be the most valuable for these kinds of projects.

Setting a budget is always hard. This is why we typically start a new project with an analysis phase. When this phase is completed, we will know the exact requirements, and we can do a proper price estimation. When starting a lean UX process, this will happen differently, as the requirements are not set and constantly changing. To find a solution to this issue, I consulted some professionals active in agile consultancy. They advised me to determine the resources (who will be working for how long) and budget of the project, not the deliverables. By regularly communicating with the client about the findings and how the decisions affect the budget they can still regulate their investments. 

A first step I took towards the lean UX process was involving developers in the design process. It wasn’t easy figuring out who to involve, as our management generally doesn’t assign a developer that early in the process. Therefore, I asked a colleague (developer) to help me out by providing some feedback on the implications for the development of the design decisions I was making. Eventually, he was assigned to the project because he knew most about it.

In the meantime, I dug deeper into design systems and started creating them for several projects. Having these systems prepared will make it easier to evolve to the lean UX process in the future. 

I am looking forward to getting more experience in this process and hope you are, too! If you want to learn more about lean UX, don’t hesitate to reach out to us!