The Emperor's New Lean UX: Why I'm not using lean UX, and perhaps why you shouldn't either

12/14/2015
Copyright 2015 UX Design Edge. All rights
reserved. 1
Copyright 2015 UX Design Edge. All rights reserved.
The Emperor’s New Lean UX
Why I’m not using lean UX and
perhaps you shouldn’t either
Everett McKay
UX Design Edge
uxdesignedge.com
@uxdesignedge
UX Speakeasy VT, December 2015
Who is this guy?
 Principal of UX Design Edge (from Vermont, USA)
 Offer UI design classes, workshops, and consulting
services, primarily to software teams that don’t have
(sufficient) design talent and resources
 Previously was a Windows PM at Microsoft, where I
owned Windows Server security UI and wrote the
Windows UX Guidelines (but not for Windows 8)
 Before that, was a developer of Windows and Mac UIs
 As a UX consultant, I have experienced lean UX
vicariously
 Have taken Jeff Gothelf’s Lean UX Workshop
Today’s agenda
 Major lean principles
 Secondary lean principles
 My lean alternative
 Group discussion
Ground rules
 I want to get through the material quickly, so let’s save
most discussions for the Group discussion section
Sup?
Introduction

12/14/2015
reserved. 2
A quick survey
5 minutes  Are you using lean UX now (or plan to)?
 If yes, how is it working?
 If not, why not?
 Can anyone claim that lean UX leads to
better product design (based on shipping
better products!)
Why this subject?
 Lean UX is a hot topic now
 Several of my customers are adapting or considering
 I believe the foundation of lean is weak, but nobody is
challenging it
 I see many promises, but not results
The goal of lean UX is great
 The goal: Build the right product, avoid wasting time
 Who doesn’t want that?
 But often methodologies boil down to practices and
steps—the goals behind them tend to get lost!
Everett’s Law of Processes
 Any process can and will be misused…once
practitioners lose sight of the goals behind the process
 Over time, rituals and dogma take over
 That’s not really agile!
 But that’s what you are supposed to do!
Lean UX in a nutshell
 In theory
 More efficient, collaborative, user/evidence-driven design
 Build -> Measure -> Learn, using an MVP as a test vehicle
 Objective: Avoid shipping big product that nobody wants
 In practice
 Used to justify weak design process
 Code -> pretend to measure -> code some more
What successful lean UX looks like
 Start a project
 Determine significant hypotheses
 Validate them immediately (without production code)
 Significantly change direction as a result
That is as good as it gets

12/14/2015
reserved. 3
Groupthink
 People are embarrassed to admit if they aren’t using
 People are embarrassed if it doesn’t work
 If it doesn’t work, you aren’t doing it right!
 Nobody is questioning agile or lean
 UX South Africa informal survey, Dr. Eric Schaffer
Program from an upcoming UX conference
 Keynote: Great UX in an agile world
 Session 1: Making agile UX work
 Session 2: Making agile UX work in the real world
 Session 3: Agile and lean UX
 Session 4: Making agile and lean UX work in the real
world
Session 5: WTF—why isn’t this working?
 Session 6: Trust us, it’s still better than waterfall
Why we must question lean
 If lean (and agile) work so well, where are the results?
Imagine a lean UX restaurant
 No “heroes” (expert chef or skilled cooks), no clear roles
 Decisions are made in collaborative, closely working teams
 All meals are a hypothesis with evidence-based learning
 No cookbooks or recipes
 Cook -> eat -> learn
 No written “deliverables”, whiteboard notes and
conversations instead
 Q: What would you expect the results to be?
The foundation of lean UX
Major lean principles
Get out of the deliverables business
 Top goal is to reduce waste
 Traditional deliverables such as UI specs are
considered waste
 Who wants to write (or read) a 200 page UI spec?
 Lean UX teams don’t write any specs, terrified of
sinning
 It’s all on whiteboards, so it’s OK!

12/14/2015
reserved. 4
But…
 Q: What would you do if you needed to have your
team deliver a well-designed product or feature as
quickly as possible?
 I would write a spec!!! Learn a tremendous amount quickly!
 Lean assumes specs are mostly about paper and typing
 Good specs are about making design decisions and
communicating them efficiently
 Only poorly written, unnecessary deliverables are
wasteful—the others exist for a reason!
The prototype as the design doc
 Using a prototype to document the design is a lean
recommendation
 This is the worst way to prototype
Discrepancies…
 In lean, “learning” (and therefore failure) is supposed
to be good
 But apparently only if do through group activities,
code, MVP…
 Traditional design tools are considered pure waste
All designs are a hypothesis
 For evidence-based design, you need to validate your
designs through some kind of test
 Build -> Measure -> Learn
 Designs are not based on expertise of designers, but
the output of a evidence-based collaborative process
But…
 This simply isn’t true…assumes we know nothing about good
design or our customers
 Need a much higher bar on things to test—we don’t have to
learn everything
 UX design is hard, evidence-based user research is much, much,
much harder
 Creating meaningful tests and metrics, creating something to
test, performing the test, analyzing the results, drawing the
correct conclusions, making the right changes—is extremely
difficult for people without a UX background
 More likely to be mislead as to be informed
Discrepancies…
 Lean UX is just rediscovering the need for user
research and user testing
 Except lean teams lack the expertise to do well

12/14/2015
reserved. 5
A/B Testing
 A favorite evaluation technique for lean UX
 Normally, A/B tests are scientifically valid tests
performed on a very large sample to measure
conversion
 For lean, A/B tests are performed on a small sample to
measure usability and preference
But…
 Evidence-based != flawed test with arbitrary metrics
 If you don’t know how to do scientifically valid
experiments or set meaningful metrics and you do the
test anyway, what do the results mean?
 …but it’s science!!
Discrepancies
 Validating everything wastes a lot of time, but our goal
was to avoid waste
 Skeptical that lean UX teams actually learn anything
 Key: Do lean teams throw away working code?
 Do lean teams really abandon designs if the test results
don’t support them?
 In practice: lean teams either don’t do the hypothesis
testing, or make the minimal chances to code to
address problems (never starting over)
Minimal viable products
 A minimal viable product (MVP) has sufficient features
to satisfy early adaptors (Eric Ries)
But…
 For most teams, lean boils down to creating the MVP
 They don’t actually test anything to validate hypotheses
 And for most teams, that MVP consists of working
code (not wireframes, demos, etc.)
 But what exactly is an MVP, and how do you prevent
it from being crap (Minimal Vcrappy Product)?

12/14/2015
reserved. 6
From Gothelf’s Lean UX
 MVPs are used to validate assumptions to minimize
waste
 The smallest thing to validate each hypothesis to
decide to proceed
 -or- the simplest product that delivers value to the
market
 Could be a sketch, wireframe, prototype, demo,
preview—or—a working product
 Design only what you need, deliver it quickly, and get
meaningful feedback fast
From Klein’s UX for Lean Startups
 An MVP is minimal, viable, and a product…that isn’t
crappy
 What is crappy?
 A crappy product often tries to do too many things at once,
and it doesn’t do any of those things particularly well
 Excuse me, but WTF?
 Recommends a fake landing page as an MVP!
Nobody knows what an MVP is!!
 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 I challenge you to apply either book to determine if
something is an MVP (vs. a non-MVP prototype, etc.)
 And determine if it is an effective MVP
 Is Zombo.com a good MVP?
Nobody knows how to evaluate an MVP
 Great design doesn’t sell itself
 Examples from popular culture: books, actors,
musicians
 Best tech example: What was the MVP for the iPad?
“It's not the
customer’s job to
know what they
want.”
Steve Jobs

12/14/2015
reserved. 7
A visualization
© Projectcartoon.com, http://projectcartoon.com/cartoon/516243
No UX heroes or rockstars
 Instead, all roles must collaborate, and beautiful
mockups are downplayed
 Shouldn’t have one authority bottleneck
But…
 UX design is much easier if someone on the team
actually knows what they are doing
 Way to easy to misinterpret as: no ux design talent or
having those dreaded unicorns
 Instead should be: no design bottlenecks
Lean and agile go together well
 Radical claim: Lean and agile are a lousy combination
 Why?
 Effective lean: avoid writing code until hypotheses proven
 Agile manifesto: Working code is the ultimate measure of
progress
 Gothelf’s MVP revision (purely an assumption)
 Lean + agile = working code MVP -> not really agile or lean
 Let’s just get something out there!
 Translation: Let’s just get the code to work—and worry about the
UX later
My two insights to successful lean UX
 Everybody: Build -> Measure -> Learn
 Joshua Kerievsky: Learn -> Measure -> Build
 This is the right order!!
 Insight 1: Critical learning -> meaningful metrics ->
MNPCE*
 *Minimal non-production-code experiment
 Insight 2: Critical learning is almost always a question
of delivering value
 This makes total sense to me!
x
 x

12/14/2015
reserved. 8
Still more promises…
Secondary concepts
Shared understanding
 Gothelf: Shared understanding is the currency of lean
UX
 My Lean UX workshop experience
 My conclusion: this is only an aspiration
Collaborative, cross-functional teams
 Constantly hear (in theory): Need to break down the
silos!
 Constantly hear (in practice): More stakeholders makes
things worse rather than better
 Small core teams work best, involving everybody is
overrated, leads to design by committee
Working with many stakeholders
“…a horse designed
by committee”
Sir Alec Issigonis
Brainstorming vs. crazy eights, 10+10
 …also called Design Studio
 To brainstorm, Gothelf recommends individuals come
up with 8 sketches in 10 minutes (so, 1.25 minutes per)
 I love brainstorming, but
 Visual brainstorming limits thinking
 Arbitrarily small time limit focuses on trivial/obvious ideas

12/14/2015
reserved. 9
Get out of the building (GOOB)
 Steve Blank: There are no facts inside the building
 Me: Bullshit!
 Problem: Talking to users is extremely difficult to do
well
 If you don’t know how to do it, likely to be mislead
Topics conspicuously missing from Lean UX
 Traditional user research
 Leveraging existing knowledge through design
principles, guidelines, and patterns
What to do instead…
My lean alternative
My problem with lean UX
 The root cause of our biggest UX design problems:
using code-driven, feature-based, requirements-based
design
 Both agile and lean attempt to solve this problem—
with code-driven, feature-based, requirements-based
design!
 See the problem?
Things to not do
 Avoid fads or trends
 Don’t adapt your project to a process—should be the
other way around
 If something doesn’t work, fix it or stop it
 Don’t assume that it’s your teams fault
 Don’t be dogmatic (write some specs!)
 Question everything before committing your project to it
 Don’t overdesign
 Ship small releases to stay on target
Things to do
 Be very clear on the process/design problems you are
trying to solve
 Don’t lose sight of the goal: the best product developed
with the least waste
 Use Learn -> Measure -> Experiment, only to determine if
you are delivering value
 Production code is the least lean way of making most
design decisions
 Train your team!! (knowledge and skill beats process)
 Communicate well: devs oppose what they don’t
understand

12/14/2015
reserved. 10
Key questions to ask
 Are you really shipping awesome user experiences that
meet users’ goals?
 Are you really minimizing waste?
 Does your team make important design decisions
quickly and confidently?
 Are you really validating hypotheses, and significantly
changing direction as a result?
If your answer to any of these questions is “no”, you’re
only pretending to be lean
So, what do you think?
Group discussion
Ground rules
 Any mention of waterfall is not allowed!
Group discussion
 So, what do you think?
Wrap up
Got feedback?
 Would love to hear it!
 Please send it to everettm@uxdesignedge.com
 Let’s connect on LinkedIn

12/14/2015
reserved. 11
Thank you!

The Emperor's New Lean UX: Why I'm not using lean UX, and perhaps why you shouldn't either

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to The Emperor's New Lean UX: Why I'm not using lean UX, and perhaps why you shouldn't either

Similar to The Emperor's New Lean UX: Why I'm not using lean UX, and perhaps why you shouldn't either (20)

Recently uploaded

Recently uploaded (20)

The Emperor's New Lean UX: Why I'm not using lean UX, and perhaps why you shouldn't either