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?

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