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?

Srihari Sriraman

October 27, 2018
Tweet

More Decks by Srihari Sriraman

Other Decks in Technology

Transcript

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

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

    high blood pressure. https://simple.org https://github.com/simpledotorg Simple
  3. - 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
  4. How do we know we are on the right track?

    Are we really building what users want? Is the interface intuitive?
  5. 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
  6. The Experiment Lane An R&D lane for exploring ideas using

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

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

    paths of experimental features, and flows.
  9. 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
  10. A notion of time Empty states, full states User responses

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

    Fully functional components YoB / DoB / Age / Picker / Separate fields
  12. 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}]}
  13. 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
  14. Engineering practices Independent environment Remove all interfaces Focus on happy

    paths Extensive manual tests Model external domain First class seed data
  15. 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
  16. 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
  17. 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
  18. 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
  19. Create a simpler version of the app focused on happy

    paths of experimental features, and flows.