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?
- 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
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
The Experiment Lane An R&D lane for exploring ideas using throw-away prototypes with simple versions of all functionalities. Product Development Experiment Lane
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
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}]}
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
Engineering practices Independent environment Remove all interfaces Focus on happy paths Extensive manual tests Model external domain First class seed data
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
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
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
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