Real World Lessons Using Lean UX (Workshop)

  • Published on
    15-Sep-2014

  • View
    10

  • Download
    2

DESCRIPTION

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.

Transcript

real world lessonsmoving to leanux at paypalbill scott (@billwscott)sr. director, user interface engineering, paypalwebvisions workshopmay 22, 2012the schedule2: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)the purposehelp you identify the common problems encounteredput before you a clear pattern of how it should worktalk specific ways we solved our problemsleave you with a number of lessons learned you can applythe problema look at where paypal has been. can you relate?team breakdownstandard process creates distinct work phasesboundaries are the hand-off points between rolesproduct(business) design engineeringproductproduct manager, business analystowns the features. doesnt do design. drives by hypothesis.typically produces PRDdesignUED, UX, ID, IA, VizDe, Content, designernot responsible for engineering the experience, but designing the experience. typically consumes PRD and produces design specs.engineeringfront-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).typical product life cycleproduct(business) designengineering(agile team)PRD UX spec(wall) (wall)customerdeliveryupon delivery, team disbands and forms into new teamswhat was broken in design?late 2011/early 2012deep silositeration planning done by developers without designers involveddesigners hand off specs without prior involvement of developersdeveloper days (dev days) valued over design timefrequent WFH days created low energy and less collaboration timehyper-segmentation of productsbroad team distributiongeographic distribution created wedges, duplications and blocked collaborationlack of alignment with UED partners (not uncommon to have designers & engineers in same region to be working on different products)lack of agile understandingwhile UED interfaced with agile teams they did not participate directly in agile planning, retrospectives, etc.agile machinery also did not account for experience designno sense of ownershipUED staff in a pooled/studio model instead of a dedicated modelonce delivery happened the designers moved to another projectoften engineers did not know who the designer was for a product to ask questions toteams not empowered to make decisions as a gauntlet of other teams had to approve to go livewhat was broken in product?late 2011/early 2012no measurement/learn culturein several products there were no key performance indicators to measure & learn againstsince a/b testing was hard to do, there was no concept of an MVP (minimal viable product)feature-itussince the organization rallied around projects instead of products, product tended to try to put as much on the train as possiblewithout kpis you guess more and more (F.O.G.)without measurement you never get rid of featurestoo many silosproduct was divided over 9 different organizations!mobile was also a separate business, product and engineering silowhat was broken in engineering?late 2011/early 2012too many silosjust like our counterparts, we were broken into many different organizationsmobile was a separate organizationtoo hard to go live37 tickets just to get a bug fixed and pushed to liveevery organization was set up to say no to anything that might be innovative for fear of failure, risk, security issues, etc.technology brokenno modern services architectureall solutions were built as silosui logic and business logic intertwinedtechnology platform assumed developers were not to be trustedagile way too granularone product had 20+ agile streams. 12 of these were experience streams. each stream was responsible for one small part of the experiencecreated nightmares of integrationcreated a fractured experience for userspaypal circa 2011roll your own. disconnected delivery experience. culture of long shelf life. inward focus. risk averse.the patternfollowing a build/measure/learn mindseta good pattern continuous customer feedback (get out of the building - GOOB)customer metrics drive everythingthink it. build it. ship it. tweak itfail fast. learn fast.lots of experimentation... build/measure/learnfourdifferent PS3 experiences launched on same daylaunching the ps3 experience16 different test cells2 different tech blogs were simultaneously reviewing different experiencesfocus was on build/measure/learnthe epiphanydesign for volatilityyou have to engineer for volatilitychange is the normthe ui layer is the experimentation layerexperimentation is not a one time eventlaunching a product is giving birth to the product. the products life just begins.design for throwaway-abilitymajority of the experience code written is thrown away in a yearlean startupfounded on build/measure/learnget out of the building (GOOB)invalidate your risky assumptionsgo for the minimal viable product (MVP)fail fast, learn fastget to the pivotlean uxdesigning products for build/measure/learn (lean startup)requires 3 rules to be followed at all timesget to & maintain a shared understandingform deep collaboration across disciplineskeep continuous customer feedback flowingengineering focused on learningengineering 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 feedbackLEANENGINEERINGApplying Lean Startup Principles to Bring Design to Lifeshared understandingthe more understanding the less documentationbut this doesnt mean NO documentationyou need whatever is needed to gain a shared understandingdeep collaborationstrong belief that ideas come from many different voicestrust is essentialall efforts never stray far from collaborative effortscontinuous customer feedbackthis is the lifeblood of the teamgets rid of politicsturns a team outside-ingetting to mvpmvp is a key tenant of lean startupapplied to engineering we should think: minimal viable everything. mv*minimal viable processminimal viable team sizeminimal viable technologyminimal viable toolswhat are startups using? getting to mvpmvp is a key tenant of lean startupapplied to engineering we should think: minimal viable everything. mv*minimal viable processminimal viable team sizeminimal viable technologyminimal viable toolswhat are startups using? zucks rule: how will the startup down the street do this tomorrow? do it like that today.healthy product life cycleDiscover Customer InsightsDefine Customer ProblemsDefine Solution ConceptsDeliver & Test SolutionsCDIthe solutionrefactoring your way to the patternpaypal vs netflixnew dna @paypaljan 2012fleshed out ui layer that could support rapid experimentationmarch 2012david Marcus becomes president of PayPalin the midst of transformationhermes projectre-inventing checkout with lean uxhermes projectwhiteboardto code code to usabilityproduct/design/engineering teams usability/customerslean ux in actionfree to iterate independent of agile user interface engineering - agile scrum team lean ux - lean team track engineering - agile scrum teamsprint 0usability usability usability usability usabilityrelease release release release{agilelean ux can provide a brain for agilethe lessons learnedwhat you can apply to your teamscreate a sandboxIMVU allows every engineer to put a test out to 1% of usersat netflix we often created additional tests that designers or engineers independently wanted to try as a solution to a hypothesis1hotwire case studyhow do you protect the parent organization from the internal startup? create a sandboxSource: Lean Startup in the Hotwire Enterprise by Kristen Mirenda & Karl Shultzhotwire case study: feedbackhate 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 Shultzhotwire case study: dataSource: Lean Startup in the Hotwire Enterprise by Kristen Mirenda & Karl Shultzmove to a living specbreak down barriers between prototyping and productionuse developers for prototyping as forcing functionembrace RITEavoid tools/process that get away from collaboration2make the spec realthere are many, many prototyping tools available nowyou can create a living spec with thesehowever the fidelity is never the same as real coderecommend HTMLprototyping(more on this later)but what about docs?watch out for predictive documentationwatch out for documentation that replaces collaboration or is a band-aid for bad processgood documentation will enhance collaboration, shared understanding and disseminate learningsuse a prototype stackwhiteboardto code code to usabilityproduct/design teamuser interfaceengineersusability/customersto enable learninguse a prototype stackwhiteboardto code code to usabilityproduct/design teamuser interfaceengineersusability/customersto enable learningnodejsJS librariesJS Templating(dustjs)less -> CSS imagesenables sketch to codeforcing functionit brings about a close collaboration between engineering and designit creates a bridge for shared understandingrequires a lot of confidence and transparencyhow 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 teamsusability usability usability usability usabilityrelease release release release{agilelean ux can provide a brain for agilestories & code sharedlean & agile teams should blend togethercode prototypes vs tools?use the right tool at the right timeas you get closer to agileaxure, proto.io, POP and a host of other prototyping tools are amazing -- especially early in the learning cyclecode prototypes important once you get close into the actual agile sprintsprovide high fidelity to the user testingfaster cycle from learning to livesuggestions for code prototypingbootstrap is one of the quickest to get going withwe use it on our production stack as welljetstrap allows you to drag and drop a bootstrap page to get a quick startnodejs is really powerful for prototyping your full application (web, tablet, desktop)prototyping toolssee:list of prototyping tools on my blog: http://bit.ly/SfWygkfew that we also use:Axure RPInVisionPOPengineer for experimentationlong shelf life to rapid experimentationfocus on learning not on deliverydesign for volatilityrefactor the tech stack with learning in mind3experiences must learnAll buildings are predictions. All predictions are wrong. There's no escape from this grim syllogism, but it can be softened.Stewart BrandOur software is always tearing itself apart (or should be)Recognize that different layers change at different velocitiesvelocity changes by layerrecognize that different parts of tech stack change at different velocitiesany 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 experimentswhy 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)rememberuse before you reuselet the experience drive the engineeringreuse is an engineering optimization. use is what users do. reuse is what engineers do.experience vs componentsexperience vs componentsbuild in rapid experimentationthink of the UI layer as the experimentation layerearly rapid prototyping leads to learnings to get into the right ballparkfollow with live A/B Testing. Lots of it.creates a healthy environment with constant customer feedback loopscontrast this with long shelf life culturerequirements for lean Stackindependent of the backend languageflexible enough to run in either the server or in the clientequally good at building web sites as it is building web applicationspushable 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 componentstangled up technologybig problem. technology and processes not geared to build/test/learn.refactor your way out of technical and experience debttechnical debtwe have to be on modern tech stack to continuously innovatewe have to be on a continuously available stackcontinuously integratingcontinuously deployingstack circa 2011/early 2012simple change could take minutes to seefollows an enterprise application model. ui gets built into the appjavajsp***restricted capabilities*prototyping was hardui 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 solutionserver side components**clientservera tale of two stacks (c++ & java)two non-standard stacksnew stack tied to Javaone word change could take 6 weeks to fix on c++ stackc++ javaxml jspproprietary uiproprietary uiold newishlong release cyclesdecision was to move to javamigration was already in place to leave the c++/xml stack behindsome odd choices preceded this: write everything in java (html, css & js!!)c++ javaxml jspproprietary uiproprietary uiXold newishold stack not designed for learningthis new stack was not conducive to prototypingfollowed an enterprise application model. ui gets built into the appajax/components all done server-side (subclass java controller)javajspproprietary uiprototyping was hardui bits could only live hereseparate the ui bitscode = JS(backbone)templates = JS{dust}style = CSS(less)imagesre-engineered the user interface stack so that the only artifacts are: javascript css imagesditched the server-side mentality to creating UIs no more server-side only templates no more server-side components no more server-side managing the uiuse javascript templatingtemplates get converted to javascriptHello {name}we use dust.jscode = JS(backbone)templates = JS{dust}style = CSS(less)imagesJavaScriptcompiles to...javascript executedto generate uiui bits now just natural web artifactsserver-side language independentserver/client agnosticCDN readycacheablerapid to createcode = JS(backbone)templates = JS{dust}style = CSS(less)imagesportable in all directionsJS templating can be run in client browser or server on the production stackwe can drag & drop the ui bits from prototyping stack to the production stackjava (rhinoscript)node.js{dust}JS templateprototypestackproductionstack{dust}JS templateclient ORservereither stackembrace open source fullystop rolling your own solutionsdemocratize software developmentbuild software that can be shared (keeps architecture clean)4use open source religiouslywork in open source modelinternal github revolutionized our internal developmentrapidly replaced centralized platform teams innovation democratizedevery developer encouraged to experiment and generate repos to share as well as to fork/pull requestgive back to open sourcewe have a projects that we will open sourcenode bootstrap (similar to yeoman)we are contributing back to open sourcecontributions to bootstrap (for accessibility)contributions to bootstrap (for internationalization)core committer on dustjs projectusing github for continuous *use github for continuous integrationstarting to use github repo model for continuous deploymentmarketing pagesproduct pagescontent updates & triggers into i18n, l10n, adaptationcomponentsgive agile a brainuse lean ux as the brain for agiledevelop a lean cadenceinvolve all members in lean ux (balanced teams)5free to test frequently with userssprint fasterfocus on getting to customer as early and as often as possibleremoves the politics in the team as this becomes the arbiteryou can slow down this cadence after you converge on key hypotheses and potential solutionsexample: spotifysquads run like lean startupsspotify: squadsimilar to scrum team. feels like startuplong term mission: build & improve the product. stay long term on the product.apply lean startup principles like MVPthink it, build it, ship it, tweak itemphasis on great workspacespotify: tribescollection of squads that work in a related areaincubators for tribeshold regular gatheringsspotify: chapters and guildschapters represent horizontal practices within a tribeguilds represent horizontal practices across tribes become hypothesis drivenlearn to state design goals in terms of solving specific customer problemsdont be afraid to invalidate hypotheseslook for the pivot6embrace the problem not the solutionengineering: dont start with technology, start with experiencedesign: get your ideas out earlytogether: get in front of customers so problem is the focus, not our current solution7co-locate if at all possiblehigh bandwidth meatspace facilitates shared understanding and deep collaboration also facilitates shared time with the customer8suggestionsat a minimum teams should come together for the first few weeks to build shared understanding, deep collaboration and getting feedback from customersfor distributed members use high bandwidth communication where possible (skype, tele-presence)high bandwidth communication necessary.github counterpointelectronic: 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 coordinationhttp://tomayko.com/writings/adopt-an-open-source-process-constraintstools that can helpteam working agreementdecide who is the decision makerdefine your cadencedefine how you will work togetherdefine your hypothesesteam working agreementdecide who is the decision makerdefine your cadencedefine how you will work togetherdefine your hypothesesshared understandingthe more understanding the less documentationbut this doesnt mean NO documentationyou need whatever is needed to gain a shared understandingdeep collaborationstrong belief that ideas come from many different voicestrust is essentialall efforts never stray far from collaborative effortscontinuous customer feedbackthis is the lifeblood of the teamgets rid of politicsturns a team outside-ingetting to mvpmvp is a key tenant of lean startupapplied to engineering we should think: minimal viable everything. mv*minimal viable processminimal viable team sizeminimal viable technologyminimal viable toolswhat are startups using? getting to mvpmvp is a key tenant of lean startupapplied to engineering we should think: minimal viable everything. mv*minimal viable processminimal viable team sizeminimal viable technologyminimal viable toolswhat are startups using? zucks rule: how will the startup down the street do this tomorrow? do it like that today.picture creditshttp://www.flickr.com/photos/wuschl2202/531914709/sizes/o/in/photostream/http://www.flickr.com/photos/a_ninjamonkey/3565672226/sizes/z/in/photostream/http://www.flickr.com/photos/funky64/4367871917/sizes/z/in/photostream/http://www.flickr.com/photos/emdot/9938521/sizes/o/in/photostream/http://www.flickr.com/photos/gregory_bastien/2565132371/sizes/z/in/photostream/http://www.flickr.com/photos/trvr3307/3703648270/sizes/z/in/photostream/http://www.flickr.com/photos/legofenris/5426012042/sizes/l/in/photostream/http://www.flickr.com/photos/cleaneugene/6866436746/sizes/c/in/photostream/http://www.flickr.com/photos/66309414@N04/6172219058/sizes/l/in/photostream/http://www.flickr.com/photos/nicmcphee/2954167050/sizes/l/in/photostream/http://www.flickr.com/photos/pasukaru76/6151366656/sizes/l/in/photostream/http://www.flickr.com/photos/brianmitchell/2113553867/sizes/o/in/photostream/http://www.flickr.com/photos/ciscel/422253425/sizes/z/in/photostream/http://www.flickr.com/photos/zebble/6817861/sizes/l/in/photostream/http://www.flickr.com/photos/nicasaurusrex/3069602246/sizes/l/in/photostream/http://www.flickr.com/photos/nathangibbs/98592171/sizes/z/in/photostream/http://www.flickr.com/photos/neilsingapore/4047105116/sizes/l/http://www.flickr.com/photos/smb_flickr/439040132/http://www.flickr.com/photos/therevsteve/3104267109/sizes/o/http://www.flickr.com/photos/st3f4n/4193370268/sizes/l/http://www.flickr.com/photos/eole/380316678/sizes/z/http://www.flickr.com/photos/cobalt/3035453914/sizes/z/http://www.flickr.com/photos/mbiskoping/6075387388/http://www.flickr.com/photos/fragglerawker/2370316759/sizes/z/http://www.flickr.com/photos/soldiersmediacenter/4685688778/sizes/z/picture credits (continued)http://www.flickr.com/photos/dahlstroms/4083220012/sizes/l/http://www.flickr.com/photos/don2/53874580/sizes/z/http://www.flickr.com/photos/hao_nguyen/3634552812/sizes/z/http://www.flickr.com/photos/42573918@N00/8194636033/http://www.flickr.com/photos/pagedooley/2420194539/sizes/z/http://www.flickr.com/photos/neilsingapore/4047105116/sizes/l/http://www.flickr.com/photos/smb_flickr/439040132/http://www.flickr.com/photos/therevsteve/3104267109/sizes/o/http://www.flickr.com/photos/st3f4n/4193370268/sizes/l/http://www.flickr.com/photos/eole/380316678/sizes/z/http://www.flickr.com/photos/cobalt/3035453914/sizes/z/http://www.flickr.com/photos/mbiskoping/6075387388/http://www.flickr.com/photos/fragglerawker/2370316759/sizes/z/http://www.flickr.com/photos/soldiersmediacenter/4685688778/sizes/z/http://www.flickr.com/photos/janed42/5033842895/sizes/z/http://www.flickr.com/photos/9619972@N08/1350940605/http://www.flickr.com/photos/alanenglish/483251259/sizes/z/thanks flickr!

Recommended

View more >