Leanux Sampler

Excerpt
from: Lean UX (Draft Version)

Contents of
Lean UX:
Applying Lean Principles
to Improve User Experience
Jeff Gothelf

* Included in this sample.
* Preface
Section I: Introduction and Principles
Chapter 1: Why Lean UX?
Chapter 2: Principles of Lean UX
Section II: Process
* Chapter 3: Vision, framing and outcomes
Chapter 4: Collaborative design
Chapter 5: MVP’s and Experiments
Chapter 6: Feedback and Research
Section III: Integrating with your organization
Chapter 7: Integrating Lean UX and Agile
Chapter 8: Making organizational shifts
107
Excerpt from: Lean UX (Draft Version)

Preface

The biggest lie in software is Phase Two.

If you've spent any time building digital products in the last 20

years—regardless of your role—you've felt the sting of this lie.
You set aside features and ideas for the next phase or work and
then they are gone—never to be heard from again. As a designer,
I've had hundreds, if not thousands, of wireframes and workflows
end up in this same bucket.
But did these ideas disappear because they were flawed? Did the
features that shipped actually meet customer and business goals?
Or did the team simply run out of time? They never got to Phase
Two.
108

In The Lean Startup, Eric Ries lays out his vision for how to ensure
the ideas that have the most value get the most resources. The
method Ries promotes relies on experimentation, rapid iterations
of ideas, and evolutionary processes. The entire concept of Phase
Two becomes moot.

The junction of Lean Startup and User Experience design -- and
their symbiotically beneficial coexistence -- is Lean UX.

What is Lean UX and how is it different?
The Lean principles underlying Lean Startup apply to Lean UX in

three ways. First, they help us remove waste from our UX design
process. We move away from heavily-documented handoffs to a
process that creates only the design artifacts we need to move the
team's learning forward. Second, they drive us to harmonize our
"system" of designers, developers, product managers, quality
assurance engineers, marketers and others in a transparent, cross-
functional collaboration that brings non-designers into our design
process. Last, and perhaps most important, is the mindset shift we
gain from adopting a model based on experimentation. Instead of
relying on a hero designer to divine the best solution from a single
point of view, we use rapid experimentation and measurement to
learn quickly how well (or not) our ideas meet our goals. In all of
this, the designer's role begins to evolve towards design
facilitation—and with that we take on a new set of responsibilities.

Besides Lean Startup, Lean UX has two other foundations: Design
Thinking and Agile development philosophies. Design Thinking
takes a solution-focused approach to problem-solving, working
collaboratively to iterate an endless, shifting path toward
;0=10.?4:9?B:=6>?:B,=/>;=:/@.?2:,7>A4,>;0.4K.4/0,?4:9
109

prototyping, implementation and learning steps to bring the
appropriate solution to light. Agile re-focuses software
development on value. It seeks to deliver working software to
customers quickly and to adjust regularly to new learning along the
way.
Lean UX uses these foundations to break the stalemate between the

speed of Agile and the need for design in the product-development
lifecycle. If you've struggled to figure our how UX design can
work in agile environments, Lean UX can help.

Lean UX breaks down the barriers that have kept software
designers isolated from real business needs on the one hand and
actual implementation on the other. Lean UX not only brings us to
the table – it brings our partners in business and technology to the
whiteboard to work with us on the best solutions in an ongoing
way.

I once had a large pharmaceutical client who hired the agency I
worked for to redesign their e-commerce platform with the goal of
increasing revenues by 15%. I was the lead interaction designer on
our team. In the vacuum of our office, we spent months
researching the current system, supply chain, competitors, target
audience and contextual use scenarios. We researched personas
and assembled strategic models. I designed a new information
architecture for the product catalog and crafted a brand-new
shopping and checkout experience.

The project took months. And when the work was complete, we
packaged it all up into a Powerpoint deck. This was a formidable
deck – and it had to be, considering the $600k price tag! We went
:A0=?:?30.7409?>:1K.0,9/>;09?,909?4=00423?-hour day going
110

over each and every pixel and word in that deck. When it was over,
the client clapped. (They really did). We were relieved. They loved
it. And we never looked at that deck again.

Six months after that meeting, nothing had changed on the client's
site. I don't think they ever looked at that deck again, either.

The moral of this story: Building a pixel-perfect spec might be a
route to rake in six-figure consulting fees, but it's not a way to
make a meaningful difference to a real product that is crucial to
real users. It's also not the reason that any designer got into the
product design business. We got in to build valuable products and
services, not to write specs.

Some teams I work with today create entirely new products or
services. They are not working within an existing product
framework or structure. In "green-K07/;=:50.?>7460?30>0
B0,=0
simultaneously trying to discover how this new product or service
will be used, how it will behave and how we are going to build it.
It's an environment of continual change, and there isn't a lot of time
or patience for planning or up-front design.

Other teams work with established products that were created with
traditional design and development methods. Their challenge is
different. They need to build upon existing platforms while
increasing revenue and brand value. These teams usually have
more resources at their disposal than a ground-floor startup, but
they still have to use their resources efficiently—figuring out the
best way to spend those resources to build products and services
their customers actually want.
111

As I've learned to practice Lean UX, I've had to overcome the
1007492?3,?B,>>3:B492B:=6?3,?B,>@27D
@9K94>30/:=
"not ready." Working this way requires the support of a high-
functioning team. You need to know—as a team—that you're not
2:492?:20?4?=423??30K=>??480,9/?3,?D:@J=0,77B:=6492
together to iterate your way forward. I want you to gain that
confidence, too. Within the pages of this book, I've distilled the
insights and tactics that have allowed me to create real success for
product and business teams—and real satisfaction for customers.

Who is Lean UX for?
%34>-::64>
K=>?
1:=49?0=,.?4:9/0>4290=>Bho know they can
contribute more and be more effective with their teams. But, it's
,7>:1:=;=:/@.?8,9,20=>B3:900/-0??0=B,D>?:/0K90?304=
products with their teams and to validate them with their customers.
It's also for developers who understand that a collaborative team
environment leads to better code and more meaningful work. And,
K9,77D
4?>1:=8,9,20=>—managers of user-experience teams,
project teams, business lines, departments and companies—who
understand the difference a great user experience can make.

What's in It for You?
The book is set up in three sections. Section I provides an

overview and introduction to Lean UX and its founding principles.
I lay out the reasons the evolution of the UX design process is so
critical and describe what Lean UX is. I also discuss the underlying
;=49.4;70>D:@J77900/?:@9/0=>?,9/?:8,600,9&(>@..0>>1@7

Section II focuses on Process. Each chapter takes a step in the
0,9&(.D.70,9//0?,47>.70,=7D3:B?:/:0,.3>?0;,9/B3D4?J>
important. I also share examples of how I and others have done
these things in the past.
112

The last part of the book, Section III, tackles the integration of
Lean UX practices into your organization. I also discuss the role of
Lean UX within a typical Agile development environment. Finally,
I discuss the organizational shifts that need to take place both at the
corporate level, the team level, and at the individual contributor
level for these ideas to truly take hold.

My hope is that this book will deliver a wake-up call to user
experience designers still waiting for "Phase Two." While the book
4>K770/B4?3?,.?4.>,9/?0.394<@0>?:307;0A:7A0D:@=;=:.0>>0>

Lean UX is, at its core, a mindset. As you travel down this path, I'd
love to hear about your successes, challenges and failures so that
we can keep that mindset current, relevant and productive. Email
me with your thoughts at jeff@jeffgothelf.com . I look forward to
hearing from you.

[Jeff]

P.S. - For the purposes of this book, the terms Interaction Design
and UX /0>429,=0@>0/?:/09:?0,77?30K07/>,9/7,-07>?3,?
currently reside under the User Experience and Design umbrella.
(If, Dear Reader, you call your specialty User Interface Design,
Information Architecture, Experience Architecture or any of the
myriad 9,80>.@==09?7DL:,?492,-:@?
69:B?3,??30D,=0
explicitly included in these terms.)
113

CHAPTER 3
Vision, Framing & Outcomes
"If it disagrees with experiment, it's wrong."
-‐ Dr. Richard Feynman
Traditionally, UX design projects are framed by
requirements and deliverables. Teams are given
requirements and expected to produce deliverables. 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. We start with assumptions
114

instead of requirements. We create and test hypotheses.
We measure to see if we’ve achieved our desired outcomes.
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 vision for
the work and shifts the conversation between team
members and their managers from outputs (e.g., "We will
create a single sign-‐on feature") to outcomes (e.g., "We
want to increase the number of new sign-‐ups to our
service.")
The hypothesis statement is a way of expressing
assumptions in testable form. It is composed of the
following elements:
Assumptions -‐-‐ a high-‐level declaration of what we
believe to be true.
Hypotheses -‐-‐ more granular descriptions of our
assumptions that target specific areas of our product or
workflow for experimentation.
115

Outcomes -‐-‐ the signal we seek from the market to help
us validate or invalidate our hypotheses. These are
often quantitative but can also be qualitative.
Features -‐-‐ the product changes or improvements we
believe will drive the outcomes we seek.
Personas – models of the people for whom we believe
we are solving a problem.
Let's take a look at each one of these elements in further detail.
116

Assumptions
The first step in the Lean UX process is to 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 non-‐designer alike -‐-‐ the opportunity
to voice his or her opinion on how best to solve the problem.
Going through an assumptions declaration exercise gets
everyone's ideas out on the whiteboard. It reveals the team's
divergence of opinions and also exposes a broad set of possible
solutions.
Let's take a detailed look at one way to run the
assumptions exercise.
117

METHOD: Declaring Assumptions
Who: Declaring assumptions is 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.
Preparation: Give the team advance notice of the problem
theywill be taking on. This gives everyone a chance to prepare
any material they need or do any research before you begin.
Important things to prepare in advance include:
Anlaytics reports that show how the current product is being
used
118

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. I’ve found it helpful to start with a problem
statement. (See the template for this statement below.) 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 guard rails that keep the
team grounded and aligned.
119

Problem Statement Template
Problem statements are made up of three elements:
1. The current goals of the product or system
2. The problem the business wants addressed (I.e., where
the goals aren't being met)
3. An explicit request for improvement that doesn't dictate
a specific solution
Template:
[Our service/product] was designed to achieve [these goals].
We have observed that the product/service isn't meeting
[these goals] which is causing [this adverse effect] to our
business. How might we improve [service/product] so that our
customers are more successful based on [these measurable
criteria] ?
120

For example, here is a problem statement we used to begin a
project at The Ladders:
Our service offers a conduit between job seekers and
employers trying to hire them. Through our service, employers
can reach out to job seekers in our ecosystem with employment
opportunities. We have observed that one critical factor
affecting customer satisfaction is how frequently job seekers
respond to employer messages. Currently, job seekers are
replying to these communications at a very low rate. How might
we improve the efficacy of our communication products, thus
making employers more successful in their jobs and job seekers
more satisfied with our service?
Problem statements are filled with assumptions. The
team's job is to dissect the problem statement into its core
assumptions. You can do that by running the Assumptions
Exercise, below. Note that some teams—especially teams
starting from scratch—may not have a clear problem
121

statement. That’s OK. You can still use the exercise below.
You’ll just have to expect that it may take longer to reach
consensus on some of the questions.
Running The Exercise: Business Assumptions Exercise
I like to use this worksheet (created by my partner Giff
Constable) to facilitate the assumptions discussion. There are
many ways to complete this worksheet. You can answer the
questions as a team, simply discussing each answer. Or you can
run a structured brainstorm / affinity mapping exercise for
each question. However you do it, remember that it’s
important to give everyone a chance to contribute. Also, don’t
worry if you get to the end of the exercise without clear
agreement on all of the answers. The goal is to collect
statements that reflect what you and your team think might be
true. If you have strong disagreement on a point, capture the
different perspectives.
122

Assumptions worksheets
Business Assumptions:
1. I believe my customers have a need to:
2. These needs can be solved with:
3. My initial customers are (or will be):
4. The #1 value a customer wants to get out of my service is:
They can also get these additional benefits:
5. I will acquire the majority of my customers through:
6. I will make money by:
7. My primary competition in the market will be:
We will beat them due to:
8. My biggest product risk is:
We will solve this through:
9. What other assumptions do we have that, if proven false,
will cause our business/project to fail:
User Assumptions:
123

1. Who is the user?
2. Where does our product fit in their work or life?
3. What problems does our product solve?
4. When and how is our product used?
5. What features are important?
6. How should our product look and behave?
You may discover that some of these questions don’t apply to
your project. That’s OK—you can adapt the questions to your
situation as you see fit. If you’re early in the life of your product,
you’ll probably spend more time on the business assumptions.
If you’ve got a mature product, you’ll probably focus your
energies on the user assumptions. The point is to cast a broad
net and look for assumptions in all dimensions of your project.
When you’ve completed the exercise, you will have a list of
assumptions statements. Your next step is to prioritize these
assumptions.
124

Prioritizing Assumptions: The reason we declare our
assumptions at the start of our work is so that we can identify
project risks. Now that we have a list of assumptions, we need
to figure out which ones are the riskiest ones—so that we can
work on them first. Lean UX is an exercise in ruthless
prioritization. Understanding that you can't test every
assumption, how do you decide which one to test first? I like to
create a chart like the one below and use it to map out the list
of assumptions. The goal is to prioritize a set of assumptions to
test based on their level of risk (How bad would it be if we were
wrong about this?) and how much understanding we have of
the issue. The higher the risk and the more unknowns involved,
the higher the priority is to test those assumptions.
This does not mean that assumptions that don’t make the first
cut are gone forever. Keep a backlog of the other assumptions
125

you’ve identified so you can come back to them and test them if
and when it makes sense to do so.
Hypotheses
With our prioritized list of assumptions in hand, we’re ready to
move to the next step: testing our assumptions. To do that, we
transform each assumption statement into a format that is
easier to test: the hypothesis statement.
Generally, hypothesis statements use the format:
We believe [this statement is true].
126

We will know we’re [right/wrong] when we see the
following feedback from the market:
[qualitative feedback] and/or [quantitative feedback]
and/or [key performance indicator change].
You can see that this

It’s not all numbers
format has two parts. A It’s worth noting that there’s
been a lot of backlash in the
statement of what you
design world about
measurement-‐driven design.
believe to be true, and The argument is that by
reducing every design decision
statement of the market to factors that can be
measured, we take the delight
feedback you’re looking and soul out of our products. I
actually agree with this
for to confirm that you’re
perspective, which is why I
think it’s so important to
right.
include qualitative feedback in
your success criteria. Are
Expressing your people delighted by a design?
Do they recommend your
assumptions this way product to their friends? Do
they tweet about it? When you
turns out to be a really look for success metrics,
remember that it’s not all
powerful technique. It numbers.
takes much of subjective and political conversation out of the
decision-‐making process and instead orients the team towards
127

feedback from the market. It orients the team towards their
users and customers.
Sub-hypotheses: breaking it down into smaller parts
Sometimes—if not most of

The importance of
benchmarks
the time—you will discover
Remember, none of your
that your hypothesis is too metrics will be meaningful
if you don't have a
big to test with one test. It benchmark in place prior
to writing your
will contain too many hypotheses. That
benchmark -‐-‐ the current
moving parts, too many sub-‐ state of the metrics you're
using to determine your
hypotheses. When this idea's success -‐-‐ needs to
be captured ahead of time
happens, I find it helpful to to ensure the team knows
what it's targeting
break the hypothesis down
into smaller and more specific parts. And though there are
many ways to do this, for product work I have found that this
format is very helpful:
We believe that
128

[doing this/building this feature/creating this
experience]
for [these people/personas]
will achieve [this outcome].
We will know this is true when we see
[this market feedback, quantitative measure, or
qualitative insight].
The first field is completed with the feature or improvement
you're considering making to your product. The second field
describes exactly which of your target customers will benefit
from this feature. The last field speaks to the benefit those
customers will get from that feature. The final statement ties it
all together. This is the statement that determines whether
your hypothesis was true. What market feedback will you look
for to indicate that your idea is correct? This could be
quantitatively measured usage of a feature. It could be an
129

increase in a business metric or it could be a qualitative
assessment of some sort.
Let's take a look at an example of how this works by going back
to the problem statement we look at earlier from TheLadders:
Our service offers a conduit between job seekers and
employers trying to hire them. Through our service, employers
can reach out to job seekers in our ecosystem with employment
opportunities. We have observed that one critical factor
affecting customer satisfaction is how frequently job seekers
respond to employer messages. Currently, job seekers are
replying to these communications at a very low rate. How can we
improve the efficacy of our communication products, thus
making employers more successful in their jobs and job seekers
more satisfied with our service?
130

I mentioned earlier that the assumption that recruiters
would use another channel to engage with candidates was not
proven and needed to be tested. How would we write the
hypothesis for that statement? Let's take our template and fill
it out:
We believe that
creating an efficient communication system within
TheLadders experience
for recruiters and employers
will achieve a higher rate of contact success and an
increase in product satisfaction.
We will know this is true when we see an increase in the
number of replies from job seekers to recruiter contacts
AND an increase in the number of messages initiated by
recruiters in our system.
131

Completing your hypothesis statements
To create your hypothesis statements, you will need to
start assembling the building blocks. You are going to want to
put together a list of outcomes you are trying to create, a
definition of the personas you are trying to service, and a set
of the features you believe might work in this situation. Once
you’ve got all of this raw material, you can put them all
together into a set of statements. Let’s take a closer look at
each of these elements.
Outcomes
When you’re creating hypotheses to test, you want to try to be
very specific regarding the outcomes you are trying to create. I
discussed earlier how Lean UX teams focus less on output (the
documents, drawings, even products and features that we
create) and more on the outcomes that these outputs create.
Can we make it easier for people to log into our site? Can we
encourage more people to sign up? Can we encourage greater
collaboration among system users?
132

Together with your team, look at the problem you are
trying to solve. You probably have a few high-‐level outcomes
you are trying to create. (Increasing sign-‐ups, increasing usage,
etc.) Consider how you can break down these high-‐level
outcomes into smaller parts. What behaviors will predict
greater usage? More visitors to the site? Greater click-‐through
on email marketing? Increasing number of items in the
shopping cart? Sometimes, it’s helpful to run a team
brainstorm to create a list of possible outcomes that you
believe will predict the larger outcome you seek.

133

In this example from Giff Constable, an executive leadership team
brainstormed and then voted on which KPI's the company should
pursue next. After consolidating down to the list shown in the
photo, each executive was given 4 M&M's. As long as they
managed not to eat their votes, these executives were able to
vote with candy for each metric they felt was most important.
Ties were broken by the CEO.
134

Personas
If your team already
has a well-‐defined set of
personas, the only thing
you need to consider at
this point is which ones
you will be using in
your hypothesis
statements. If you don’t
have personas yet
though, this section will tell you how we like to create personas
for the Lean UX process.
Proto-personas: Designers have long been advocates for the
end user. Lean UX is no different. As we make assumptions
about our business and the outcomes we'd like to achieve, we
still need to keep the user front and center in our thinking.
135

Most of us learned to think about personas as a tool to
represent what we learned in our research. And it was often
the case that we created personas as the output of lengthy,
expensive research studies. The problem with personas that
are created this way is that we think this is the only way that
we can create personas. And we tend to regard them as
untouchable because of all of the work that went into creating
them.
In Lean UX, we change the order of operations in the
persona process. When creating personas in this approach, we
start with assumptions and then do research to validate our
assumption. Instead of spending months in the field
interviewing people, we spend a few hours creating proto-‐
personas. Proto-‐personas are our best guess as to who is using
(or will use) our product and why. We sketch them on paper
with the entire team contributing—we want to capture
everyone’s assumptions. Then, as we learn from our ongoing
research we quickly find out how accurate our initial guesses
136

are and how we’ll need to adjust our target—and thus our
design.
137

Using proto-personas.
A team we were working with in New York w as building an app that
improved the Community Supported Agriculture (CSA) experience for
New York City residents. CSA is a program that allows city residents to
pool their money and purchase an entire season's worth of produce
from a local farmer. The farmer then delivers his crops, weekly, to the
members of the CSA. Many subscribers to the CSA are men and
women in their late 2 0's and early 30's who need to juggle a busy
work life, an active social life and a desire to participate in the CSA.
The team assumed that most CSA consumers were w omen

who liked to cook. They spent about an hour creating a p ersona
named Susan. But when they went out into the field to do research,
they quickly learned that the overwhelming majority of cooks, and
hence potential users of their app, were young men. They returned to
the office and revised their persona to create Timothy:

Timothy proved to be a far more accurate target user. The team had
not wasted any more time refining ideas for the wrong audience. They
were now focused on an audience that, while still not perfect, w as far
more correct than their initial assumptions.

138

Persona format:
We like to
sketch proto-‐
personas on paper
using a hand-‐drawn
quadrant. (Or try
folding a sheet of
paper into four
boxes.) The top-‐left
quadrant holds a
rough sketch of the persona, and his or her name and role. The
top-‐right box holds basic demographic information. Try to
focus on demographic information that predicts a specific type
of behavior. For example, there may be cases where the
persona's age is totally irrelevant while their access to a
specific device, like an iPhone, will completely change the way
they interact with your product.
139

The bottom half of the proto-‐persona is where we put
the meat of the information. The bottom-‐left quadrant contains
the user's needs and frustration with the current product or
situation, the specific pain points your product is trying to
solve, and/or the opportunity you’re trying to address. The
bottom-‐right quadrant contains potential solutions for those
needs. You’ll use the bottom right to capture feature and
solution ideas.
Persona creation process: As with the other elements of the
hypothesis statement, we like to start the persona creation
process with a brainstorm. Team members offer up their
opinions on who the project should be targeting and how that
would affect their use of the product. Once the brainstorming is
complete, the team should narrow down the ideas to an initial
set of 3-‐4 personas they believe are most likely to be their
target audience. Try to differentiate the personas around needs,
and roles, rather than by demographic.
140

Features: Once you have a list of outcomes in mind, and have
set a focus on a group of users, it's time to start thinking about
what tactics, features, products and services you can put in
place to achieve them. This is typically the part where
everyone on the team has a strong opinion—after all, features
are the most concrete things we work with, so it’s often easiest
for us to express our ideas in terms of features. Too often
though, our design process starts when someone has a feature
idea, and we end up working backwards to try to justify the
feature. In Lean UX, features exist to serve the needs of the
business, the customer, and the user.
Feature brainstorming process: Employing the same
techniques described earlier, we like to create feature lists by
brainstorming them as a team. We’re looking for features we
think will drive customer behavior in the desired direction.
Have each team member write each idea, using a thick Sharpie,
141

on a post-‐it note. When time is up, ask everyone to post their
notes to the wall have the group arrange them into themes.
Assembling your sub-hypotheses:
With all of your raw material created, you’re ready to organize
this material into a set of testable hypotheses. We like to create
a table like the one below and then complete it by using the
material we’ve brainstormed.
We will for In order to
achieve
[create this [this persona] [this outcome.]
feature]

142

As you write your hypotheses, consider which persona(s)
you're serving with your proposed solutions. It's not unusual
to find solutions that serve more than one at a time. It’s also
not unusual to create a hypothesis in which one feature drives
more than one outcome. When you see that happening, split
the hypothesis into two parts—you want each statement to
refer to only one outcome. The important thing to remember in
this whole process is to keep your ideas specific enough so that
you can create meaningful tests to see if your ideas hold water.
When your list of hypotheses is complete you’re ready
(finally!) to move on to the next step: design. If you’ve done the
process to this point with your whole team (and I strongly
recommend that you do) you’ll be in a great position to move
forward together. This process is a really effective way to
create a shared understanding and shared mission across your
whole team.
#
143

In this chapter we discussed how we can reframe our work in
terms of outcomes. This is a vitally important Lean UX
technique: framing our work with outcomes frees us (and our
teams) to search for the best solutions to the problem at hand.
We looked at the process of declaring outcomes. We start with
the project's problem statements and then acknowledge our
assumptions. We transform these assumptions into hypotheses.
We learned how to write hypothesis statements that capture
our intended features, audience, and goals and that are specific
enough to be tested. We end up with statements that will serve
as our roadmap for the next step of the Lean UX process:
collaborative design.
In the next chapter we will cover what collaborative design is
and how it differs from traditional product design. We'll discuss
specific tools and techniques that empower teams to design
together and we’ll show you how designing together is the
beginning of the hypothesis validation process.
144

Leanux Sampler

Uploaded by

Copyright:

Available Formats

Leanux Sampler

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Leanux Sampler

Uploaded by

Copyright:

Available Formats

Excerpt

from: Lean UX (Draft Version)

Section I: Introduction and Principles

Chapter 1: Why Lean UX?

Chapter 2: Principles of Lean UX

Section II: Process

* Chapter 3: Vision, framing and outcomes

Chapter 4: Collaborative design

Chapter 5: MVP’s and Experiments

Chapter 6: Feedback and Research

Section III: Integrating with your organization

Chapter 7: Integrating Lean UX and Agile

Chapter 8: Making organizational shifts

The biggest lie in software is Phase Two.

If you've spent any time building digital products in the last 20

The Lean principles underlying Lean Startup apply to Lean UX in

Lean UX uses these foundations to break the stalemate between the

The book is set up in three sections. Section I provides an

Vision, Framing & Outcomes

"If it disagrees with experiment, it's wrong."

-­‐ Dr. Richard Feynman

Traditionally, UX design projects are framed by

requirements and deliverables. Teams are given

requirements and expected to produce deliverables. Lean

world-­‐-­‐to create an outcome. We start with assumptions

We measure to see if we’ve achieved our desired outcomes.

This chapter digs into the main tool of outcome-­‐focused

work: the hypothesis statement. The hypothesis statement

the work and shifts the conversation between team

members and their managers from outputs (e.g., "We will

create a single sign-­‐on feature") to outcomes (e.g., "We

The hypothesis statement is a way of expressing

assumptions in testable form. It is composed of the

Assumptions -­‐-­‐ a high-­‐level declaration of what we

believe to be true.

Hypotheses -­‐-­‐ more granular descriptions of our

assumptions that target specific areas of our product or

workflow for experimentation.

us validate or invalidate our hypotheses. These are

often quantitative but can also be qualitative.

Features -­‐-­‐ the product changes or improvements we

believe will drive the outcomes we seek.

Personas – models of the people for whom we believe

we are solving a problem.

assumptions. Every project starts with assumptions, but

ignore assumptions, or worse, treat them as facts. Declaring

your assumptions allows your team to create a common

member -­‐-­‐ designer and non-­‐designer alike -­‐-­‐ the opportunity

Going through an assumptions declaration exercise gets

Who: Declaring assumptions is 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

Preparation: Give the team advance notice of the problem

Important things to prepare in advance include:

certain actions in your product

successes and failures

Justification from the business as to how solving this

-‐ Dr. Richard Feynman

world-‐-‐to create an outcome. We start with assumptions

This chapter digs into the main tool of outcome-‐focused

create a single sign-‐on feature") to outcomes (e.g., "We

Assumptions -‐-‐ a high-‐level declaration of what we

Hypotheses -‐-‐ more granular descriptions of our

Features -‐-‐ the product changes or improvements we

member -‐-‐ designer and non-‐designer alike -‐-‐ the opportunity

team, making sure that all disciplines are represented -‐-‐

decision-‐making process and instead orients the team towards