2. 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
3. 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
4. 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
5. 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
6. 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.
7. 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
8. 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
9. 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
12. 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
17. 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
18. Prototyping user stories
• Early prototypes normally evolve through a
sketching and structuring iterative process
19. 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
23. 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
24. 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
25. 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. 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. 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
30. 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
