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
srihari
devopstaiwan
asahihidehiko
prashantspol
nagix
murahigeas
n1ru4l
masakamayama
mixi_engineers
line_developers
sadonosake
gl_tsukasa
keio_smilab
tenderlove
cassininazir
dotmariusz
3n
chriscoyier
paulrobertlloyd
matthewcrist
stephaniewalter
notwaldorf
wjessup
rasmusluckow
smashingmag