Paper prototyping

636 views

Published on

David Lamas @ European Innovation Academy Summer Session 2013

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

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

No notes for slide

Paper prototyping

  1. 1. Monday Tuesday 10:00 to 11:00 Introduction to paper prototyping. Critical assessment of representative examples. Stop-motion prototyping. Introduction to paper prototype evaluation. Evaluating paper prototypes using techniques such as expert evaluation, cognitive walk-through, co- discovery, wizard of Oz and others. Critical assessment of representative examples. 11:00 to 12:00 Initial prototyping activities. Drafting paper prototype evaluation protocols. 13:00 to 16:00 Prototyping madness (sharing your initial ideas with the group, 30 seconds per team). Further prototyping activities. Prototyping madness (sharing your ideas with the group, 30 seconds per team). Prototyping madness (sharing your draft evaluation protocols with the group, 30 seconds per team). Paper prototype refinement through evaluation. Prototyping showcase (sharing the results of your prototyping efforts with the group for feedback, 2 minutes per team).
  2. 2. Paper Prototyping
  3. 3. Prototyping • Prototyping is an interaction design approach used by designers to acquire feedback from users about future designs – While simple, paper prototyping can provide a great deal of useful feedback which will result in the design of better products
  4. 4. Explorative prototyping • Explorative prototyping is used to explore system requirements in cooperation with users – I can be seen as a communication facilitator designers, developers and users
  5. 5. Experimental prototyping • Experimental prototyping aims to assess whether the planned system will be adequate and acceptable when finished – Experimental prototypes can be used as requirements specification
  6. 6. Evolutionary prototyping • And prototyping can also be evolutionary in nature – This is the case when a design evolves through multiple generations succeeding each other – In this case, each prototype is an early version of a product or service that is further worked upon until the prototype has evolved into a final solution
  7. 7. Prototypes • Prototypes may be horizontal or vertical – Horizontal prototypes cover a very broad range of the intended future features, but only very little of the actual functionality of the features is addressed – Vertical prototypes address fewer features but, on the other hand, these are almost fully described.
  8. 8. Prototypes • Prototypes serve several purposes… – They incite and facilitate experimentation as they are inexpensive to alter • As they focus on content and functionality and turn attention away from details of graphic design
  9. 9. Prototypes • Prototypes serve several purposes… – They incite criticism from users because they are perceived as being low-cost and low-fidelity • If a user is presented with an early version of a product or service that has required substantial work, she or he is likely to be more reluctant (as well as able) to criticize it
  10. 10. Prototypes • Prototypes serve several purposes… – They have the advantage of ‘grounding’ the discussion during a stakeholder session, making the sure the session does not get too much off track
  11. 11. Prototypes
  12. 12. Prototypes • The question now should be… – How do we go about it?
  13. 13. Prototyping process • You… – Follow design patterns – Create a prototype for each (set of) user stories • Starting by sketching and structuring and eventually ending with a paper mockup of the envisioned product or service frontend – You iterate the prototype and the user stories • There is an interplay between both so its only expectable that they will co-evolve
  14. 14. Design patterns
  15. 15. Design patterns
  16. 16. Design patterns
  17. 17. Prototyping user stories • Well… you start with your user story and end up with something like this:
  18. 18. Prototyping user stories • Early prototypes normally evolve through a sketching and structuring iterative process – Sketching is normally based on existing design patterns, unless there is an unusual problem to be addressed or a novel solution with potential added value – Structuring normally follows state transition diagrams principles, which allows clear validation of the underlying user stories
  19. 19. Prototyping user stories • Early prototypes normally evolve through a sketching and structuring iterative process
  20. 20. Mature paper prototypes • Mature paper prototypes usually let go of the state transition diagram and become fully actionable paper prototypes – Of course, in this case the processor is the person animating the prootype
  21. 21. Mature paper prototypes
  22. 22. Mature paper prototypes • For demonstration purposes, mature paper prototypes can also be animated using stop motion animation
  23. 23. However…
  24. 24. However… • This only makes sense if you have progressed from your idea’s personas into scenarios and user stories – Most likely you have actually address all this in previous activities but under different names or even implicitly • My recommendation is that you reframe what you have under this heading to better start this interaction design process
  25. 25. However… • This only makes sense if you have progressed from your idea’s personas into scenarios and user stories – If this is not so clear for you, please bear with me for a little longer
  26. 26. Personas • These are base on observation, interviews, research • They can be primary, secondary, etc… • Personas support design decisions – But should not entirely replace real users
  27. 27. Personas
  28. 28. Scenarios • Scenarios describe the context of the interaction between the personas and the envisioned product or service – These consist of goals, expectations, actions and reactions – They aim to reflect the real context and usage
  29. 29. Scenarios
  30. 30. User stories • User stories are written sequences of actions and events leading to an outcome – Good user stories are standalone, short and testable – They bring users, designers and developers together – Users stories are a powerful way to reflect upon user needs
  31. 31. User stories • Go more or less like this… – As a <ROLE>, I want to <DO SOMETHING> so that I could <GET SOMETHING> • User stories: – Describe one specific need – Are not to detailed – Are testable
  32. 32. User stories
  33. 33. User stories
  34. 34. Now it’s up to you to make it happen
  35. 35. paperprototypingateia .wordpress.com

×