Real World Lessons Using Lean UX (Workshop)
•
52 likes•39,156 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Real World Lessons Using Lean UX (Workshop)
Similar to Real World Lessons Using Lean UX (Workshop) (20)
More from Bill Scott
More from Bill Scott (19)
Recently uploaded
Recently uploaded (20)
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
- 4. the problem a look at where paypal has been. can you relate?
- 5. team breakdown standard process creates distinct work phases boundaries are the hand-off points between roles product (business) design engineering
- 6. product product manager, business analyst owns the features. doesn’t do design. drives by hypothesis. typically produces PRD
- 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
- 10. what was broken in design? late 2011/early 2012
- 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
- 15. what was broken in product? late 2011/early 2012
- 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
- 19. what was broken in engineering? late 2011/early 2012
- 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.
- 25. the pattern following a build/measure/learn mindset
- 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
- 28. the epiphany design for volatility
- 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
- 33. shared understanding the more understanding the less documentation but this doesn’t mean NO documentation you need whatever is needed to gain a shared understanding
- 34. deep collaboration strong belief that ideas come from many different voices trust is essential all efforts never stray far from collaborative efforts
- 35. continuous customer feedback this is the lifeblood of the team gets rid of politics turns a team outside-in
- 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
- 39. the solution refactoring your way to the pattern
- 40. paypal vs netflix
- 41. new dna @paypal jan 2012 fleshed out ui layer that could support rapid experimentation march 2012 david Marcus becomes president of PayPal
- 42. in the midst of transformation
- 43. hermes project re-inventing checkout with lean ux
- 44. hermes project whiteboard to code code to usability product/design/engineering teams usability/ customers lean ux in action
- 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
- 46. the lessons learned what you can apply to your teams
- 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
- 82. use open source religiously
- 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
- 87. free to test frequently with users
- 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
- 89. example: spotify squads run like lean startups
- 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
- 91. spotify: tribes collection of squads that work in a related area incubators for tribes hold regular gatherings
- 92. spotify: chapters and guilds chapters represent horizontal practices within a tribe guilds represent horizontal practices across tribes
- 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
- 98. tools that can help
- 99. team working agreement decide who is the decision maker define your cadence define how you will work together define your hypotheses
- 100. team working agreement decide who is the decision maker define your cadence define how you will work together define your hypotheses
- 101. shared understanding the more understanding the less documentation but this doesn’t mean NO documentation you need whatever is needed to gain a shared understanding
- 102. deep collaboration strong belief that ideas come from many different voices trust is essential all efforts never stray far from collaborative efforts
- 103. continuous customer feedback this is the lifeblood of the team gets rid of politics turns a team outside-in
- 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.