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. Engineering to
    embrace change
    Srihari Sriraman | nilenso

    View Slide

  2. What – Experimenting in early stage products
    How – Quick prototyping using Real Software™
    Who – Small teams of designers, and engineers
    About the talk

    View Slide

  3. The fast, free app for clinicians
    to track patients with high blood
    pressure.
    https://simple.org
    https://github.com/simpledotorg
    Simple

    View Slide

  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

    View Slide

  5. The place

    View Slide

  6. The users

    View Slide

  7. The team
    The team

    View Slide

  8. The team

    View Slide

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

    View Slide

  10. How do we know we are on the right track?
    Are we really building what users want?
    Is the interface intuitive?

    View Slide

  11. Experimenting

    View Slide

  12. Build
    Get to users
    Fail
    expensive

    View Slide

  13. Build faster
    Get to users faster
    Fail faster

    View Slide

  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

    View Slide

  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

    View Slide

  16. Creating feedback cycles
    1. Conduct user study
    2. Analyse results
    3. Improve design
    5. Engineer solution
    4. Plan next user study
    2 weeks

    View Slide

  17. Create a
    simpler version of the app focused on happy paths
    of experimental features, and flows.

    View Slide

  18. Prototyping

    View Slide

  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

    View Slide

  20. Alternatives
    Pitfalls
    Always online
    No storage
    Sub-par programmability
    Constant guidance
    No custom components
    “Start from the beginning”

    View Slide

  21. The recommendation

    View Slide

  22. Demo of experiments

    View Slide

  23. Alternative flows
    One-time only flows
    Important only for context
    A-la-carte wizard-of-oz-ing

    View Slide

  24. A notion of time
    Empty states, full states
    User responses to data
    Emulate reality, but time-lapsed

    View Slide

  25. A/B tests
    Observed in real time
    Same user, different interfaces
    Fully functional components
    YoB / DoB / Age / Picker / Separate fields

    View Slide

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

    View Slide

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

    View Slide

  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}]}

    View Slide

  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

    View Slide

  30. Engineering
    practices
    Independent environment
    Remove all interfaces
    Focus on happy paths
    Extensive manual tests
    Model external domain
    First class seed data

    View Slide

  31. eXtreme Programming
    with designers

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  35. the dramatic effectiveness
    of small teams

    View Slide

  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

    View Slide

  37. Get to your users faster
    Be wrong faster

    View Slide

  38. Create a
    simpler version of the app focused on happy paths
    of experimental features, and flows.

    View Slide

  39. Engineering to
    embrace change
    Srihari Sriraman | nilenso

    View Slide