6.813/6.831 — User Interface Design & Implementation
Spring 2018

GR3: Paper Prototyping

Presentation & draft report due in studio on Friday, March 23, 2018.
Final report and self-assessment (one per group member) due 11:59 pm on Sunday, April 1, 2018. We will be checking for your self-assessments as part of your grade.

Prototype Building Session: In studio on Friday, March 16, 2018.
Prototype Testing: During class on Monday, March 19 and Wednesday, March 21, 2018.

In this group assignment, you will do your first implementation of your term project, as a paper prototype.

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

  • The building session offers you an opportunity to start building a paper prototype. The course staff will be available to make suggestions, and some materials will be provided.

  • The testing session will allow you to test a paper prototype on your classmates. For part of the time, you will also serve as a user for somebody else's paper prototype.

You should do at least two rounds of testing, each round involving at least three users. After the first round, you will revise your paper prototype to address the critical usability problems that arose and explore possible design alternatives. Aim to complete one round each class. If you don't manage to complete the second round with your revised prototype in class, you will have to find users outside of class to complete the assignment.

Preparing for Testing

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.

Running the Tests

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.

Serving as a User for Your Classmates

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.

Deliverables

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.