Applying the LeanUX process, part 1

LeanUX is a collaborative, iterative process meant to promote and prioritize iteration and feedback to create solid designs quickly. Traditional waterfall and agile techniques haven't kept up with modern needs.

At my company, I spearheaded an effort to incorporate LeanUX into our Software Design process. After facilitating a few projects, I had a process that was inspired by LeanUX, but tailored to my company's specific structure and work style.

I initially decided to write this guide as an internal reference so that others within the company could facilitate LeanUX design processes. However, once it was done I realized that it could help to educate others as well that are attempting something similar within their own companies.

You may find that this process works well within your company, or you may find you need to deviate from it.

Why LeanUX?

Within my company, our agile development process had, historically, not accounted for user feedback. We made assumptions about our products and then built our products based on those untested assumptions. Only after the product launched did we get a chance to validate or invalidate those assumptions.

This is a costly way to develop code, and it resulted in wasted time and money and products our customers didn't always love.

By comparison, LeanUX is a highly iterative process that incorporates user feedback as a core part of the iteration, meaning feedback comes sooner and more often.

Is LeanUX right for your team?

We spent around a year using and perfecting this process. At the end of that year we decided that, while LeanUX brought with it a number of benefits, it did not fit the needs of our team as well as other processes.

Internally, we have since moved on to another process. Take a look at both to see which approach would be a better fit for you.

For my company, our employees frequently work on multiple project teams at once. LeanUX doesn't really account for this. This made it difficult to get everyone in the room for every decision.

Another detriment is that LeanUX requires a lot of time in meetings, which was costly and inefficient for us. Employees complained that they had nothing to contribute during collaborative design sessions, and they had other work that was not being done.

In the end, shared understanding promoted by LeanUX was not enough of a selling point for us. We have since moved onto a new process that shares some elements of LeanUX, but reduces how much time our team spends in group conversations.

Take a look at the other process and see which one works better for your situation.

LeanUX Process Benefits

Organizes around outcomes, not features

Reframing our requirements around outcomes instead of features means every feature has a business justification before any design or development time is devoted to it. This increases the quality of our applications because unjustified feature requests do not make it through the process. This results in less churn because only well-formed ideas make it into the designs.

Prioritizes experiments over assumptions

The LeanUX prioritizes learning and data over assumptions, which means that the major decisions made in your product are backed up by actual experimental data. Team assumptions that do not stand up to user tests are modified or discarded, and features that are born from user tests will have a clear justification for why they should be included in the product.

Prioritizes shared understanding over documentation

Shared understanding means everyone on the team should be included in the decision-making process. This has a few benefits:

1. This allows the entire team to leverage their product knowledge and expertise

2. It allows developers to have input into the design to smooth out any development concerns before the design is locked in

3. It lessens the need for lengthy documentation that quickly gets out of date

Critical Roles

Facilitator

The Facilitator is responsible for ensuring that this process is run correctly. They schedule the major team meetings and keep the process moving forward. They are responsible for running the planning phase of the process until the team begins to create their MVP. After the initial MVP is created and the team has begun to get feedback the Facilitator may be able to step back and let the team schedule their own meetings and dictate their own pace. This is based on the makeup of the team and their individual needs and preferences.

The Facilitator should be aware of the team’s information needs and work with them to answer key questions. This may include inviting an architect or other project’s stakeholder to a meeting from time to time in order to fill in any information gaps the team may have.

Decider

The Decider is responsible for making key decisions and breaking ties. This person is typically the product owner but could be an executive or some other high-level role within the company. There should only be one Decider on a project, otherwise there could be confusion. Also, multiple deciders make it tough to break ties.

Process Flow

LeanUX is a cyclical process. It is a series of steps that are repeated multiple times for the life of the project.

Spend the time up front to plan

Lean UX front-loads the planning to force the team to think about the benefits of their products. This seems daunting up front, but it means that the after the process is completed the team can focus on designing and gathering data about their experiments. This ultimately results in a better product and less waste because ideas that cannot be demonstrated to work or that do not deliver value are discarded in favor of better ideas.

Create MVP (Or MMF: Minimum Marketable Feature)

The next step is to generate a testable prototype. Depending on the team composition and preferences the prototype can consist of the following:

• sketches on paper

• a PowerPoint presentation

• a clickable prototype like from Adobe XD or Figma

• executable computer code

The point is to generate something quickly that the team can use to gather data about the product assumptions the team has made.

The basic design should be generated during collaborative design sessions with the core team.

Ensure all features are represented or accounted for (User Stories). If features are dropped it should be intentional and for a specific reason.

Test MVP with users

Before the prototype is completed, the team should start to agree on the core test cases that they want to validate. These can be turned into tests.

Apply learning

Take the lessons you learn from the user test and apply them to your MVP.

This is also where your team may incorporate new requirements into the design.

The “planning” phase will be shorter during the iterations due to the up-front work your team has done, but any new learning or any additional requirements that need to be addressed should be worked as part of the planning phase. Any invalidated assumptions should be noted. Any new hypotheses should be incorporated into the plan and added to the design and MVP for testing.

Repeat…

This process can continue until everyone is happy with the test results, or it can be limited to just a few or even one user testing session. The point is to gather data to support or invalidate the design assumptions made in the original MVP. Any amount of testing will lead to a better product.

The goal is to back all assumptions with data derived from user tests. This will create a better foundation of knowledge and will have far-reaching consequences for the quality of future products.

It is important to remember that this is a collaborative process, but it is also a process where team members can and should work in parallel when it makes sense.

Next Steps

Check out part 2 of the series for a step-by-step breakdown of how to facilitate your first LeanUX meeting at your company.

Or, check out part 3 for worksheets and FAQs that can help you jump in right away.