The 3 foundations of Lean UX

Lean UX stands on a number of important foundations: it’s a combination of a few different schools of thought. Understanding where it comes from will help you to apply the method and find resources when you get stuck.

The first foundation of Lean UX is user experience design. Lean UX is, at its heart, a way of practicing user experience design. Drawing on roots in the fields of human factors and ergonomics, as well as the human-centered design ideas that emerged in the 1950s with the work of industrial designers like Henry Dreyfuss, today we call these methods and mindsets user experience design (or just UX), a term credited to Don Norman. UX embraces a number of design fields, including interaction design, information architecture, graphic design, and many others. But the heart of UX practice is that it begins by identifying human needs—the needs of the users of the system.

In the past decade, we’ve seen the rise in popularity of Design Thinking. Design Thinking emerged in academia in the 1970s and 1980s, and was popularized by the design firm IDEO in the early 2000s. It is a way of applying human-centered design methods to a wide range of problems. Tim Brown, CEO and president of IDEO, described Design Thinking as, “innovation powered by…direct observation of what people want and need in their lives, and what they like or dislike about the way particular products are made, packaged, marketed, sold, and supported.”

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:

1. 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.

2. 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.

3. 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.

4. 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 implements.

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.

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. Finally, 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.

PRINCIPLE: EXTERNALIZING YOUR WORK

What is it? Externalizing means getting your work out of your head and out of your computer and into public view. Teams use whiteboards, virtual shared spaces, foam-core boards, artifact walls, printouts, and sticky notes to expose their work in progress to their teammates, colleagues, and customers.

Why do it? Externalizing work allows everyone to see where the team stands. It creates a passive, ambient flow of information across the team. It inspires new ideas that build off the ones that have already been shared. It allows all the members of the team—even the quiet ones—to participate in information-sharing activities. Their sticky notes or whiteboard sketches are equally as loud as the most prominent person on the team.

PRINCIPLE: MAKING OVER ANALYSIS

What is it? Lean UX values making over analysis. There is more value in creating the first version of an idea than spending half a day debating its merits in a conference room.

Why do it? The answer to most difficult questions the team will face will not be answered in a conference room; it’s the customers in the field who will answer them. To get those answers, you need to make the ideas concrete—you need to make something for people to respond to. Debating ideas without market-based data is waste. Instead of analyzing potential scenarios, make something and get out of the building with it.

PRINCIPLE: GETTING OUT OF THE DELIVERABLES BUSINESS

What is it? Lean UX shifts the focus of the design process away from the documents the team is creating. Instead, it focuses on the outcomes the team is achieving. With increased cross-functional collaboration, stakeholder conversation becomes less about what artifact is being created and more about which outcome is being achieved.

Why do it? Documents don’t solve customer problems—good products do. The team’s focus should be on learning which features have the biggest impact on its customers. The artifacts the team uses to gain and communicate that knowledge are irrelevant. All that matters is the quality of the product.