A beginner’s guide to Lean UX (+ 5 lessons from Jeff Gothelf)
When it comes to creating experiences that blow your users away, a good management system is key.
It’s not enough to design a product and hope your users are happy with it. You need a process that allows you to create that product, and then make changes if need be.
And this requires is some collaborations between teams and departments, as well as frequent interactions with your users.
That might seem like a lot to handle. After all, how can you keep up with the constant flux of your users’ needs and expectations while involving multiple teams and stakeholders?
Enter Lean UX.
Lean UX is a design management system built to help create well-designed products through frequent collaboration between teams, constant iteration, and frequent contact with your users.
Like many design systems, Lean UX contains a lot of moving parts. But once your team gets going with it, you’ll find that it’s an intuitive, fruitful way to get fast insights on what your users want.
That’s why we want to walk you through what exactly Lean UX is, its benefits for designers, and how you can start applying the process to your own company.
What is Lean UX?
Jeff Gothelf, organizational designer and UX design team leader, introduced Lean UX to the world when he published Lean UX: Designing Great Products with Agile Teams in 2013.
He helped develop the system after seeing frustrations with his team at TheLadders. They even created a diagram breaking down the exact pain points they were having with their management system.
He took what he learned with his team and developed Lean UX. He’s since spent the past few years teaching the system to all who will listen.
The book laid the groundwork for different ways that companies handle their UX process, and introduced a system that emphasizes the following:
- Removing waste. The system seeks to cut through common, time-consuming tactics like frequent documentation by creating minimal viable products that drive learning quickly.
- Constant collaboration. Lean UX brings together teams from “designers, developers, product managers, quality assurance engineers, marketers, and others” through frequent contact and communication (From Lean UX).
- More experimentation. Designers leverage rapid experimentation with their designs to uncover more grounded information and lessons on their products.
At the heart of Lean UX is the idea of radical transparency. Each team needs to communicate to one another their findings often in order to address any roadblocks and do the work needed to deliver a product quickly.
From Lean UX:
“By having these conversations early and often, the team is aware of everyone’s ideas and can get started on their work earlier. If they know that the proposed solution requires a certain backend infrastructure, for example, the team’s engineers can get started on that work while the design is refined and finalized. Parallel paths for software development and design are the fastest route to reach an actual experience.”
Once you break down the walls of communication between members of your team, then you’re primed for Lean UX.
As such, Lean UX is much less of a system than it is a mindset that each member of your company must adopt if you want to see success.
How the Lean UX process works
Before you jump into the Lean UX process, you need to remember what Gothelf says: Lean UX is a mindset.
In order for a mindset to become effective it needs to be adopted by everyone in your company.
From Lean UX:
“This reframing requires an organization-wide position of humility. It requires teams and managers to use their knowledge and skills and creativity as scientists might: they propose their best solution and then they test to see if they’re right.”
All members of your organization need to be on board and understand Lean UX for it to be effective.
With that, let’s take a look at the process itself.
The system can be broken down into four processes:
- Outcomes, assumptions, hypotheses
- Creating the MVP
- Research and Learning
Let’s take an overview of each and see how they work.
Note: This is a BRIEF overview. There’s a lot to be said about each section. To gain a fuller understanding of the Lean UX and the full process, pick up a copy of Lean UX and read it for yourself.
Outcomes, assumptions, and hypotheses
Where most software creation processes focus on features and deliverables, Lean UX shines a light on the outcomes of the product and how they benefit (or don’t benefit) the user.
To create good outcomes, Lean UX shifts away from what designers think is required of a product to their assumptions.
Assumptions are simply your belief or expectation based on what you know about your users.
Yes, these are filled with risk and can be outright wrong. But they’re important to create a launching point for your team.
There are four types of assumptions:
- Business outcomes. This is what done looks like. How do you know your product was successful?
- Users. The people you’re creating your product for. Who are they? What’s their persona look like?
- User outcomes. This is what your users want from your product. What are their pain points? How can your product solve them?
- Features. How you will improve your product going forward in order to give your users the desired outcome.
From your assumptions, you’re going to then move onto creating a hypothesis. This involves turning your assumptions into hypotheses statements.
Example: We believe our users are middle-aged homemakers who need help with their housework. We will know we’re right if we see an increase in app usage and hear that it has helped them save time on housework.
The hypotheses is a great way to establish what you believe you know about your users and what they need. This is the groundwork for your work going forward.
This is where you begin to actually design your product. This might also be the time where you can test your hypotheses.
From Lean UX:
“For example, if you’re in the early stage of a project, you might test demand by creating a landing page that will measure how many customers sign up for your service.”
And it’s not enough to shut your team of designers in a room slowly filling with water and force them to design a product before they drown (too specific?). Remember: You must design collaboratively.
For example, the teams from across departments must sketch and create wireframes together, and everyone must feel comfortable giving their feedback on everything. Designers should see themselves as facilitators to these conversations and meetings.
There are a variety of different ways you can structure your meetings and conversations as your designs progress. For more, check out chapter four of Lean UX.
All of this work becomes part of the minimum viable product.
MVP (Minimum viable product)
What’s the least amount of work we can do to learn more about our hypothesis? That’s the question behind your minimum viable product (MVP).
We’ve written about this before, but an MVP is the most basic expression of your product. The idea is to get a simple product out to see how your target audience reacts to it.
In The Lean Startup by Eric Riess, MVP is defined as “a version of a new product which allows a team to collect the maximum amount of validated learnings about customers with the least effort.”
And your MVP can come in a variety of different shapes. Here are a few:
- Wireframes. Low-fidelity versions of your product. For more, here’s our article on how to create a wireframe.
- Mockups. Higher-fidelity, full-scale versions of your product complete with designs, colors, and icons.
- Prototypes. Very basic version of your product with minimal functionality and design. For more, check out our guide on rapid prototyping.
You need to build your MVP based on your assumptions and hypotheses. Your target audience’s reaction and feedback to your MVP will give you the most insights into whether you’re on the right track.
If you’d like to learn about how to create a MVP, read our article all about it here.
Once you have your MVP, it’s time to take a deep dive into how your users are reacting.
Research and learning
This part of the process is all about validation.
Are you on the right track? Is your product giving your users what they need? What needs to be changed?
Research and learning requires two things to be effective in Lean UX:
- Continuous. Bake “small, informal, qualitative research” techniques into every sprint (from Lean UX).
- Collaborative. Teams must work cross-functionally instead of in individual silos to “build shared understanding” (from Lean UX).
The goal is for your organization to gain insights in a quick but comprehensive way. This can only happen if you research frequently and collaboratively.
Your users will be a part of this process as well, whether through conversations, interviews, surveys, or whatever else. The conversations you get will validate your hypotheses. Once you know what you need to change and improve, it’s time to start back up at the top and do everything again!
Rinse and repeat until you have a product that satisfies your users’ needs.
Should you use Lean UX?
While there are plenty of great benefits to Lean UX, there are five that might sway you to trying it out for yourself:
- Increased collaboration
- Improved outcomes
- Streamlined feedback process
- Reduced time-to-market
- Strengthened user research
Lean UX teams are traditionally cross-functional.
This means that they involve people from across a variety of different disciplines to work together when creating a product.
“Diverse teams create better solutions, because each problem is seen from many different points of view,” writes Gothelf. “Creating diverse teams limits the need for gated, handoff-based processes. Instead, teams can share information informally, which creates collaboration earlier in the process and drives greater team efficiency.”
Rather than focus on output (the end product), Lean UX relies on the product’s outcome (how the product impacts the user).
“Although it’s easy to manage the launch of specific feature sets, we often can’t predict a feature will be effective until it comes to market,” Gothelf writes. “By managing outcomes (and the progress made toward them), we gain insight into the efficacy of the features we are building.”
This gives designers the freedom to produce minimum viable products quickly based on their assumptions and see how it performs. If it doesn’t perform well, they can respond and make tweaks as necessary.
Gothelf continues, “If a feature is not performing well, we can make an objective decision as to whether it should be kept, changed or replaced.”
This ties in with the next benefit of Lean UX:
Streamlined feedback process
Lean UX is built upon the concept that it’s more beneficial for designers to do rather than talk about doing.
“There is more value in creating the first version of an idea than spending half a day debating its merits in a conference room,” writes Gothelf.
When you create a product, the most important feedback you can get isn’t from a manager or a member of your team. The most crucial feedback and critiques come from your users (i.e. the people who will actually be using your product).
If you spend your time deliberating and falling into the dreaded “paralysis by analysis,” you create waste—which you do not want with Lean UX.
That brings us to …
The system of Lean UX trims the fat that most design processes experience by removing aspects that don’t contribute to creating a product for the users.
Whatever doesn’t contribute to that goal is waste—and is cut out mercilessly.
According to Lean UX methodology, at the heart of each of your decisions should be the question, “Does this really help us create a good product for the users?” If the answer is no, then you probably shouldn’t be doing it.
This applies to meetings, documentation, and even the stakeholders. Your users should come first with each of your design decisions—that brings us to…
Strengthened user research
Like any good design process, Lean UX puts the user first. However, Lean UX puts an emphasis on including the user as early and often as possible.
How? With GOOB.
No, that’s not something that a kid would call you on the schoolyard (though, it’s probably that too). GOOB stands for “getting out of the building.”
It’s the idea that teams shouldn’t just be cooped up in the offices arguing about minutiae about a design. Instead, they should actually go out into the world and get feedback from their users—and they should do it sooner rather than later.
“Test your ideas with a strong dose of reality while they’re still young,” writes Gothelf. “Better to find out that your ideas are missing the mark before you’ve spent time and resources building a product that no one wants.”
Before you do anything, be sure to head to your local bookstore to pick up a copy of Lean UX.
Like we said earlier, this is a very brief overview of the process. To gain a fuller understanding of Lean UX and how exactly you can apply it to your team, be sure to pick up a copy for yourself. Better yet, make sure everyone on your team has a copy too.
Best of luck—and be sure to let us know about your experiences with Lean UX!