6.893 User Interface Design & Implementation
Fall 2003
GR2: Paper Prototyping
Prototype Due: Wednesday, October 1, 2003, in class
Report Due: 12 Noon, Friday, October 3, 2003, by email to Rob &
Jaime
In this group assignment, you will do your first implementation of your
term
project, which will be a paper prototype. Your paper prototype
should be able to handle at least the 3 scenarios you described in your
task analysis. You will test your paper prototypes on your
classmates during an in-class prototyping session next Wednesday.
What to Prepare
Before Prototype Testing Day, you should:
- Build your prototype.
Draw the static background, menus, dialog boxes, and other
windows. Decide how to implement the dynamic parts of your
interface. Hand-sketching is
preferred.
- Prepare a briefing for test
users. This should be at most a page of information about
the purpose of your application and any background information about
the domain that may be needed by your classmates to understand
it. These are your notes for the briefing, so make them short,
simple and clear, not dense wordy paragraphs. This is not a
manual or quick-reference card. It should not describe how to use
the interface.
- Write your 3 scenario tasks on
separate index cards. Just write the concrete goal of the
task (e.g. "buy milk, tomatoes, and bread"). Don't write the
specific steps to follow, since that's for your users to figure
out. The tasks should be brief, roughly 5 minutes at most.
- Choose roles for your team
members.
One person must play the computer. The other team members (if
any)
will be observers. We won't bother with a facilitator for these
pilot tests. It may be useful for you to swap roles after every
user on Testing Day, so that each of you gets a chance to try each
role, but decide how you'll do it in advance.
- Practice running your paper
prototype. Every
team member should practice playing the computer, learning the
steps involved in making the prototype functional, such as rearranging
pieces and writing responses. It isn't important to be fast, just
competent and confident. A few trials are enough. Make sure
your prototype can handle the 3 scenario tasks you chose.
Testing Day
Next Wednesday, October 1, the class will meet in NE43-518 instead of the usual
location. Don't be late, because we need all the time. The
80-minute class period will be divided into two 40-minute halves, and
the projects will likewise be divided into two groups. During the
first half, each team in Group 1 will run their prototype as a team
while Group 2 people serve as users, individually. During the
second half, we'll switch, and Group 2 teams will run their prototypes
on Group 1 people.
When you are running your own group's prototype, you should do the
following things for each user:
- Brief the user. Use
the briefing you wrote up to describe orally the purpose of the
application and background information about the domain. Don't
waste too much time on this: 1 minute should be enough.
- Present
one task. Hand the index card to the user and let
them read it. Make sure they understand the task.
- Watch the user do the task.
Take notes from your observations.
- Repeat with the other tasks.
Run as many tasks on the user as you have time for. You'll get at
most 15 minutes with each user, so you'll be able to test at least 2
users. If you can't get to all your tasks with one user, start
the other user on untested tasks.
Bring extra materials on Testing Day.
Having extra blank Post-it notes, correction tape, and index cards on
hand will help you improvise if a user does something
unexpected, or help you make small fixes to your prototype between
users.
When you are serving as a user, you should:
- Relax and enjoy yourself.
You're not being tested -- the interface is. Part of the point of
this experience is to feel what it's like to be the user in a user
test, so that you can empathize with them.
- Be cooperative.
Don't be
intentionally dense, e.g. looking for Exit everywhere but the File
menu. If you see something you think is a usability problem, feel
free
to point it out to the observers (a la heuristic evaluation), but
remember that your current role isn't heuristic evaluator. Interact
with the interface as you would if you were really using it.
- Think aloud. Help
the observers understand what you're thinking by verbalizing your
thought process. "Let's see, I want to enter this bottle of milk,
so where's the scanner... oh, here it is. I'll scan the bottle
like this, oops that didn't work, let me find the bar code..."
You get the idea.
What to Hand In
By 12 noon next Friday,
October 3, you should hand in a report (electronically)
with the following parts:
- Prototype photos.
One or more digital photos of the pieces of your prototype. Try
to show the prototype in an interesting state, not just a blank
window. We'll be taking pictures of each
group's prototype during Testing Day, so if your group doesn't have
access to a digital camera, you can ask for the picture we took to
include in your report.
- Briefing. The
briefing you gave to users.
- Scenario tasks. The
tasks you gave to users, exactly as you wrote them on the cards.
- Observations.
Usability problems you discovered from the testing, and possible
solutions. Describe what users did, but don't record users' names.
Send your report in PDF or Postscript format by email to both Rob
Miller (rcm@mit.edu) and Jaime Teevan (teevan@ai.mit.edu).