You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Group Members 

  • Stephen Suen ssuen
  • Kathy Fang kfang 
  • Yi Wu wuyi
  • Connie Huang connieh
  • TA: Katrina Panovich

GR1 - User and Task Analysis

GR2 - Designs

GR3 - Paper Prototyping

GR4 - Computer Prototyping

GR5 - Implementation

GR6 - User Testing


GR3 - Paper Prototyping

You must do at least two rounds of testing, with a revision of your paper prototype in between. Each round must involve at least 3 users. Note that if you don't have time to run 3 users during the in-class testing sessions, you will have find users outside of class as well. After the first round, revise your paper prototype to address the critical usability problems and explore possible design alternatives, then run 3 more users.

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 (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 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.

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 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.

Prototype PhotosDigital photos 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.

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 two rounds of paper prototyping. Describe how your prototype changed between those two rounds.

  • No labels