User Experience in a Rapidly Changing World, for ISA '13, Recife Brazil

7,535
-1

Published on

Slides from my talk at Interaction South America, Recife, Brazil, November 15, 2013.

Software is eating the world. Thanks to newly mature platforms, techniques and infrastructure, teams are moving faster than ever before. So how do you design software in this world, a world of continuous integration, deployment and delivery?

Published in: Design, Technology, Business

User Experience in a Rapidly Changing World, for ISA '13, Recife Brazil

  1. 1. User Experience in a Rapidly Changing World Interaction South America, Recife Brazil November 15, 2013 Josh Seiden Principal Neo New York josh.seiden@neo.com @jseiden
  2. 2. Me and my #hashtags Josh Seiden www.neo.com @neo_innovation @ jseiden leanUX #leanStartup # leanUXbook #
  3. 3. 1. CHANGE IS THE NEW REALITY 2. ADAPTING OUR PRACTICE 3
  4. 4. Old assumptions, new reality 4 4
  5. 5. Old assumptions, new reality
  6. 6. No more “Model Years” 6
  7. 7. SOFTWARE ENABLES CONTINUOUS CHANGE 7
  8. 8. Coping with Continuous Production Lean Startup Business? Business Design? Agile UX Design? Lean Startup Business? Agile UX Agile
  9. 9. Enterprise? Lean Startup Business? Business Design? Agile UX Design? Lean Startup Business? Agile UX Agile
  10. 10. SOFTWARE IS EATING THE WORLD. Mark Andreessen, WSJ, Aug 2011 10
  11. 11. HOW CAN WE ADAPT OUR PRACTICE TO THIS NEW REALITY? 11
  12. 12. AGENDA 1. CONTINUOUS LEARNING 2. ASSUMPTIONS & HYPOTHESES 3. SMALL X-FUNCTIONAL TEAMS 4. ENABLE MAKING 5. MANAGE OUTCOMES 6. A NEW ORGANIZATION 12
  13. 13. 1 CONTINUOUS LEARNING 13
  14. 14. Internet Mouse
  15. 15. Reduce Inventory, Risk and Waste This is going to be BIG! Make a design decision Nope. MONTHS HOURS Get feedback from market Concept credit: @clevergirl
  16. 16. A system built on continuous learning Risk Learning! Diagram concept: @clevergirl 16
  17. 17. Continuous Learning Streams Qualitative information Quantitative information Process learning 17
  18. 18. Systems vs. Objects
  19. 19. 2 ASSUMPTIONS AND HYPOTHESES 19
  20. 20. EVERY PROJECT STARTS WITH ASSUMPTIONS 20
  21. 21. 360° ASSUMPTIONS Tech-enthusiast CUSTOMER consumers Need to control web PROBLEM browser from couch Internet mouse! SOLUTION Able to surf the CUSTOMER internet from the OUTCOME couch Computer stores, CUSTOMER magazine ACQUISITION advertising Purchasers of EARLY Gateway ADOPTER Convergence TV Traditional retail BUSINESS channel sales MODEL Logitech, COMPETITION Microsoft KEY COMPETITIVE More buttons than ADVANTAGE anyone else!
  22. 22. Technique: Write the test first We believe ______. We’ll know this is true when we see § qualitative outcome and/or § quantitative outcome § That improves this KPI.
  23. 23. Hypothesis statement We believe that [doing this] for [these people] will achieve [this outcome]. We’ll know this is true when we see [this market feedback].
  24. 24. Hypothesis statement: feature We believe that creating Internet Mouse for people who own “Convergence” TVs will need a way to control the computer from their couches We’ll know this is true when we see people buying Convergence TVs.
  25. 25. Hypothesis statement: business We believe that creating Internet Mouse for people who own “Convergence” TVs will get us in the internet business. We’ll know this is true when we see pre-orders from our retail channel partners.
  26. 26. 3 SMALL X-FUNCTIONAL TEAMS 26
  27. 27. REMEMBER THIS? Business? Business BUSINESS Design? DESIGN Design? Lean Startup Business? Agile UX DEVELOPERS
  28. 28. THIS DOESN’T WORK Business? Business BUSINESS Design? DESIGN Design? Business? Agile UX DEVELOPERS
  29. 29. Small, dedicated, co-located & cross-functional 1. 2. 3. 4. 5. Two-pizza teams 1 project each 1 location (same time zone) Self-sufficient Freedom to experiement
  30. 30. Example: PayPal
  31. 31. 4 BIAS TOWARDS & ENABLE MAKING 31
  32. 32. 32
  33. 33. Twitter Bootstrap
  34. 34. Design Systems at GE 34
  35. 35. UI Technology at PayPal Bill Scott Sr. Director of UI Technology PayPal 35
  36. 36. MVP = MINIMUM VIABLE PRODUCT “THE SMALLEST THING YOU CAN MAKE TO TEST YOUR HYPOTHESIS.” 36
  37. 37. What are businesses trying to learn? 1. Is there a need / opportunity in the market? 2. Will people buy my solution? 3. Does my solution work? 37
  38. 38. MVP: Pre-sales 38
  39. 39. Don’t design a product, design an experiment. 39
  40. 40. 40
  41. 41. 41
  42. 42. 42
  43. 43. 43
  44. 44. 5 MANAGE OUTCOMES 44
  45. 45. Output
  46. 46. Outcome
  47. 47. Impact
  48. 48. Output, Outcome, Impact § § § Output: the software we build. The materials we produce. Easy to measure. Example: A new log-in page. Outcome: the change in the world after we deliver output. Harder to measure. Example: increase user log-in rate. Impact: the change we see over time. Very hard to measure. Example: Our service is profitable.
  49. 49. Don’t manage output. Instead, focus on outcomes. Don’t make teams responsible for impact.
  50. 50. Case Study: TheLadders 14%
  51. 51. Case Study: TheLadders 63%
  52. 52. 6 A NEW ORGANIZATION 53
  53. 53. Enterprise? Lean Startup Business? Business Design? Agile UX Design? Lean Startup Business? Agile UX Agile
  54. 54. Small-chunk, outcome-based, predictable funding Stakeholders $$ $ Product validation Small team Business model validation Culture / Infrastructure to support continuous learning 55
  55. 55. AGENDA 1. CONTINUOUS LEARNING 2. ASSUMPTIONS & HYPOTHESES 3. SMALL X-FUNCTIONAL TEAMS 4. ENABLE MAKING 5. MANAGE OUTCOMES 6. A NEW ORGANIZATION 56
  56. 56. Thank you! josh@neo.com | @jseiden www.leanuxbook.com www.neo.com @neo_innovation

×