by Jeff Gothelf
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, as measured by the market’s reaction to it.
Wrapping Up
This chapter put forward a set of foundational principles for Lean UX. These are the core attributes that any Lean UX team should strive to embody. As you begin to form your practice, we encourage you to use these principles to define your team’s make up, location, goals, and practices.
In Part II, we put these principles into action as we detail the entire Lean UX process.
1 Don Norman and Jakob Nielsen, “The Definition of User Experience”, Nielsen Norman Group.
2 Tim Brown, “Design Thinking”, Harvard Business Review, June 2008.
3 YouTube, “Why You Need to Fail - by Derek Sivers”, Feb 15, 2011.
Part II. Process
It’s Tuesday, and Rick, Mark, Olga, and Arti are standing at the whiteboard, looking at a wireframe that they’ve drawn. Arti has a marker in her hand, but she’s not drawing. “Rick, I don’t understand what you’re driving at. Can you explain the problem?” she asks.
Rick takes the marker, wipes clear a section of the board, and explains the regulation, again. The team is designing an app for stock traders, and the app must obey a strict set of regulations. Rick, the business analyst, is responsible for making sure that the team’s designs support the rules.
After a while, the team is nodding, and Arti takes the marker again. She suggests a change to the wireframe design of the app on the board and the team nods again. They all take out their iPhones, take photos of the board, and agree to reconvene the next day. They’re confident that what they’ve agreed on will be ready for user-testing on Thursday.
Arti, the designer, goes back to her desk to begin detailing out the design they’ve sketched. Mark, the frontend developer, begins building the page—he uses components from the Design System the team has built, so he doesn’t need to wait for Arti before getting the basic pieces in place. Rick opens the project’s wiki page and begins to document the decisions the team has made about the application’s behavior. He’ll review these choices with the product owner later in the day. And Olga, the QA tester, begins the process of writing tests for the new section of the app.
This is the day-to-day rhythm of Lean UX: a team working collaboratively, iteratively, and in parallel, with few handoffs, minimal deliverables, and a focus on working software and market feedback. In this section, you’ll see how it’s done.
About Part II
In the previous part, we looked at the ideas behind Lean UX—the principles that drive the work. In this section, we get very practical and describe in detail the process of doing Lean UX.
The Lean UX Process
Chapter 3 describes how to frame our work. Lean UX radically shifts the way we frame our work. Our goal is not to create a deliverable. It’s to change something in the world—to create an outcome. In this chapter, we describe the key tools we use to do this: hypothesis statements.
Chapter 4 describes the shift in our design process. Lean UX uses many techniques familiar to designers but shifts the emphasis of our work. We become more collaborative. We aim for speed first. We prioritize learning. We use a key tool to achieve this: the Minimum Viable Product.
Chapter 5 is about experiments. Lean UX is based on the idea that we begin our work with an assumption. We use experiments to test our assumptions and then build on what we learn in those experiments. This chapter shows you how to orient your design process around experiments and learning.
Chapter 6 is about feedback. UX in any form requires good input from users. Lean UX puts a premium on continuous feedback to help guide our design process. This chapter shows you techniques that Lean UX teams use to get feedback early and often and how to incorporate that feedback into future product iterations.
Chapter 3. Driving Vision with Outcomes
If it disagrees with experiment, it’s wrong.
—Dr. Richard Feynman
Traditionally, software projects are framed by requirements and deliverables. Teams are given requirements and are expected to produce deliverables that describe how the features that satisfy those requirements will look, behave, and perform. In many cases, the strategic context for those requirements is not communicated, is missing, or is simply not considered. Lean UX radically shifts the way we frame our work by introducing back the strategic context for our feature and design choices and, more important, how we—the entire team, not just the design department—define success. Our goal is not to create a deliverable or a feature: it’s to positively affect customer behavior or change in the world—to create an outcome.
Why focus on outcomes instead of features? It’s because we’ve learned that it’s hard—and in many cases impossible—to predict whether the features we design and build will create both the strategic as well as tactical value we want to create. Will this button encourage people to purchase? Will this feature create more engagement? Will people use this feature in ways we didn’t predict? Will we successfully shift the way people interact with our service? So, rather than focus on the feature, it’s better to focus on the value we’re trying to create, and keep testing solutions until we find one that delivers the value—the outcome—that we desire.
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. To reduce the risk of investing too heavily in the wrong features, designs, and engineering implementations, we soften our stance from what is “required” to what is “assumed” to be true. These assumptions—still very much loaded with risk—are our best guess given our current state of knowledge. We know that as we begin to research, design, develop, and test, new information will be revealed, and this new information will undoubtedly force course corrections. It’s for these reasons that we begin with outcomes and assumptions instead of features and requirements.
Using the Right Words
Langu
age, in this case, is important. Requirements present a seemingly immutable path forward. Assumptions explicitly admit that we might be wrong. We use our assumptions to create and test hypotheses. If you’re familiar with Test-Driven Development (TDD), hypotheses are very similar. They are, in a way, a form of Test-Driven Product Design and Development. We write the test first—the hypothesis. We design and/or develop just enough product (i.e., experiments and Minimum Viable Products [MVPs]) to see if the hypothesis is true. These small tests reduce the risk of going too far forward in the wrong direction. We use objective measures of customer behavior to determine if we’ve achieved our desired outcomes. It is these outcomes that are our definition of progress and ultimately, our new definition of done. Figure 3-1 offers an overview of the process.
This chapter digs into the main tool of outcome-focused work: the hypothesis statement. The hypothesis statement is the starting point for a project. It states a clear strategic vision for the work and shifts the conversation between teams, managers, and stakeholders from outputs (e.g., “We will build an iPhone app”) to outcomes (e.g., “We want to increase the amount of commerce that comes through our mobile channels.”)
Figure 3-1. The Lean UX process
Assumptions
Assumptions are our best guess based on what we know today. They are also filled with risk. Your goal as Lean UX practitioners is to reduce risk.
“We believe our primary user base should be middle school and high school students who would rather use their mobile device over any other to access school content.”
“We believe integrating the default calendar application on our users’ mobile devices is a feature they will value and use often.”
“If our users communicate with one another regularly using our app, it’s an indication that we built and designed the right features.”
Without the evidence to confirm these statements, they are all assumptions, filled with risk. Every downstream decision we make based on untested assumptions increases the risk of failure in our product. So when we find an assumption, we need to ask, How might we ensure that these statements are true as quickly (and cheaply) as possible so that future decisions stand a better chance of succeeding?
To do so, the first step in the Lean UX process is to explicitly declare your assumptions. Every project starts with assumptions, but mostly we don’t acknowledge this fact. Instead, we try to ignore assumptions, or worse, treat them as facts.
Declaring your assumptions allows your team to create a common starting point. By doing this as a team, you give every team member—designer and nondesigner alike—the opportunity to ask questions about your target audience, what problems you’re solving for those people, and how best to solve the problem. It allows the broader group to include concerns about things that might have been missed when the project was framed. This could include technical dependencies, competitive market concerns, or long-term service sustainability issues such as sourcing content. Most important, declaring your assumptions brings a group perspective to what success looks like.
Assumptions: The Big Four
There are four types of assumptions that are particularly important in Lean UX:
Business outcomes
Our success metric and definition of “done.” Business outcomes describe a measurable change we want to see in the world or in customer behavior. They are the signal we seek from the market to help us validate or invalidate our hypotheses. These are often quantitative but can also be qualitative.
Users
The people for whom we believe we are solving a problem, often modeled as personas.
User outcomes
The goals of the people for whom we are building products. These can be end goals (e.g., completing a specific task), emotional or experience goals (e.g., not feeling like a technological luddite), or long-term goals (e.g., keep as much of my money so I can retire comfortably).
Features
These are the product changes, additions, or improvements we believe will help our customers achieve their goals and drive the business outcomes we seek.
Each of these elements is critical to writing a testable hypothesis, as we’ll see later. For now, let’s take a detailed look at one way to find assumptions together as a team.
Method: Declaring Assumptions
Who
Declaring assumptions is best done as a group exercise. Gather your team, making sure that all disciplines are represented—including any subject matter experts that could have vital knowledge about your project. For example, if you’re handling a frequent customer complaint, it might be beneficial to include a customer service representative from your call center. Call center reps speak to more customers than anyone else in the organization and will likely have insight the rest of the team won’t. By working together in this cross-functional capacity you are raising the Product IQ of the entire team. Team members not only get to voice their opinions and concerns, but equally as important, they get to hear other points of view. This moves team members away from discipline-specific views of the product to a more holistic, product-focused one.
Preparation
Give the team advance notice of the problem they will be taking on. Provide them the strategic context for the work to ensure that their tactics agree with the broader goals of the organization. This gives everyone a chance to prepare any material they need, ask questions, or do any research before you begin. Important things to prepare in advance include the following:
Analytics reports that show how the current product is being used
Usability reports that illustrate why customers are taking certain actions in your product
Information about past attempts to fix this issue and their successes and failures
Justification from the business as to how solving this problem will affect the company’s performance
Competitive analyses that show how your competition is tackling the same issues
Problem Statement
The team needs to have a starting point for the exercise. We’ve found it helpful to begin with a problem statement. (See the templates for this statement that follow.) These statements are created by key stakeholders as they begin to address the strategic vision for the business. The problem statement gives your team a clear focus for their work. It also defines any important constraints. You need constraints for group work. They provide the guardrails that keep the team grounded and aligned. Creativity thrives in the constraints.
Problem statements take on slightly different flavors depending on whether you are working on an existing product or creating a brand new one. Let’s take a look at each.
Existing product: problem statement template
Problem statements for existing products are made up of three elements:
The current goals of the product or system
The problem the business wants addressed (i.e., where the goals aren’t being met)
An explicit request for improvement that doesn’t dictate a specific solution
You can use the template shown in Figure 3-2 to express your problem statement. Keep in mind though that there’s nothing magical about this template—or really any of the templates we share in this book. You should adapt the templates so that they make sense to you, your team, and your context.
Figure 3-2. Problem statement template for existing products and services
All too often, teams are tasked with poorly worded business problem statements. In fact, these are rarely problem statements at all. They are typically poorly hidden requirements requests. Take this “problem statement,” for example:
Our competitors have all shipped mobile applications in the past 12 months and are advertising them heavily. With the ongoing need to stay competitive, we too must develop more mobile products.
To achieve this, we intend to launch an iOS application by Q2 of this year and ensure that all of our marketing sites are mobile-friendly by the beginning of Q3. In addition, we
will launch a Facebook mobile ad campaign to ensure that our acquisition targets are hit this year.
This statement fails to declare a real business problem (other than feature parity concerns with our competition) nor does it indicate the impact (good or bad) this is having on the product or service. Finally, instead of providing a clear business measure of success, it lists a specific set of features and tactics the team is expected to deliver. This way of assigning work to a team does very little to raise their Product IQ or inspire any creativity in finding the right solutions. The team is tasked with a solution to implement rather than a problem to solve.
Here is an alternative version for a hypothetical company working in the educational technology space:
Our Learning Management System (LMS) was intended to provide a central platform to facilitate communication, student body management, and assessment for parents, students, and teachers in most educational contexts.
We have observed new students both in the United States and abroad entering schools with a mobile-first or mobile-only mindset. We have also observed a significant rise in funding for competing educational technology startups catering to this new behavior model. Our products are heavy and not mobile-friendly which increases our risk of losing incoming cohorts of new students through decreased usage and dependency on the LMS.