Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Engineering to embrace change

Engineering to embrace change

How to find out what users want? Experiment. How to experiment? Prototype. How to prototype? How can engineers and designers collaborate well to get to users fast?

6389f3db059111f68daa44ab6d01a1bd?s=128

Srihari Sriraman

October 27, 2018
Tweet

Transcript

  1. Engineering to embrace change Srihari Sriraman | nilenso

  2. What – Experimenting in early stage products How – Quick

    prototyping using Real Software™ Who – Small teams of designers, and engineers About the talk
  3. The fast, free app for clinicians to track patients with

    high blood pressure. https://simple.org https://github.com/simpledotorg Simple
  4. - The users are nurses who work in public health

    centres in rural villages in India - We are migrating from a paper system, to an offline- first app Simple
  5. The place

  6. The users

  7. The team The team

  8. The team

  9. basic flows Find or register patient Record BP Record drugs

    Follow up
  10. How do we know we are on the right track?

    Are we really building what users want? Is the interface intuitive?
  11. Experimenting

  12. Build Get to users Fail expensive

  13. Build faster Get to users faster Fail faster

  14. Existing methodologies Spike Tracer Bullet R & D Quick, throw-away

    implementation of functionality, executed within a time-box. http://wiki.c2.com/?SpikeSolution Narrow implementation of functionality in production quality. http://wiki.c2.com/?TracerBullets Long term research, or development of new products, that are high risk, and have unclear return. http://wikipedia.org/wiki/ Research_and_development Product Development Spike Spike Spike Product Development Tracer Bullet Product Development R & D
  15. The Experiment Lane An R&D lane for exploring ideas using

    throw-away prototypes with simple versions of all functionalities. Product Development Experiment Lane
  16. Creating feedback cycles 1. Conduct user study 2. Analyse results

    3. Improve design 5. Engineer solution 4. Plan next user study 2 weeks
  17. Create a simpler version of the app focused on happy

    paths of experimental features, and flows.
  18. Prototyping

  19. Pen, Paper Wireframes Hi-Fi Mockups Low-Fi Prototypes Hi-Fi Prototypes Real

    Software™ time – flexibility + design research – usage x Days Weeks Months spectrum of fidelities + time – flexibility + design research + usage } Design + Engineering
  20. Alternatives Pitfalls Always online No storage Sub-par programmability Constant guidance

    No custom components “Start from the beginning”
  21. The recommendation

  22. Demo of experiments

  23. Alternative flows One-time only flows Important only for context A-la-carte

    wizard-of-oz-ing
  24. A notion of time Empty states, full states User responses

    to data Emulate reality, but time-lapsed
  25. A/B tests Observed in real time Same user, different interfaces

    Fully functional components YoB / DoB / Age / Picker / Separate fields
  26. Realistic data First class seed data Persistence Generated sample data

  27. Realistic data First class seed data Persistence Generated sample data

  28. Realistic data First class seed data Persistence Generated sample data

    {:name "Same first name different last name" :common {:age 35 :gender "male" :profile :htn-weeks} :variants [{:full-name "Shreyas Malhotra”} {:full-name "Shreyas Garewal”}]} {:name "Same full name, similar ages, And different locations" :common {:full-name "Mahalakshmi Puri" :gender "female" :profile :htn-days} :variants [{:village-or-colony 1, :age 70} {:village-or-colony 2, :age 72 :profile :htn-months :next-visit-in-days 31} {:village-or-colony 3, :age 75}]}
  29. Technology choices Dynamic programming language Schema-less storage, on file In-app,

    in-memory database Live reloads (not just artefacts) REPL and related tooling Generative seed/sample data
  30. Engineering practices Independent environment Remove all interfaces Focus on happy

    paths Extensive manual tests Model external domain First class seed data
  31. eXtreme Programming with designers

  32. Communication Simplicity Feedback Talk about system requirements – Over pen/paper

    prototypes, whiteboards, or simpler prototypes Sit together, pair program – Should this animation be programmed? A gif? Not done? – Discuss tradeoffs in design vs cost of change Most often, designers have thought of other solutions – Complex date entry field with validations, vs separate fields
  33. YAGNI (you ain’t gonna need it) – Just screenshots, and

    a walk-through? – Don’t build a fancy BP keyboard, or fuzzy search – Don’t add a login flow Incremental design – System design (both visual and software) should be incremental – Fit for the needs of the day – Throw-away when there are drastic changes Communication Simplicity Feedback
  34. From the customer – frequent user studies From the system

    – use the app, and fix bugs every day From the team – Post study meetings – Bi-weekly cycles for introspection and execution – PM Board reflecting everyone’s work Communication Simplicity Feedback
  35. the dramatic effectiveness of small teams

  36. http://www.qsm.com/blog/2012/part-ii-small-teams-deliver-lower-cost-higher-quality Small teams > Large teams Two-pizza teams Coordination overheads

    rise dramatically Defect rates reduce with size Experiment lanes for small teams People matter, technology can only do so much
  37. Get to your users faster Be wrong faster

  38. Create a simpler version of the app focused on happy

    paths of experimental features, and flows.
  39. Engineering to embrace change Srihari Sriraman | nilenso