Chapter 3. Outcomes

Traditionally, software projects are framed by requirements and deliverables. Teams are given requirements and are expected to create deliverables. These deliverables will describe systems, features, and technology that will satisfy those requirements. In many cases, requirements arrive without strategic context. Why are we doing this? For whom? What does success look like?

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.

What Business Are We In?

Lean UX means getting out of the deliverables business. We’re in the business of creating outcomes. We must focus less on the stuff we make—the documentation and mock-ups and prototypes, the features and pages and buttons—and more on generating results. To do that, we focus on only making things that generate the outcomes that we want.

Why focus on outcomes instead of features and deliverables? 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 the 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 features, 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 shift in emphasis applies both to the things that designers make as part of their process—documents, mock-ups, wireframes, specifications, prototypes—and to the way we frame our work. What is the result that our clients or stakeholders want? Sure, they may be asking us to create a website or an app. They may be asking for a new page, a new flow, some new copy. But they’re asking that for a reason—and part of our job is to understand and articulate that reason. We’ll dig into how to do that in the next part of the book. For now, though, we want to equip you with a little bit of language to help you reframe your work away from deliverables and toward results—in other words, to move from outputs to outcomes.

A Story About Outcomes

Imagine a small team working at an agency. Jono, Nicole, Alex, and Amanda are meeting with a new client for the first time. The client has hired the agency to design, build, and launch a new website that they are committed to launching later in the year.

The client team has prepared for this first meeting. They’ve prepared and sent a detailed list of requirements that the website must meet. The feature list is ambitious and, for the agency team, more than a little scary. The agency team has done their homework too. They’ve reviewed the requirements list, and they have a set of questions ready for the client.

After some introductions and pleasantries, Nicole cuts to the chase. She says, “So we’ve had a chance to review the requirements list, and there’s a lot here. One thing that would help us would be to step away from the requirements for a moment and just talk about the purpose of the site and service. Can you tell us why this service is important for your business?”

“Sure,” says Cecily, the CEO of the small company that has hired the agency. “We currently operate a very high-end adventure-travel and event-planning service for perhaps 50 clients a year. It’s a very high-touch service. We’d like to launch an online version of our service so that we can serve thousands of clients each year. We know the demand is there, but the economics require a lower-touch approach, and that’s what this website will provide.”

“That’s great,” says Nicole. Jono goes to the whiteboard and writes Impact: a successful low-touch service that allows us to serve thousands of clients each year.

Nicole continues: “And when this service is live, what will customers be able to do that they can’t do today?”

“Well,” says Cecily, pausing for a moment. “That’s a good question. Our current service is a specialized event-planning service for bespoke events in exotic locations. We do all of the planning ourselves. In our new service, we’d like event hosts who don’t require our travel expertise to be able to find event planners to work with that fit their budgets and their needs.”

“Awesome,” says Jono, who writes on the board Outcome: event hosts will meet qualified event planners for domestic and local events.

Cecily looks at the board, a bit puzzled. She says, “That’s all obvious stuff. Why does this help you?”

Nicole explains, “Well, the feature list in your requirements document is very ambitious.” This is Nicole’s polite way of explaining that the list is unreasonably long and veers frequently into speculation. She continues: “Since your deadline is pretty short, we’re going to need to filter the list and decide what to build first and what features can wait until later. Understanding the outcome our users want will help us prioritize the feature list so that we can focus on things that help customers meet each other, find projects, and bid on them together. Anything that doesn’t create that outcome will get deprioritized.”

Unpacking the Story: Output, Outcomes, Impact

Now, the story above is fiction, but it’s based on countless real kickoff meetings, and it illustrates one of the key ideas in Lean UX: Lean UX is about focusing on outcomes.

Let’s look at the story in a little more detail and talk a bit about the framework behind Nicole and Jono’s process.

First, the client arrived with a long list of requirements—these requirements described the website and the features of the site that they wanted the agency to design and build. These are the things that they wanted the agency to make: the output.

The agency team knew that the list of features was too long—it would take a long time to build everything in the requirements document—and, worse, they suspected that many of the features in that list wouldn’t be useful to end users or to the client. So the agency team was looking to get beyond the feature list.

When Nicole asked about the impact that the client was seeking, she was going to the big picture. If the CEO wanted to keep her job, what would she need to deliver to the board? We use the word “impact” to describe the highest-level targets that a business sets. These tend to be things like revenue, profit, customer loyalty. But they can also be big, strategic objectives, like Cecily’s goal to grow from a boutique provider of services into an organization with broader reach.

The problem with big targets—impact-level targets—is that there are so many ways to pursue them, and so many factors that contribute to them, that it can be difficult to know how to break down the work and how to measure progress toward that target. To address that, we use an intermediate target, called an “outcome.” In this case, the team captured the most important intermediate target they would be working toward, which was the outcome: To allow qualified professionals to meet one another and create collaborative project bids.

So, while outputs are things we make, like websites and features, outcomes are things that people do. In fact, that’s the key to our definition of outcomes. We define an outcome as “a change in human behavior that creates value.”1 When we use this definition of outcome, we are using an inherently human-centered idea to define success. When we move away from outputs—the stuff we make—and toward outcomes, we’re choosing to put humans and their needs at the center of what we do.

A deeper look at an outcome

Let’s take a closer look at the outcome in our story. First, we said that an outcome is a change in behavior. What do we mean by that? In our story, our outcome was: meet qualified professionals and create collaborative project bids. This project—if it’s successful—will encourage a behavior: professionals will meet one another online in order to create project bids together. This might be a new behavior—something that these professionals can’t do today—or it might simply be a better way to do something that they do today. Either way, we consider that a behavior change.

And what about the creates value part of our definition? Well, if our work is successful, these professionals will be able to do this new thing, and they’ll get value from being able to do it. So, then, we’ve satisfied both parts of our definition. Professionals will be able to do this new thing, and they’ll get value from doing it.

Now, what’s interesting here is that this new behavior also creates value for the organization. They benefit from this new customer behavior, because when they satisfy their customer, the customer pays them for the service, is more likely to pay them again in the future, and is also more likely to recommend the service to others. If you’re reading closely, you’ll notice that these are also customer behaviors—customers pay for service, they return for more service, they recommend the service. All of these are outcomes, too, but these outcomes don’t necessarily benefit the user. Instead, these outcomes benefit the organization.

That’s an important thing to pay attention to when we work with outcomes: who is getting value from the behavior in question? When a professional can do business more easily, they are getting that value. When the customer pays for this outcome, the organization is getting the value. In other words, value depends on your point of view. We’ll talk about this in more detail in Chapter 8. For now, just remember that every outcome comes with a point of view baked in, and it’s important to understand whose point of view we’re thinking about. (See Figure 3-2.)

Let’s look at a system like Facebook for an example of point of view. When an end user logs on to Facebook, they get value from reading and posting to the timeline. Advertisers get value when timeline users see and interact with ads. And Facebook gets value when users spend more time on the site and advertisers pay them for access to these people. If you want your system to work, you need to create a set of aligned outcomes—you need to understand the ways that different users get value and then deliver that value to them in a way that also creates value for your organization.

Figure 3-2. Aligned value

The Facebook example brings up another point of view here, which relates to the value the system creates for people who don’t directly use the system. Facebook’s impact on society is—well, let’s call it controversial. In terms of our model, they have created a way to deliver value to users, advertisers, and themselves, but at what cost to society? A robust and ethical framework for aligning value has to take into account the needs of a broad range of stakeholders—both those who directly interact with the system and those who are indirectly impacted.2

This brings us to a final point here: none of the systems that we work on can be described with a single outcome statement. They are all systems of interrelated outcomes. What’s more, all of these related outcomes combine to create the high-level impact (or impacts) that we seek. This can make working with outcomes tricky—a typical system is composed of many people performing many behaviors. It’s easy to quickly get overwhelmed. What behaviors are important? Which ones should we focus on? In coming chapters, we’ll share some techniques for discovering, understanding, and mapping these related outcomes and for navigating through this complexity to find the key outcomes to focus on.

Outcomes, Iteration, and Validation

When you shift the focus of your work from outputs to outcomes, it creates huge changes in the way you organize your work. One of the big things that changes is the finish line: how do you know when you’re done?

In the software world, we typically use requirements, specifications, and acceptance criteria to tell us when work is done. Is the software running? Does it meet the specs? Comply with requirements? Meet the acceptance criteria? Does it meet what Scrum calls the “definition of done”? These methods are good in that they can define the finish line very precisely, but they almost always ask us to evaluate the output of our work. What if we don’t want to stop there? What if we want to measure the outcomes that we’ve created?

It turns out that, in this case, we can’t stop working on a thing when we’ve finished making it. To measure outcomes, we actually need to put that thing in the world and observe how (or if) it changes people’s behaviors. In other words, while we have to complete the output, that’s not enough. We have to validate it.

The process of validating our output is inherently iterative. Most of the time, teams don’t get everything right on their first attempt. Typically, our first attempt may get some of the outcome we seek but usually not all of it. When we focus on outcomes, we see the opportunity for improvement, and we keep working on that thing until it delivers the outcomes that we set out to deliver. This is the process that Lean Startup calls the build-measure-learn loop and what the Agile community calls inspect and adapt. Whatever you call these loops, they describe an iterative approach. An approach that means the end of one-and-done. An approach that means we iterate until we achieve the outcome.

1 To learn more about outcomes, see Josh’s book Outcomes Over Output: Why Customer Behavior Is the Key Metric for Business Success (Sense & Respond Press, 2019), https://oreil.ly/7O2xZ.

2 For a good summary of the issues here, see Oz Lubling’s article “The Blurry Line between Empowerment and Exploitation in UX,” Culture Clash, February 4, 2021, https://oreil.ly/BDi2z.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.209.69.180