How to prototype to understand your clients

855 views

Published on

The talk by Antti Tarvainen and Harri Lammi at Turku Agile Day on May 16, 2012.

Published in: Technology
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
855
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
12
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

How to prototype to understand your clients

  1. 1. How to prototype tounderstand your clients antti.tarvainen@leonidasoy.fi harri.lammi@leonidasoy.fi @tarvaina @harri_lammi
  2. 2. Talk in one slide Understand the context1. of your system. Build prototypes to validate2. your understanding of the context and the design. Different situations call for3. different kinds of prototypes.
  3. 3. PROTOSONNI“A prototype in seven days”
  4. 4. Case: Lausuntopalvelu Demo http://youtu.be/jVlYofasZnI http://lausuntopalvelu.fi https://github.com/leonidas/lausuntopalvelu-prototyyppi but look at it on your own risk — it really is throwaway code.
  5. 5. Schedule: Understand the problemStart shop 1 day Iterate with paper protosDesign & Design user interface 5 daysDevelopment Develop functionalityDemo 2 hours Deliver to the customerTeam:Proxy product owner2 IX/UI designers2 software developers
  6. 6. Startshop TipsDO have a scheduleDO let the client tell their storyDON’T try to come up with a solution beforeyou understand the problemDON’T delegate design responsibility to theclient
  7. 7. From context to the solution Context PersonasWe need tounderstand the Scenarioscontext before Paper prototypeswe canimplement the Wireframessolution. Layouts Solution
  8. 8. From context to the solution Context PersonasWe use Scenariosdifferent toolsto move from Paper prototypescontext towards Wireframessolutions. Layouts Solution
  9. 9. From context to the solution ContextWe verify our Personasunderstanding Scenariosat each levelwith the client Paper prototypesand by Wireframescomparing tothe other levels. Layouts Solution
  10. 10. PO CODE
  11. 11. Development TipsDO have small tasks (< 2h)DO commit and deploy all the timeDO have product owner test the prototype allthe timeDON’T write anything extraDON’T spend time in polishing
  12. 12. Internals in this casejQuery, Transparency, Spine, Undescore, ...CoffeeScriptNode.jsMongoDBGithubLinodeYouTube
  13. 13. Demo to the client
  14. 14. Lessons learned• 7-day projects are exciting!• Throw the code away.• Throw the design away.
  15. 15. What is good software?
  16. 16. What is a good tool?
  17. 17. context toolA tool is used in some context.
  18. 18. context tool In the contextdifferent forces act upon the tool
  19. 19. context tool Tool is goodif it fits the context.
  20. 20. context tool Tool is badif it doesn’t fit the context.
  21. 21. Example.
  22. 22. when you areExample. just a few bored and need minutes of time entertainment you can stop whenever you want always with you etc. etc. you don’t want to learn anything difficult
  23. 23. when you areExample. just a few bored and need minutes of time entertainment you can stop whenever you want always with you etc. etc. you don’t want to learn anything difficult
  24. 24. when you areExample. just a few bored and need minutes of time entertainment you can stop whenever you want always with you etc. etc. you want to learn something useful
  25. 25. when you areExample. bored and need social entertainment situation you can stop whenever you want always with you etc. etc. you want to learn something useful
  26. 26. So to create a good tool you need two things.
  27. 27. context ? ? ?1. Understand the contextwhere the tool will be used.
  28. 28. context tool2. Design a tool that fits the context.
  29. 29. context toolYou cannot tell from an abstract idea, if it will fit the context.
  30. 30. context toolAs you make the idea more concrete,you will see its problems more clearly.
  31. 31. context toolThis gives you an idea how to improve it.
  32. 32. context toolAnd so on.
  33. 33. context tool Continue iterating until you find a design thatfits the context well enough.
  34. 34. specifi implem mainte design testingcation entation nance Traditional waterfall lacks iteration
  35. 35. specifi implem mainte design testingcation entation nance context tool Probably resulting in a bad tool.
  36. 36. Agile methods, e.g. Scrum,introduce iteration to fix that problem.
  37. 37. But a few things are unclear 1. How do you find the context?2. How does the context result in a backlog?
  38. 38. user needs User needs are the most fundamental part of the context.
  39. 39. architecture user interfaceuser needs ? requirements data model feature list What is the most logical next step? Why?
  40. 40. architecture user interfaceuser needs requirements data model feature list User interface is, because it can be tested against user needs.
  41. 41. architecture user interfaceuser needs requirements data model feature listYou cannot tell from e.g. data modelalone if it will match the user needs.
  42. 42. This is our process.
  43. 43. The right side of the processis traditional agile, e.g. Scrum.
  44. 44. Before starting Scrum weinvestigate the context and look for solutions by prototyping.
  45. 45. context? ? ? ? We find out the context of the system by interviewing potential users.
  46. 46. context? We describe the context by writing scenarios.
  47. 47. contexttool ? We create prototypes based on the scenarios.
  48. 48. contexttool ? We test the prototypes using simulation and user testing.
  49. 49. When the user interaction of the most common scenarios is clear, we put them to the product backlog.
  50. 50. A use case may consist of one or more features.
  51. 51. We take new features to production based on the rhythm of the project. Preferrably as soon as they are ready.
  52. 52. There are multiple kinds of prototypes.
  53. 53. Paper prototyping is fastest.
  54. 54. A fancier prototype adds precision but not necessarily accuracy.
  55. 55. We use mostly paper prototypes and functional prototypes.
  56. 56. The length of a paper prototype feedback loop is minutes.
  57. 57. The length of a functional prototype feedback loop is days.
  58. 58. Paper prototype is good for finding out and validatingthe use cases and the design.
  59. 59. A functional prototype is good forcommunicating the vision of the product, selling it and validating the market.
  60. 60. Talk in one slide Understand the context1. of your system. Build prototypes to validate2. your understanding of the context and the design. Different situations call for3. different kinds of prototypes.

×