6.831 User Interface Design & Implementation
Fall 2004

GR3: Paper Prototyping

Due: Wednesday, October 20, 2004, in class

Building Day: Friday Oct 8, 4-6 pm, 32-G449
Testing Day: Thursday Oct 14, 4-6 pm, 32-G449

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 3 scenarios. These scenarios may be the scenarios you described in GR2; alternatively, you may want to choose different scenarios that explore the riskiest parts of your interface, which are the ones that will provide the most payoff from prototyping. You will test your paper prototypes on at least 3 users, who may be classmates or real target users.

There are two optional class meetings associated with this assignment (days and times shown above):

Building Day offers you an opportunity to start building your paper prototype. The course staff will be available to make suggestions, and some materials will be provided.
Testing Day offers you an opportunity to test your paper prototype on your classmates. Don't be late to this session if you intend to participate, because we need all the time. The 2-hour period will be divided into two 1-hour 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.

You can also build your prototypes outside of class and test them outside of class.

What to Prepare

Before testing your prototype, 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 test users (who may be 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 to run.
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. If you are working alone on your project, you should recruit someone to serve as your computer, while you act as an observer.
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 Users

When you run your prototype on a user, you should do the following things:

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.

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.

On Testing Day, 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. 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

You should hand in a hardcopy report with the following parts:

Prototype photos. 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. You must test at least 3 users. If you are unable to test this many on Testing Day, you will need to supplement by testing others later.