This document discusses different types of prototypes that can be used during product development. It describes paper prototypes as being easy, fast and cheap to produce. Functional prototypes implement some or all features to test functionality but cut costs by reducing features, functionality or resources. Simulation mimics a product's actual user interface while emulation imitates functions on different hardware. The document advises that after testing, prototypes should be discarded rather than having their code used in the final product.
2. General Information
Prototyping is commonly used as a part
of user-centered design paradigms
Prototyping was introduced during
1980s
Prototyping has a strong position in
Contextual Design method
3. General Information
What is a prototype?
Looks like a finished product?
Behaves like a finished product?
May have small faults or missing
functionalities?
Prototypes can be used in many ways
To try out new features of an application
Test a complete family of applications
4. Prototyping vs. Traditional
methods
According to some sources prototyping
does not fit very well in ’waterfall’
design paradigm
results of intermediate phases are not
suitable for prototyping
In waterfall model it is expensive to go
back a step (e.g. from implementation
back to design)
5. Prototyping vs. Traditional
methods
An experienced usability expert will be
able to see some of the usability issues
from the documentation
This kind of practice is, however,
inadequate
Many usability issues will not be found
One solution is to separate UI design to
an independent subproject
6. Prototyping vs. Traditional
methods
Especially important is to use
prototyping, when new product
concepts are introduced
Prototypes can also be used as a means
of communication between project units
Often parts of requirements spesification
are intepreted in different ways
Prototypes are useful for completing formal
spesifications
7. Functional Prototypes
Functional protoype is essentially a
product with fully implemented
functionalities
The goal is still to keep the costs lower
than those of a finished product
There are basically three ways to cut
the expenses
8. Functional Prototypes
1. Cut down the product features
only part of all features are implemented
the implemented features are fully
functional
2. Cut down the functionalities
all features are implemented
some functionalities are missing
9. Functional Prototypes
3. Cut down resources used in
implementation
Memory optimization is not implemented
Efficency is not maximized
Very effective computers are used during
testing to make up missing efficency
Error hanling is not fully implemented
10. Functional Prototypes
Often mixtures of aforementioned
methods are used to cut down the costs
of developing a prototype
11. Paper Prototypes
In some cases it is practical to use
paper prototypes instead of functional
ones
E.g. Contextual Design stresses use of
paper prototypes
Piece of paper is used to represent UI
A member of usability staff arranges the
UI according to user’s actions
12. Paper Prototypes
Changes to the UI can be illustrated by
Using Post-it labels
Drawing to the paper
Using various pieces of paper
The person responsible for arranging
the UI must know the underlying
system well
13. Paper Prototypes
E.g. heuristic evaluation methods can
be used
We will go into heuristics later in the
course
Use of paper prototypes is not
restricted to just desktop applications
Wood block => mobile device
Cardbroad box => laptop computer
Pencil => bar code reader
14. Paper Prototypes
Various software tools can be used to
sketch the contents of paper
prototypes, e.g.
Visual Basic for the UI views
Flash for mobile device emulations
It may be psychologically easier for the
test person to suggest changes to a
ballpark drawing
15. Paper Prototypes
Compared to functional prototypes,
paper prototypes are easier, faster and
cheaper to produce
Several degrees of accuracy can be
used during iterative cycles
16. Wizard of Oz
Wizard of Oz is a spesific technique of
prototyping
Used to test and demonstrate technically
’impossible’ features
E.g. speech recognizing text editor in
1970s
User believes he/she is using a
computer-based system
17. Wizard of Oz
In reality user’s actions are transmitted
to a person, who processes actions and
forms the feedback of the system
Because of that, the response times can
be quite long
User can be told, that advanced processes
are time-comsuming
Several ’wizards’ can be used to speed up
system’s actions
18. Emulation Techniques
Emulation = imitating a product’s
functions using another product
E.g. mobile devices can be emulated
using desktop computers
More processing power, thus no need for
code optimization
Ability to test device’s UI before hardware
examples are manufactured
19. Emulation Techniques
Emulator’s do not transmit a truthful
image of a product, e.g.
no physical buttons of the actual device
different display format
20. Simulation Techniques
Simulations are used to mimic a device
by using another kind of technical
enviroment
E.g. flight simulators used for pilot
training
The difference between simulation and
emulation is, that simulation utilizes the
actual UI of a device
21. Simulation Techniques
Simulation can be used during early
design phases of a product, e.g.
Model can be made of wood or plastic
The hardware buttons are included in the
model
Buttons are wired to a computer system,
which gives feedback according to the
user’s actions
22. Simulation Techniques
Simulations are effective means of
marketing a product
localization
testing the physical adequacy of the
product
Simulations are generally more
expensive than other forms of
prototyping
23. Manuscripts
A manuscript (like in a case of a movie)
can be written of a product
Manuscript will represent a spesific
task, which is completed by using the
product
The goal is to demonstrate the product
in daily use and advantages of using
the product
24. Manuscripts
Suitable formats of manuscripts are
animations
comic strips
theater plays
etc.
Manuscripts are not to be used as
testing methods
Instead they are good for
demonstrating a product to a large
audience
25. After Prototype Has Been
Used
Usually the best choice is to throw the
prototype away
It is meant to be used as a sketch
There are many real-world examples of
failures, when code parts of prototypes
have been used in products
26. After Prototype Has Been
Used
Prototypes, which ’look too good’ can
be potentially dangerous:
Customer may think, that the product is
almost finished
Management is not willing to throw ’almost
finished’ parts of prototype away
One way of avoiding prototype’s code
to be used is to implement prototype
with a language unsuitable for for the
product