Half Day Workshop given 5/22/2013 at WebVisions Portland.
In this workshop Bill will explore the mindset of LeanUX and how it relates to bring products to life in the midst of big organizations that don't normally think "Lean". He will look at how teams can create a strong partnership between product, design & engineering in a way that tears down the walls and instead focuses on three key principles:
Shared understanding
Deep collaboration
Continuous customer feedback
The workshop will take a look at how Bill has been able to apply Lean UX at PayPal — a place that in recent years has been the total antithesis of the lean startup idea. With very specific examples, he will share lessons learned applying lean to the full product life cycle as well as how it relates to agile development.
Finally, the workshop looks at the technology stack. In the last few years there has been an explosion of open source technology stacks that can support rapidly creating products, launching them to scale and rapidly iterating on them when live. While startups embrace these stacks from the get-go, large organizations struggle with how to embrace this change. This workshop will also look at the shift that has happened, what is driving this change, and how organizations can embrace this stack and how to marry Lean Tech with Lean UX.
Anupama Kundoo Cost Effective detailed ppt with plans and elevations with det...
Real World Lessons Using Lean UX (Workshop)
1. real world lessons
moving to leanux at paypal
bill scott (@billwscott)
sr. director, user interface engineering, paypal
webvisions workshop
may 22, 2012
2. the schedule
2:00-2:30 the problem (30)
2:30-3:00 the pattern (30)
3:00-3:15 q & a (15)
3:15-3:30 break (15)
3:30-3:45 the solution (15)
3:45-5:15 the lessons learned (90)
5:15-5:30 wrap up + q & a (15)
3. the purpose
help you identify the common problems encountered
put before you a clear pattern of how it should work
talk specific ways we solved our problems
leave you with a number of lessons learned you can
apply
7. design
UED, UX, ID, IA, VizDe,
Content, designer
not responsible for
engineering the experience,
but designing the
experience.
typically consumes PRD and
produces design specs.
8. engineering
front-end engineer, user
interface engineer, web
developer.
not the designer, but the
engineer that creates the
experience.
typically consumes UI specs
and PRDs (for context).
9. typical product life cycle
product
(business)
design
engineering
(agile team)
PRD UX spec
(wall) (wall)
customer
delivery
upon delivery, team disbands and forms into new teams
11. deep silos
iteration planning done by developers without
designer’s involved
designers hand off specs without prior involvement of
developers
developer days (“dev days”) valued over design time
frequent WFH days created low energy and less
collaboration time
hyper-segmentation of products
12. broad team distribution
geographic distribution created wedges, duplications
and blocked collaboration
lack of alignment with UED partners (not uncommon
to have designers & engineers in same region to be
working on different products)
13. lack of agile understanding
while UED interfaced with agile teams they did not
participate directly in agile planning, retrospectives,
etc.
agile machinery also did not account for experience
design
14. no sense of ownership
UED staff in a pooled/studio model instead of a
dedicated model
once delivery happened the designers moved to
another project
often engineers did not know who the designer was
for a product to ask questions to
teams not empowered to make decisions as a
gauntlet of other teams had to approve to go live
16. no measurement/learn culture
in several products there were no key performance
indicators to measure & learn against
since a/b testing was hard to do, there was no
concept of an MVP (minimal viable product)
17. feature-itus
since the organization rallied around projects instead
of products, product tended to try to put as much on
the train as possible
without kpis you guess more and more (F.O.G.)
without measurement you never get rid of features
18. too many silos
product was divided over 9 different organizations!
mobile was also a separate business, product and
engineering silo
20. too many silos
just like our counterparts, we were broken into many
different organizations
mobile was a separate organization
21. too hard to go live
37 tickets just to get a bug fixed and pushed to live
every organization was set up to say “no” to anything
that might be innovative for fear of failure, risk,
security issues, etc.
22. technology broken
no modern services architecture
all solutions were built as silos
ui logic and business logic intertwined
technology platform assumed developers were not to
be trusted
23. agile way too granular
one product had 20+ agile streams. 12 of these were
experience streams. each stream was responsible for
one small part of the experience
created nightmares of integration
created a fractured experience for users
24. paypal circa 2011
roll your own.
disconnected delivery
experience. culture of
long shelf life. inward
focus. risk averse.
26. a good pattern
continuous customer
feedback (get out of the
building - GOOB)
customer metrics drive
everything
think it. build it. ship it. tweak it
fail fast. learn fast.
lots of experimentation...
build/measure/learn
27. four
different PS3
experiences
launched
on same day
launching the ps3
experience
16 different test cells
2 different tech blogs were
simultaneously reviewing different
experiences
focus was on build/measure/learn
29. you have to engineer
for volatility
change is the norm
the ui layer is the experimentation layer
experimentation is not a one time event
launching a product is giving birth to the
product. the product’s life just begins.
design for throwaway-ability
majority of the
experience code
written is thrown
away in a year
30. lean startup
founded on build/measure/learn
get out of the building (GOOB)
invalidate your risky
assumptions
go for the minimal viable
product (MVP)
fail fast, learn fast
get to the pivot
31. lean ux
designing products for build/
measure/learn (lean startup)
requires 3 rules to be followed at
all times
get to & maintain a shared
understanding
form deep collaboration
across disciplines
keep continuous customer
feedback flowing
32. engineering focused
on learning
engineering the build/measure/learn
cycle
shift the focus to minimal viable
everything (MV*)
follows the key rules of lean ux:
shared understanding
deep collaboration
continuous customer feedback
LEANENGINEERING
ApplyingLeanStartup
Principlesto
BringDesigntoLife
34. deep
collaboration
strong belief that ideas come
from many different voices
trust is essential
all efforts never stray far from
collaborative efforts
36. getting to mvp
mvp is a key tenant of lean
startup
applied to engineering we
should think: minimal viable
everything. mv*
minimal viable process
minimal viable team size
minimal viable technology
minimal viable tools
what are startups using?
37. getting to mvp
mvp is a key tenant of lean
startup
applied to engineering we
should think: minimal viable
everything. mv*
minimal viable process
minimal viable team size
minimal viable technology
minimal viable tools
what are startups using?
zuck’s rule: how will the startup down the
street do this tomorrow? do it like that today.
38. healthy product life cycle
Discover
Customer
Insights
Define
Customer
Problems
Define
Solution
Concepts
Deliver &
Test
Solutions
CDI
45. free to iterate independent of agile
user interface engineering - agile scrum team
lean ux - lean team track
engineering - agile scrum teamsprint 0
usability usability usability usability usabili
release release release release
{agile
lean ux can provide a brain for agile
47. create a sandbox
IMVU allows every engineer
to put a test out to 1% of
users
at netflix we often created
additional tests that
designers or engineers
independently wanted to try
as a solution to a hypothesis
1
48. hotwire case study
how do you protect the parent organization from the
internal startup? create a sandbox
Source: “Lean Startup in the Hotwire Enterprise” by Kristen Mirenda & Karl Shultz
49. hotwire case study: feedback
“hate it - can't even
sort anymore”
“I don't like it because you
cannot filter the results or
even sort them.. What
were you thinking?”
“absolutely blows...pure
garbage. need to be able to sort
asap. i'll come work for you and
help you figure it out. wtf.”
Source: “Lean Startup in the Hotwire Enterprise” by Kristen Mirenda & Karl Shultz
50. hotwire case study: dataSource: “Lean Startup in the Hotwire Enterprise” by Kristen Mirenda & Karl Shultz
51. move to a
“living spec”
break down barriers
between prototyping and
production
use developers for
prototyping as forcing
function
embrace RITE
avoid tools/process that get
away from collaboration
2
52. make the spec real
there are many, many prototyping tools available now
you can create a living
spec with these
however the fidelity
is never the same as
real code
recommend HTML
prototyping
(more on this later)
53. but what about docs?
watch out for “predictive documentation”
watch out for documentation that replaces
collaboration or is a band-aid for bad process
good documentation will enhance collaboration,
shared understanding and disseminate learnings
54. use a prototype stack
whiteboard
to code code to usability
product/design
team
user interface
engineers
usability/customers
to enable learning
55. use a prototype stack
whiteboard
to code code to usability
product/design
team
user interface
engineers
usability/customers
to enable learning
nodejs
JS libraries
JS Templating
(dustjs)
less -> CSS images
56. enables sketch to code
forcing function
it brings about a close collaboration between engineering
and design
it creates a bridge for shared understanding
requires a lot of confidence and transparency
57. how lean & agile can play together
fuller integration with services, unhappy paths & hardening error handling
prototyping happens in rapid succession (lean ux track)
services agile scrum teams
usability usability usability usability usabili
release release release release
{agile
lean ux can provide a brain for agile
stories & code shared
lean & agile teams should blend together
58. code prototypes vs tools?
use the right tool at the right time
as you get closer to agile
axure, proto.io, POP and a host of other prototyping
tools are amazing -- especially early in the learning
cycle
code prototypes
important once you get close into the actual agile sprints
provide high fidelity to the user testing
faster cycle from “learning to live”
59. suggestions for code prototyping
bootstrap is one of the quickest to get going with
we use it on our production stack as well
jetstrap allows you to drag and drop a bootstrap
page to get a quick start
nodejs is really powerful for prototyping your full
application (web, tablet, desktop)
60. prototyping tools
see:
list of prototyping tools on my blog: http://bit.ly/SfWygk
few that we also use:
Axure RP
InVision
POP
61. engineer for
experimentation
long shelf life to rapid
experimentation
focus on learning not on
delivery
design for volatility
refactor the tech stack with
learning in mind
3
62. experiences must learn
All buildings are predictions.
All predictions are wrong.
There's no escape from this grim
syllogism, but it can be softened.
Stewart Brand
Our software is always
tearing itself apart (or
should be)
Recognize that
different layers change
at different velocities
63. velocity changes by layer
recognize that different parts of tech stack change at
different velocities
“any building is actually a hierarchy of pieces, each of
which inherently changes at different rates” - Stewart
Brand. How Buildings Learn.
design for throwaway-ability (volatility)!
“use before you reuse” (optimize for change)
utilize packaging or paths to capture experiments
64. why start with experience?
stay honest & pure by having experience be the driver
(not what your boss thinks or what looks good on
your resume or what the loudest one in the room
thinks)
remember
use before you reuse
let the experience drive the engineering
reuse is an engineering optimization. use is what users
do. reuse is what engineers do.
69. build in rapid experimentation
think of the UI layer as “the experimentation layer”
early rapid prototyping leads to learnings to get into
the right ballpark
follow with live A/B Testing. Lots of it.
creates a healthy environment with constant customer
feedback loops
contrast this with “long shelf life”
culture
70. requirements for lean Stack
independent of the backend language
flexible enough to run in either the server or in the client
equally good at building web sites as it is building web applications
pushable outside of the application stack (publish model)
cleanly separated from the backend/app code (ideally by JSON)
utilize what is common to developers
quick & easy to build & tear down components
71. tangled up
technology
big problem. technology and
processes not geared to build/
test/learn.
refactor your way out of
technical and experience debt
72. technical debt
we have to be on modern tech
stack to continuously innovate
we have to be on a continuously
available stack
continuously integrating
continuously deploying
73. stack circa 2011/early 2012
simple change could
take minutes to see
follows an “enterprise
application” model. ui
gets built into the “app”java
jsp***
restricted
capabilities*
prototyping
was hard
“ui bits”
could only
live here
* assumed client developers were low-skill
* required server side java eng for simple client changes
** java server pages. server-side java templating solution
server side
components**
client
server
74. a tale of two stacks (c++ & java)
two non-standard stacks
new stack tied to Java
“one word” change could
take 6 weeks to fix on c++
stack
c++ java
xml jsp
proprietary
ui
proprietary
ui
old new’ish
long
release
cycles
75. decision was to move to java
migration was already in
place to leave the c++/
xml stack behind
some odd choices
preceded this: write
everything in java (html,
css & js!!)
c++ java
xml jsp
proprietary
ui
proprietary
ui
Xold new’ish
76. old stack not designed for learning
this new stack was not
conducive to prototyping
followed an “enterprise
application” model. ui
gets built into the “app”
ajax/components all done
server-side (subclass java
controller)
java
jsp
proprietary
ui
prototyping
was hard
“ui bits”
could only
live here
77. separate the ui bits
code = JS
(backbone)
templates = JS
{dust}
style = CSS
(less)
images
re-engineered the user
interface stack so that
the only artifacts are:
• javascript
• css
• images
ditched the server-side
mentality to creating UIs
• no more server-side only
templates
• no more server-side
components
• no more server-side
managing the ui
78. use javascript templating
templates get converted
to javascript
<p>Hello {name}</p>
we use dust.js
code = JS
(backbone)
templates = JS
{dust}
style = CSS
(less)
images
JavaScript
compiles to...
javascript
executed
to generate ui
79. ui bits now just natural web artifacts
server-side language independent
server/client agnostic
CDN ready
cacheable
rapid to create
code = JS
(backbone)
templates = JS
{dust}
style = CSS
(less)
images
80. portable in all directions
JS templating can be run
in client browser or server
on the production stack
we can drag & drop the
ui bits from prototyping
stack to the production
stack
java
(rhinoscript)
node.js
{dust}
JS template
prototype
stack
production
stack
{dust}
JS template
client OR
server
either stack
81. embrace open
source fully
stop rolling your own
solutions
democratize software
development
build software that can be
shared (keeps architecture
clean)
4
83. work in open source model
internal github revolutionized
our internal development
rapidly replaced centralized
platform teams
innovation democratized
every developer encouraged
to experiment and generate repos
to share as well as to fork/pull request
84. give back to open source
we have a projects that we will open source
node bootstrap (similar to yeoman)
we are contributing back to open source
contributions to bootstrap (for accessibility)
contributions to bootstrap (for internationalization)
core committer on dustjs project
85. using github for continuous *
use github for continuous integration
starting to use github repo model for continuous
deployment
marketing pages
product pages
content updates & triggers into i18n, l10n, adaptation
components
86. give agile a brain
use lean ux as the brain for
agile
develop a lean cadence
involve all members in lean
ux (balanced teams)
5
88. sprint faster
focus on getting to customer as early and as often as
possible
removes the politics in the team as this becomes the
arbiter
you can slow down this cadence after you converge
on key hypotheses and potential solutions
90. spotify: squad
similar to scrum team. feels
like startup
long term mission: build &
improve the product. stay
long term on the product.
apply lean startup principles
like MVP
“think it, build it, ship it,
tweak it”
emphasis on great
workspace
93. become
hypothesis driven
learn to state design goals in
terms of solving specific
customer problems
don’t be afraid to invalidate
hypotheses
look for the pivot
6
94. embrace the
problem not the
solution
engineering: don’t start with
technology, start with
experience
design: get your ideas out
early
together: get in front of
customers so problem is the
focus, not our current
solution
7
95. co-locate if at
all possible
high bandwidth “meatspace”
facilitates shared
understanding and deep
collaboration
also facilitates shared time
with the customer
8
96. suggestions
at a minimum teams should come together for the
first few weeks to build shared understanding, deep
collaboration and getting feedback from customers
for distributed members use high bandwidth
communication where possible (skype, tele-presence)
high bandwidth
communication
necessary.
97. github counterpoint
electronic: discussion, planning and operations
process should be in high fidelity electronics.
available: work should be visible and expose process.
work should have a URL. single source truth.
asynchronous: almost nothing should require direct
interruption.
lock-free: avoid synchronization points.
cooperation without coordination
http://tomayko.com/writings/adopt-an-open-source-process-constraints
102. deep
collaboration
strong belief that ideas come
from many different voices
trust is essential
all efforts never stray far from
collaborative efforts
104. getting to mvp
mvp is a key tenant of lean
startup
applied to engineering we
should think: minimal viable
everything. mv*
minimal viable process
minimal viable team size
minimal viable technology
minimal viable tools
what are startups using?
105. getting to mvp
mvp is a key tenant of lean
startup
applied to engineering we
should think: minimal viable
everything. mv*
minimal viable process
minimal viable team size
minimal viable technology
minimal viable tools
what are startups using?
zuck’s rule: how will the startup down the
street do this tomorrow? do it like that today.