What is Lean UX?

Applying Lean Principles to Improve
User Experience in Agile Environment
Darren F. Gideon
Principal Web Developer UI
Citrix Web Services

It’s focus is strictly on the design phase of software
development process. Best practice is to use
staggered sprints also known as Cycle 0 and Sprint
Zero.
Design activity takes place one sprint ahead of
development.

It is a methodology inspired by “Lean Startup” and
“Agile” for bringing UX designs to light faster with less
emphasis on deliverables and with greater focus on
the actual experiences being designed.

It accomplishes this by getting out of the deliverables
business and instead focusing on successful
experiences. It focuses more on creating successful
experiences by:
1. Removing waste from design process
2. Harmonizing the interaction of designers, developers, product manager, QA,
etc. into a transparent cross functional collaboration of all involved parties.
3. Relying on rapid experimentation and measurement to quickly learn how well or
not ideas are meeting the users goals. The designer’s role is one of design
facilitation instead of sole point of view.

• Not being judged by the depth and breadth of delivered
documents (delivery of pixel perfect hi-defs and extensive
documentation before presenting to collaborative team,
customer, and or users).
• Being judged by the success of the end-state experience
for the user.

It focuses on ensuring the ideas that have the most
value get the most resources via:
1. Experimentation
2. Rapid Iteration
3. Evolutionary Process

Hi, HR its Darth Vader
here. I need some
personnel for
a planetary operation.

No problem Darth Vader.
Will this candidate do? He
says he knows Photoshop.

No, I don’t need a
designer. I need canon
fodder for a ground
assault.

Oh, he knows COBOL too.
What if we can outfit him
with Storm Trooper
equipment? Would he fulfill
what you need then?

He knows COBOL? He
definitely will be good
canon fodder then.
But I don’t need a Storm
Trooper. The assault is on
the ice planet Hoth.

Oh, so you need him
outfitted with cold weather
gear. How about him now
as a Snow Trooper?

Perfect!
Get him outfitted with full
Snow Trooper armor,
weapons, and cold weather
gear.
Then put him on the next
transport to Hoth.
Oh, make sure he signs
the proper
“RELEASE”
forms before he
goes.

1. Darth Vader makes a request to fulfill an outcome
2. A “minimum viable product” (MVP) is presented to be
critiqued.
3. The MVP is critiqued and sent back, starting the next
iteration.
4. The MVP is adjusted just enough to prove the concept and
then presented again for critique.
5. Additional rapid iterations happen where the MVP is evolved
until it meets the desired outcome.
6. The MVP is then prototyped and goes through the iteration
process again until approved. It is then sent to Hoth to be
validated in battle.

Because the biggest lie in software development is “Phase II.”
A successful experience is a feature that actually ships that
meets the customer and business goal(s). Delivering an
experience that doesn’t do this with a promise of finishing the
experience in Phase II is delivering a bad / incomplete experience
to the end user that might never be rectified.
So why does this happen?
Usually because a team ran out of time and then there never was
a phase II. Or the customer goals change in phase II leaving a
bad / incomplete end-state experience in place.

LEAN UX is based on three processes that are used to
reduce waste and achieve a better end-state experience
faster:
1. Design thinking
2. Agile development
3. Feedback loop that where a team works collaboratively
to iterate repeatedly through a path to achieve a
desired outcome

Design thinking starts with the goal or what is desired
to be achieved by the user instead of starting with a
certain problem. Direct observation of what “users”
want to accomplish and what they like and dislike
leads to innovation and the achievement of a
successful outcome.

1. Emphasis on individuals and interactions over
processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over rigidly following a plan.
5. The realization that the initial design will have something
wrong in it. So the goal should be find out what
is wrong as soon as possible, then adjust, and test again.

A feedback loop is the process where you create the
minimum viable product (MVP) to quickly test your
assumptions, adjust the MVP based on feedback,
and test again.
Getting your collaborative team and then customer
feedback avoids you making incorrect market
assumptions.
Your design is a hypothesis and your goal is to
validate the solution by team and customer feedback.

By providing insight into the design work to your
teammates sooner rather than later you accomplish
the following:
1. It ensure that you’re aligned with the broader team and the business
vision
2. Give developers a sneak peek at the direction of the application
enabling them to spot challenges earlier and speed up development
3. Fleshes out your thinking, since displaying your concepts to others
forces you to focus on areas that you didn’t initially think of
or deemed important

1. Cross Functional teams
2. Progress equals outcomes not output
3. Problem focused not features implemented
4. Remove waste
5. GOOB, the new user centricity
6. Small batch size
7. Continuous discovery
8. Shared understanding
9. Externalizing your work
10. Don’t over analysis
11. Learning over growth
12. Get out of the deliverables business
13. Permission to fail

Teams made up of the various disciplines involved in
creating your product. Their involvement should be
continuous from the first day of the project until the
end.
The creation of a diverse team collapses the handoff
process known as waterfall. Allows insight and
foresight on each idea for all those involved. Which
fosters greater team efficiency.

Features and services are outputs.
The business goals they are meant to achieve our
outcomes. By managing and measuring against
outcomes we gain insight of whether the features we
are building meat those outcomes.
If a feature is not performing well we can objectively
decide as to if it should be kept, changed, or
replaced.

A problem focused team is one that has been
assigned a business problem to solve (or an outcome
to achieve) instead of a set of features to implement.
• It allows for innovation by the team
• It shows trust in the team to find a solution
• It fosters an investment by the team in the
outcome

A core tenant is the removal of anything that doesn’t
lead to the ultimate goal. Which is improved
outcomes. You do this because team resources are
limited.
The more waste a team can eliminate, the faster they
can move.

“Getting out of the Building” coined by Steven Blank.
Meeting room debates about user needs won’t be
settled in your office. The answers lie out in the
marketplace. So you should give potential users a
chance to provide feedback on your ideas as soon as
possible.
It is better to find out early if you are missing the mark
BEFORE you spent the time and resources to build a
product that nobody wants.
The success of failure of a product isn’t the team’s
decision but ultimately the end user.

Create only the design that is necessary to move the
team forward and avoid a big inventory of untested
and unimplemented ideas.
Large batch forces a team to wait for big deliverables.
It also keeps them from learning whether the ideas
are valid or not.

The ongoing process of engaging the customer
during the design and development process.
The goal is to understand what users are doing with
your products and why the are doing it. Research
must be frequent and the entire team should be
involved.
The involvement of the team will build empathy and
understanding for the users and the problems they
face.

It’s the collective knowledge a team builds up over
time as they work together. The more a team
collectively understands not only what it is doing but
why, the less it has to depend on second hand
reports and detail documents to continue it work.

Getting your ides out of your head and into public
view allows everyone to see where the team stands.
This can be done by whiteboards, printouts, etc.
You do this to create a flow of information across the
team. Which helps to inspire ideas off of ones that
have already been shared. It also more quickly
exposes possible issues with ideas that then can be
interated on or discarded.

There is more value in creating a first version of an
idea than spending half a day debating its merits in a
conference room.
The most difficult questions will not be answered in a
conference room debate but by users in the field. To
get user input you need to make ideas concrete so
that they have something to respond to.

It’s difficult to figure out the right thing to build and
scale a business around it at the same time.
Scaling an idea that is unproven is risky. It might work
and it might not. If it doesn’t work and you scaled it to
your entire user base you have wasted valuable time
and resources.
Ensuring the idea is right on a smaller scale mitigates
this risk (e.g. Canary releases, beta groups, etc.)

The focus of the design process should be creating
the successful outcomes not documents.
Documents don’t solve customer problems – good
products do. The team’s focus should be on learning
which features have the biggest impact on their
customers. The artifacts the team uses to gain that
knowledge is irrelevant.

In order to find the best solutions to problems the
team needs to experiment with ideas. Most of these
ideas will fail.
The team must be safe to fail if they are to be
successful. So permission to fail means a team has a
safe environment to experiment in which creates a
culture of experimentation and creativity.
Derek Silvers (CD Baby Founder) has a video called
“Why you need to fail” which goes into this.
http://www.youtube.com/water?v=HhxcFGuKOys

Here we have our COBOL developer. One of his
hobbies is to race cars, the Mach 5 in this
instance.

He is racing on course new to him and he
is taking this corner at speed for the first time. He
likes to use a “heel-and-toe shifing” method but
will it be to fast for this corner?

Oh no COBOL Racer!
Your going to fast … hai!

He learned just how fast he can take this corner on
this race track? If he didn’t fail he would never know
how close he can push things to the edge without
failing.

Traditional UX design projects are framed by
requirements and deliverables. LEAN UX goal is not
about create a deliverable but to create an outcome
by starting with assumptions instead of requirements.
The main tool for this is the Hypothesis statement
which is made up of these elements:
• Assumptions
• Hypotheses
• Outcomes
• Personas
• Features

A high level declaration of what we believe to be true.
It’s a the starting point and the team should be
involved so everyone is on same page.

More detailed description of our assumptions that
target specific areas of our product / workflow for
experimentation. Breaking down your assumptions
into hypotheses allows you to test these
assumptions.
• We believe this statement is true
• We will know we’re right/wrong by the following
feedback from users
• [qualitative feedback] and/or [quantitative
feedback] and/or [key performance indicator
change].

What we seek from the market / users to help us
validate or invalidate our hypotheses. These need to
be specific to be useful.

Models of the people for whom we believe we are
solving a problem.

The product changes or improvements we believe will
obtain the outcomes we seek.
Once you have a list of outcomes you want to
achieve then you can start thinking about tactics,
features, products, and services you can put in place
to achieve those desired outcomes.

1. Shifting from output to outcomes
2. Move from limited roles to collaborative capabilities
3. Embracing new skills
4. Create cross-functional teams
5. Create small teams
6. Create co-located collaborative workspaces
7. Eliminate “Big Design Up Front”
8. Speed first, aesthetics second
9. Valuing problem solving
10. Embracing UX debt
11. After LEAN UX transition back to company document standards
12. Be realistic about your environment

Teams must shift conversation with leadership from one
based on features to one centered on achieving outcomes.

Discouraging cross-functional input encourage
organizational silos which is the death of collaboration.
Need to adopt mantra of “competencies over roles. Every
team member has multiple competencies and skills. Both
primary and secondary.

While teams still need core UX and design skills you also
need to add facilitation as a core competency.
Designers must open up the design process. The team not
the individual most own the product design.
Designers must take a leadership role in the team where
they provide leadership and facilitation in a group
brainstorming activities.

Collaboration for many teams is a single discipline activity;
developers solving problems with other developers, etc.
Involving everybody in process facilitates communication.
Allows for a broader range of insights and creates a
greater cohesion of all members working toward the same
goal.

Large groups are less efficient than smaller groups.
Smaller teams also forces members to work on smaller
problems and be more focused.
Jeff Bezos calls these “two-pizza teams.” If the team
needs more than two pizzas for a meal, it’s to big.

Co-locate teams to the same workspace which makes
everybody more visible and accessible. Face to face
conversation is more effective than anything else for
showing some work, discussing, sketching, and
exchanging ideas, understanding body language and facial
expressions (sub-text), when trying to reach a resolution
on something.

Instead of documenting and presenting a complete product
from end to end MVPs (minimum viable products) allow for
ideas to be seen much sooner than before. It gives a
glimpse into actual product experience and allows for a
quicker iteration of designs to be more usable and
feasible.

Jason Fried, CEO of 37Signals once said “speed first,
aesthetics second.”
He is not talking about compromising quality.
It is creating about creating the MVP (minimum viable
product) to demonstrate something to start the whole
evolutionary cycle of iterations. Your first design will not be
perfect, what you want is it to be useable enough to start
to start the process.
Get it done, get it out there, discuss, modify based on
discussion, and iterate.

Companies value problem solving over aesthetics. The
ability to illustrate the path you take to get from an idea to
validated learning to end experience is what is valuable.

It’s often the case in agile environment that you do not go
back to improve the user experience.
“It’s not iterative if you only do it once.”
To improve the team needs to do more than refactor code
and address technical debt. The team also has to commit
to evaluating, reworking, and improving the user interface
and experience based on user feedback and testing.
UX debt is the commitment to continuous improvement of
the user experience.

Yes, many organizations have strict documentation
standards. However, as hypotheses are proven and design
directions are solidify then transition back to
documentation required by company. Otherwise it is waste
to document something that you might discard after
testing.

Change can be disconcerting for many individuals who are
used to do things in a certain way. So in many cases it is
best to ask forgiveness instead of permission.
Proving that you saved time and money or create a more
successful outcome will better make your case than asking
permission and explaining why you think it will produce
better results.

What is Lean UX?

More Related Content

What's hot

Viewers also liked

Similar to What is Lean UX?

Recently uploaded

What is Lean UX?