by Jeff Gothelf
Brown continued, “[it’s] a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”
Design Thinking is important for Lean UX because it takes the explicit position that every aspect of a business (or any other system) can be approached with design methods. It gives designers permission to work beyond their typical boundaries. It also encourages nondesigners to use design methods to solve the problems they face in their roles. So, UX and its cousin Design Thinking form the critical first foundation that encourages teams to consider human needs, collaborate across roles, and approach product design from a holistic perspective.
The next foundation of Lean UX is Agile software development. Software developers have been using Agile methods for years to reduce their cycle times, build a cadence of continuous learning, and deliver customer value regularly. Although Agile methods can pose process challenges for designers (that we’ll show you how to solve in Part II), the core values of Agile are perfectly aligned with Lean UX. Lean UX applies the four core values of Agile development to product design:
Individuals and interactions over processes and tools.
Lean UX favors collaboration and conversation over deliverables and rigid process. It engages the entire team to generate ideas from diverse points of view. It encourages the free and frequent exchange of ideas to allow the team to debate, decide, and move forward quickly.
Working software over comprehensive documentation.
Every business problem has endless solutions, and each member of a team will have an opinion on which is best. The challenge is figuring out which solution is most viable. Sometimes, it’s difficult or impossible to predict in advance which solution will work. By getting our ideas into the hands of customers (often through working software) sooner, the team can quickly assess solutions for market fit and viability.
Customer collaboration over contract negotiation.
Collaborating with your teammates and customers builds a shared understanding of the problem space and the proposed solutions. It creates consensus behind decisions. The result? Faster iterations, real involvement in product-making, and team investment in validated learning. It also lessens dependency on heavy documentation because everyone on the team has already participated in making the decisions. Collaboration creates alignment more effectively than written communication, argument, and elaborate defense.
Responding to change over following a plan.
The assumption in Lean UX is that the initial product designs will be wrong, so the team’s goal should be to find out what they got wrong as soon as possible. As soon as the team discovers what’s working and what’s not, they adjust their proposals and test again. This input from the market keeps teams agile, constantly nudging them in a “more right” direction.
The final foundation of Lean UX is Eric Ries’s Lean Startup method. Lean Startup uses a feedback loop called “build-measure-learn” to minimize project risk and get teams building and learning quickly. Teams build Minimum Viable Products (MVPs) and ship them quickly to begin the process of learning as early as possible.
As Eric puts it, “Lean Startup initially advocates the creation of rapid prototypes designed to test market assumptions and uses customer feedback to evolve them much faster than via more traditional software engineering practices.”
He continues, “Lean Startup processes reduce waste by increasing the frequency of contact with real customers, therefore testing and avoiding incorrect market assumptions as early as possible.”
Lean UX is a direct application of this philosophy to the practice of product design.
Each design is a proposed business solution—a hypothesis. Your goal is to validate the proposed solution as efficiently as possible by using customer feedback. The smallest thing you can build to test each hypothesis is your MVP. The MVP doesn’t need to be made of code: it can be an approximation of the end experience—it might not even be a product! You collect what you learn from your MVP and develop your ideas. Then you do it again.
So, What Is the Definition of Lean UX?
Inspired by Lean Startup and Agile development, it’s the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way.
We work to build a shared understanding of the customer, their needs, our proposed solutions, and our definition of success.
We prioritize learning over delivery to build evidence for our decisions.
Principles
In the rest of this chapter, we’ll lay out the principles behind Lean UX. As you explore this approach, keep these principles in mind. Think of your experience with Lean UX as a learning journey. Use these principles to keep yourself and your team on course.
We’ve organized these principles into three groups: there are principles to guide team organization, a set of principles to guide process, and a set of principles to guide culture.
Principles to Guide Team Organization
Let’s begin by taking a look at the Lean UX principles related to team organization:
Cross-functional teams
Small, dedicated, colocated
Self-sufficient and empowered
Problem-focused team
Principle: cross-functional teams
What is it? Cross-functional teams are made up of the various disciplines involved in creating your product. Software engineering, product management, interaction design, visual design, content strategy, marketing, quality assurance—these all make up a part of Lean UX teams. Lean UX demands a high level of collaboration between these disciplines. Their involvement must be continuous from day one of the project until the end of the engagement.
Why do it? Diverse teams create better solutions, because each problem is seen from many different points of view. Creating diverse teams limits the need for gated, handoff-based (“waterfall”) processes. Instead, teams can share information informally, which creates collaboration earlier in the process and drives greater team efficiency.
Principle: small, dedicated, colocated
What is it? Keep your teams small—no more than 10 total core people. Dedicate them to one project and staff it all out of the same location.
Why do it? The benefit of small teams comes down to three words: communication, focus, and camaraderie. Smaller teams are easier to keep current on project status, changes, and new learning. Dedicating your team to one project keeps team members focused on the same priorities all the time and eliminates dependencies on other teams. Having the team all in one place allows relationships to grow between colleagues.
Principle: self-sufficient and empowered
What is it? Give your teams all the capabilities they need to operate without external dependencies. Ensure that they have the tools they need to create and release software. Give them permission to figure out how to solve the problems they face and to engage with users and customers through first-hand contact.
Why do it? Teams without external dependencies are free to optimize their process for maximum efficiency. They neither want for outside resources nor do they want for external expertise. Teams that can create and release software themselves can move at a rapid pace and can maximize their learning. Finally, teams cannot learn from the market if they are not allowed to engage with the market. Teams must be able to interact with customers directly in order to get the feedback they need to create effective solutions.
Principle: problem-focused teams
What is it? A problem-focused team is one that has been given a business problem to solve, as opposed to a set of features to implement. In other words, this is a team that has been organized around an outcome.
Why do it? Assigning teams problems to solve shows trust in those teams. It allows them to come up with their own solutions and drives a deeper sense of pride and ownership in the solutions the team implem
ents.
Principles to Guide Culture
Culture and process are inextricable. Adopting Lean UX means adopting a culture of learning and curiosity. Here are the Lean UX principles that can help guide your culture toward that end state:
Moving from doubt to certainty
Outcomes, not output
Removing waste
Shared understanding
No rock stars, gurus, or ninjas
Permission to fail
Principle: moving from doubt to certainty
What is it? Software development is complex and unpredictable. Because of this, Lean UX begins with the idea that everything is an assumption until we prove otherwise. As we work, we gain clarity. Thus, we are always moving from a position of doubt to one of certainty.
Why do it? Every project begins with a set of assumptions. Sometimes, these assumptions are easy to spot; sometimes we don’t see them until it’s too late. To eliminate the risk of investing a lot of time and effort in work that’s based on bad assumptions, we begin by validating our assumptions. This means that we begin with doubt and proceed to validate what we know, as systematically and rigorously as we possibly can. In the process, our learning lets us become more certain about our positions.
Principle: outcomes, not output
What is it? Features and services are outputs. The goals they are meant to achieve are outcomes. In Lean UX, teams are trying above all to create a meaningful and measureable change in customer behavior: an outcome. Lean UX measures progress in terms of explicitly defined outcomes.
Why do it? When we attempt to predict which features will achieve specific outcomes, we are mostly engaging in speculation. Although it’s easier to manage the launch of specific feature sets, we often can’t predict if a feature will be effective until it’s in the market. By managing outcomes (and the progress made toward them), we gain insight into the efficacy of the features we are building. If a feature is not performing well, we can make an objective decision as to whether it should be kept, changed, or replaced.
Principle: removing waste
What is it? One of the core tenets in Lean manufacturing is the removal of anything that doesn’t lead to the ultimate goal. In Lean UX, the ultimate goal is improved outcomes; hence, anything that doesn’t contribute to that is considered waste and should be removed from the team’s process.
Why do it? Team resources are limited. The more a team can eliminate waste, the faster they can move. Teams want to work on the right challenges. They want to be effective. Thinking in terms of value creation and waste removal can help teams keep their laser focus where it belongs.
Principle: shared understanding
What is it? Shared understanding is the collective knowledge that builds up over time as the team works together. It’s a rich understanding of the space, the product, and the customers.
Why do it? Shared understanding is the currency of Lean UX. The more a team collectively understands what they’re doing and why, the less they need to debate what happened and can quickly move to how to solve for the new learning. In addition, it reduces the team’s dependencies on second-hand reports and detailed documents to continue its work.
Principle: no rock stars, gurus, or ninjas
What is it? Lean UX advocates a team-based mentality. Rock stars, gurus, ninjas—we use these labels to describe individual stars. Rather than focus on star performers, Lean UX seeks team cohesion and collaboration.
Why do it? Rock stars don’t share—neither their ideas nor the spotlight. Team cohesion breaks down when you add individuals with large egos who are determined to stand out and be stars. When collaboration breaks down, you lose the environment you need to create the shared understanding required to move forward effectively.
Principle: permission to fail
What is it? To find the best solution to business problems, Lean UX teams need to experiment with ideas. Most of these ideas will fail. Permission to fail means that the team has a safe environment in which to experiment. That applies to both the technical environment (they can push out ideas in a safe way), and the cultural environment (they won’t be penalized for trying ideas that don’t succeed).
Why do it? Permission to fail is the platform on which you build a culture of experimentation. Experimentation breeds creativity. Creativity, in turn, yields innovative solutions. When teams don’t fear for their jobs if they get something wrong, they’re more apt to take risks. It is from those risks that big ideas ultimately come.
The Virtues of Continuous Improvement
In a video called “Why You Need to Fail,” CD Baby founder Derek Sivers describes the surprising results of a ceramics class.3
On the first day, the instructor announced to his class that the students would be divided into two groups. Half of the students would only need to make one clay pot each during the semester. Their grades would depend on the perfection of that solitary pot. The other half of the class would be graded simply by the weight of the pots they made during the semester. If they made 50 pounds of pots or more, they’d get an A. Forty pounds would earn a B; 30 pounds, a C; and so on. What they actually made was irrelevant. The instructor said he wouldn’t even look at their pots. He would simply bring his bathroom scale to the final day of class and weigh the students’ work.
At the end of the semester, an interesting thing had occurred. Outside observers of the class noted that the highest-quality pots had been made by the “quantity group.” They had spent the entire semester working as quickly as they could to make pots. Sometimes they succeeded, and sometimes they failed. With each iteration, each experiment, they learned. From that learning they became better able to achieve the end goal: making high-quality clay pots.
By contrast, the group that made one object didn’t have the benefit of those failed iterations and didn’t learn quickly enough to perform at the same level as the “quantity group.” They had spent their semester theorizing about what would make a “grade-A” clay pot but didn’t have the experience to execute that grandiose vision.
Principles to Guide Process
Now that we have a sense of the broader organizational and cultural principles, let’s take a tactical look at how teams need to change the way they’re working:
Work in small batches to mitigate risk
Continuous discovery
GOOB: the new user-centricity
Externalizing your work
Making over analysis
Getting out of the deliverables business
Principle: work in small batches to mitigate risk
What is it? Another fundamental from Lean manufacturing is the practice of dividing work into small units, or batches. Lean manufacturing uses this notion to keep inventory low and quality high. Translated to Lean UX, this means creating only the design that is necessary to move the team forward and avoiding a big “inventory” of untested and unimplemented design ideas.
Why do it? Every project begins with assumptions. Large-batch design begins with those untested assumptions and creates a lot of design work on top of them. This means that if we find out that a foundational assumption is wrong, we must throw away a lot of work. By working in smaller batches, we can design and validate our decisions as we go, which reduces the risk of wasted work.
Principle: continuous discovery
What is it? Continuous discovery is the ongoing process of engaging the customer during the design and development process. This is done through regularly scheduled activities, using both quantitative and qualitative methods. The goal is to understand both what the user is doing with your products and why they are doing it. So you do research on a frequent basis and a regular rhythm. Research involves the entire team.
Why do it? Regular customer conversations provide frequent opportunities for validating new product ideas. By bringing the entire team into the research cycle, it develops empathy for users and the problems they face. You create shared understanding. Finall
y, as the team learns together, you reduce the need for future debrief conversations and documentation.
Principle: GOOB: the new user-centricity
What is it? It might sound like baby’s first word, but GOOB is actually an acronym for what Steve Blank, Stanford professor, entrepreneur, and author, calls “getting out of the building.” This is Blank’s name for the kind of user and customer research that the UX community has advocated for years.
In Blank, the UX community has a champion from the business world. Blank realized that the endless meeting room debates about the customer couldn’t be settled inside the office. Blank’s prescription: give potential customers a chance to provide feedback on your ideas sooner than you would have in the past. Much sooner. Test your ideas with a strong dose of reality while they’re still young. 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.
Why do it? Ultimately, the success or failure of your product isn’t the team’s decision—it’s the customer’s. They will need to click that “Buy Now” button you designed. The sooner you give them a voice, the sooner you’ll learn whether you’ve got an idea that works.
