COS 368 Graphical User Interface Design Prototyping

Paper Prototypes
•Useful. 
•Cheap and fast. 
•Start testing immediately.  
•"low-fidelity" prototypes
o do not necessarily look much like the final product
o have simulated functionality.

Paper - Represent home window, other windows.

Postits - Represent menus, dialog boxes, etc.
Transparencies - For changes to the home screen or other screen.  User can write on it.

Team of people to handle the prototype. 

• There is usually too much for one person to do.
• "facilitator" to interact with the user
• "computer" to simulate the computer    
• "scribe" to take notes (not necessarily in the same room). 
• entire team can be observing and having them all take notes has several advantages:
o you get more information
o keeps them from butting in on the test.  1
2
Why use paper, not computer prototype?
• Fast, cheap
• Users not as intimidated
• Developers not as committed. (No coding has been
done.)
• Participants see that the entire system is under
design.  (May be easier to get comments.)
• Participants not caught up in the look of the system. 
Paper allows imagination to work.
• Can create interface with computer drawing tools,
print color copies, and distribute.
• Allow iterative design by testing successive
prototypes.  Computer prototypes may require so
much time to build that it significantly reduces the
number of possible tests.
3
Programmer (implementer, us) comments (from
GUI Design for Dummies, page 97)
• "When I used paper all my attention was on design."
• "[Got] much better input than we've ever gotten
before."
• "Users grabbed it and started adding stuff."
• "No temptation to build programming on a paper
prototype.  [O]n the computer we tend to go on and
build further on the prototype."
• "We could afford to try out several different designs."

4
People who should be involved in the prototype
study. 
• It is important for everyone having design
responsibilities to be part of any testing.
• Designers
• Developers
• Graphics designers
• Manual writers
• Often it is useful to have other stakeholders
such as executives and marketing people to
show them how users react to the system.
(May be shown highlights later.)
5
Paper prototypes can often find many of the design flaws in a system,
but not all of them.
Situations conducive to using paper prototypes Early in the design
process.
• Screen layout is of high importance.  Low fidelity is not a problem
with deciding overall layout.
• Terminology is an issue.  Are buttons, labels, etc. phrased correctly
and do they use terminology familiar to the users?
• Functionality is an issue.  What can the system do and how do you
get it to do it?
• Navigation is an issue.  In this case you probably need a prototype
with a fair amount of breadth and depth so there are options that
users must decide between.
• Look and feel are of primary interest.
• Desire many prototypes to afford several runs through the design -
test - update cycle.
• There are issues that come up and the group spends much time
giving opinions of how to design something.  A simple prototype of
incorporating versions of the issue can give answers in less time
than arguing can and it helps get the entire team behind the
decision that was made. (Data trounces opinion.)
6
Situations not conducive to paper prototyping
• Need to test system response time. (Does computer get
the task done within 7 seconds?)
• Near to final delivery, low-fidelity may not be adequate.
• The system must be tested with a large amount of real
content.
• Testing to see if users notice small changes to a screen. 
With a paper prototype the "computer" explicitly
changes something thus drawing attention to the fact
that is has changed.
• Mouse click and keyboarding errors.  Paper does not use
a mouse or a keyboard.  The user points with a finger
and writes input into text boxes in a paper prototype. 
e.g. Clicking the wrong link or choice because they are
positioned to closely on the actual interface.  Mouse
problems due to small controls.
• Mouse vs. keyboard preference.  Can't tell which user's
prefer because they are always using their hands. 7
Internal walk throughs
Members of the design team and other
members of the product team try out the
system before it is tested by users. 
1.The first level of this is just a presentation of
the design to the larger group.  We will do this
in class.
2.A team member tries to use the prototype to
get some sort of job done. 

The job to be done is often specified in a scenario. 

e.g.  You must use the USM campus map to get
somewhere on campus.
8
Building a paper prototype
Again, this is a low-fidelity prototype.  Part of its usefulness derives from it comparative
crudeness. Materials needed (or useful) for running a user test and for building the
prototype :
•Fairly large piece of solid, glossy, usually white construction paper for the basic
window(s). 
•Removable tape (from Post-it) has glue on its entire back so it will not curl. 
•Restickable glue keeps items in place until you are ready to use them. 
•Small slips of paper that you will put onto the prototype in response to user
actions. 
•Transparencies.  These are very useful to put over your prototype so the user can
check check boxes and fill in text areas without ruining the only copy of the
prototype that you have. 
•Transparency pens and wet eraser.  The user may want to make changes to settings
in which case you need washable pens and a clean, wet eraser.  You will probably
use a new transparency for each user.
•Error correcting tape or Wite-Out.  Allow you to make small changes to the
prototype on the fly.  Labels and such are candidates for change.
•3" by 5" (or some such) cards. Useful for dialog boxes.
•Scissors to cut the various items to the right size.
•Pens or permanent markers for creating the basic windows of the prototype as well•
as dialog boxes, etc.
•Other?  Up to your imagination.
9
Computer Based Rapid Prototyping.
• Many "Visual" systems allow drag-and-drop of widgets to quickly build
interfaces.  Also, these are complete implementation languages allowing
you to build the entire system with them.  Such systems for Java 2 are
coming out now.
– Problem - May generate obscure, slow code that is difficult to change.
• Older interface tools for rapid prototyping.
– TCL/TK, etc.
• Many database systems include nice interface builders.  Often based on
Visual Basic.
• Problems with computer based prototypes
– There is still a lot of coding to do with any programming system. 
Programmers need more time to set it up and make changes than
with a paper prototype.
– The prototype can become the product.  Management sees the
prototype and thinks the product is about ready to ship.
– Computer and network failures during testing.  If the lights are on a
paper prototype will probably work. 10
Horizontal vs vertical prototypes
• Vertical - Allows a few jobs to be done in their entirety. 
Does not implement full functionality on the rest of the
system, in fact, there may be no elements of the rest of the
system visible in the prototype.
• Horizontal - Implement top layer of the interface, but not
implement full functionality of any part.

Must usually have some activity (as specific as possible) that

the prototype will allow the user to handle.  It may be for
horizontal prototypes the user would be asked to start
several different activities, but see none to completion. 
In a vertical prototype, perhaps only one activity could be
initiated, but it could be taken to completion.
Commonly a combination of horizontal and vertical is used. 
The entire top level is shown but only a limited number of
the options really work.
11
 Functionality of electronic prototypes.
Electronic prototypes must have some
functionality.  It is not enough for the user to
see what the interface will look like.  The
prototype must support some meaningful
interaction.  Sometimes the prototype is a
shell with a person connected to it who
performs the database lookup or whatever
and makes it appear that the prototype is
doing it.  This is called "Wizard of Oz" testing.

12
 Advantages of others designing before we program

• Design is more complete before code is written.  This

makes it less likely that code will be thrown away.
• The programmer is responsible for implementing the
interface, this is what programmers are good at. 
Programmers are not responsible for design of the
interface.  Programmers in general have no
background in interface design.
• The people doing the design may come up with really
interesting designs that can be very rewarding to
implement.  They are often designs that a
programmer would never think of.  Creating a
working system from a challenging design can give
the programmer a lot of satisfaction.

13