GR3: Paper Prototyping

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 encouraged. You don't have to prepare every possible screen in advance; it may be much easier to write responses on the fly.

• 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. These are your notes for the briefing, so make them short, simple and clear, and not dense, wordy paragraphs. This is not a manual or quick-reference card. It should not describe how to use the interface.

• Write your scenario tasks on separate index cards.

  Your scenario should have involved at least three tasks. You should write these tasks down to give to your users. Just write the concrete goal(s) 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 will be observers. It's not necessary to have a facilitator for these pilot tests. It may be useful for you to swap roles after every user on during the testing sessions, 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 tasks involved in your scenario.

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, keeping an eye out for critical incidents.

• Repeat with the other tasks.

  Run as many tasks on the user as you have time for.

Bring extra materials to your testing sessions. 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.

During the testing sessions, 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 users in a user test, so that you can empathize with them.

• Be cooperative.

  Don't be intentionally stubborn, 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.

Google Doc Project Report. Under the section "GR3 Paper Prototyping" add the following sections:

• Images of your prototype.

  Digital photos/images of the pieces of your prototype. Show the prototype in interesting states; don't just show a blank window. Although you will iterate your paper prototype during this assignment, the photos only need to show one iteration. Ensure the quality of these photos is high enough so that you can actually see the features of your paper prototype! Smartphone images are often not high enough quality/blurry/too small. You can produce high quality images by scanning your prototype using the scanners in the Barker or Hayden library.

• Briefing.

  The briefing you gave to users.

• Scenario Tasks.

  The tasks you gave to users, as you wrote them on the cards.

• Observations.

  Usability problems you discovered from the testing. Describe critical incidents encountered by the users, but don't record users' names. Record these as a series of high-level takeaways, focusing on the usability problems you saw, rather than what each participant did. For instance, you might describe how you had some learnability issues with your prototype, as evidenced by users B and C clicking all of the menus to try to find option X.

• Prototype iteration.

  You did multiple rounds of paper prototyping. Please state the number of iterations you did, the outcome of each iteration, and the number of users tested in each iteration. Describe how your prototype changed between those two rounds.

• Studio Reflection. Describe the feedback you got in your studio sessions, and how you will incorporate it into your project.

Studio presentation. You must prepare a Google Slides slideshow to present this work in studio. Use this template presentation as a guide. Send the link to your mentor by 12pm (noon) on Friday. Also bring your physical prototype(s) to studio to show the class. Take notes during the discussion of your presentation and put the important ones in your report.

Self-assessment form. Complete your individual self-assessment forms by the deadline.