Lean Engineering. Applying Lean Principles to Building Experiences

43,426 views

Published on

Highlights a couple of principles that we have been applying to our UI engineering teams to move us to applying Lean UX to our products.

This was a 25 minute talk from Lean Day UX in NYC on March 1, 2013.

2 Comments
38 Likes
Statistics
Notes
  • It's kind of amazing how straightforward this can be. The key is really taking seriously the need to get constant feedback from users. And then these lightweight stacks actually work well in production (especially at the stage we are at now)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Nice. Reminds me a lot of the changes we made at the startup I worked at 2000-2005. Prototyping in JSP / Weblogic was far too heavy - I made a super light Access database / ASP prototype and my productivity skyrocketed. The backend devs would grab html/css/js straight from my prototype and integrate it into the actual product. Worked great!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
43,426
On SlideShare
0
From Embeds
0
Number of Embeds
3,453
Actions
Shares
0
Downloads
189
Comments
2
Likes
38
Embeds 0
No embeds

No notes for slide

Lean Engineering. Applying Lean Principles to Building Experiences

  1. lean engineeringapplying lean principles to building experiences bill scott (@billwscott) sr. director, user interface engineering, paypal LEAN DAY UX March. 1, 2013. NY
  2. the way it washow we used to engineer experiences
  3. buildingexperiencescirca 1985merry band of three.dropped out of college forsemester. prototyped ourway to nirvana.however...
  4. had to roll yourown everything(close your eyes & imagine)no internet. no google. noblogs. no email. no blogs. nostackoverflow. no github. notwitter.much of the software erahas been about buildingfrom scratch.of course open source wasgaining momentum. unix.gnu. linux. perl. mozilla.
  5. disconnectedfrom experiencedeliver to disk then to usereverything was focused ongetting it perfect forstamping on the diskno user in the loop.experience happenedsomewhere down the supplychain
  6. software had along shelf lifenot dynamically updatabledesigned for longevityherculean effort to deliverengineers ran the asylumdelivery dates drive theexperienceBDUF & waterfall
  7. btw, agile didn’t fix itagile has been a big step in the right directionbut is an engineering disciplinedoesn’t address the full life cycleagile has become big business and sometimescollapses under the weight of “ceremonies” (process)but agile is a good “engine” for delivery if you knowwhat to roughly buildneeds a brain...
  8. an epiphanyengineering for the experience
  9. netflix waycustomer is OOBget code OOB as fast aspossiblecustomer metrics driveeverythingthink it (quickly). build it.ship it. tweak itfail fast. learn fast.the epiphany...
  10. design forexperimentationthe ui layer is anexperimentation layer fourchange is the norm different PS3 experiencesexperimentation is not a one launched on same daytime event
  11. paypala study in contrast
  12. paypal circa 2011roll your own. disconnecteddelivery experience. culture of long shelf life. inward focus. risk averse.
  13. new dnainsertedjan 2012fleshed out ui layer thatcould support rapidexperimentationmarch 2012david Marcus becomespresident of PayPalapril 2012formed lean ux team toreinvent checkout experience
  14. change is working its way out
  15. two principlesapplying lean ux & engineering at paypal
  16. #1 engineer for experimentation
  17. experiences must learn All buildings are predictions. All predictions are wrong. Theres 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
  18. engineer for lean uxLean UX - co-located Product/Design team UIEs Usability/Customers And back again... Whiteboard Code to to code Usabilityengineering stack should treat prototype & production the same allow rapid sketch to code life cycle allow quick changes during usability studies (RITE) support being the “living spec”
  19. stack circa 2011/early 2012prototyping restricted capabilities* was hard client server server side “ui bits” components** simple change could could only take minutes to see live here jsp*** follows an “enterprise application” model. ui java gets built into the “app” * assumed client developers were low-skill * required server side java eng for simple client changes ** java server pages. server-side java templating solution
  20. allowed us to refactorui portability to get to the new stack (backward compatibility) dustjs dustjs (js templating (js templating) client server dustjs dustjs (js templating) (js templating) JS templating can be run on the client or run on the server node.js java js templating can be prototype production run on nodejs stack or stack stack run on java stack (rhinoscript)
  21. enable a brain for agile usability usability usability usability usabili lean ux - lean team track (prototyping) { user interface engineering - agile scrum team (production)agile sprint 0 engineering - agile scrum team release release release release
  22. #2 engineer with open source mindset
  23. use open source religiously
  24. work in open source modelinternal github revolutionizedour internal developmentrapidly replaced centralizedplatform teamsinnovation democratizedevery developer encouragedto experiment and generate reposto share as well as to fork/pull request
  25. give back to open sourcewe 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
  26. using github for continuous *use github for continuous integrationstarting to use github repo model for continuousdeployment marketing pages product pages content updates & triggers into i18n, l10n, adaptation components
  27. summaryto support collaboration, shared understanding andcontinuous customer feedback we changed:technology. but not for tech sake. we did it for theexperience to support LS principles.process. enabled lean ux and put a brain on agile.people. revitalized our existing talent and startedattracting new talent.
  28. blogshttp://looksgoodworkswell.comhttp://designingwebinterfaces.comtwitterfollow me on twitter @billwscottbook designing web interfaces O’Reillypicture creditshttp://www.flickr.com/photos/paolomargari/3793121065/sizes/z/http://www.flickr.com/photos/smb_flickr/439040132/http://www.flickr.com/photos/juanpol/16287486/sizes/z/http://www.flickr.com/photos/giesenbauer/4092794246/sizes/l/http://www.flickr.com/photos/therevsteve/3104267109/sizes/o/http://www.flickr.com/photos/not_wise/182849352/sizes/l/http://www.flickr.com/photos/37217398@N02/3442676067/sizes/l/http://www.flickr.com/photos/hongiiv/4151964823/sizes/z/http://www.flickr.com/photos/therevsteve/3104267109/sizes/o/http://www.flickr.com/photos/mbiskoping/6075387388/http://www.flickr.com/photos/soldiersmediacenter/4685688778/sizes/z/

×