Notes on Paper Prototyping
See online eBook Morgan/Kaufmann - Paper Prototyping
What is Paper Prototyping?
Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person ‘playing computer,’ who doesn’t explain how the interface is intended to work. If you have ideas for your interface and can draw them – rough sketches will do – then you can create a paper prototype.
Paper prototypes are often sufficiently realistic that they encourage test participants to extrapolate to real-world situations of use. Thus, they can uncover issues beyond the user interface.
Paper prototyping overlaps with usability testing, but the two concepts are not quite the same. It’s possible to conduct usability tests on real interfaces, not just paper prototypes. And paper prototypes can be used for purposes other than usability testing – some product teams find them helpful in generating design ideas and conducting internal interface reviews.
The goal is to determine:
- general usability issues: confusing concepts, poor terminology, layout problems, lack of feedback
- which features users need, and why
- missing (or misspecificed) functional requirements: find needs that the development team isn't aware of
- find preferences in design alternatives
- separate the gotta-haves from the nice-to-haves
- which functionality interfers with usability and can be dropped
- discover social issues in online training
A Paper Prototyping Project
- Kickoff Meeting: discuss goals, agree on user profile, determine team, set schedule - time: 2-4 hours
- User Recruitement: find people who match profile and schedule test - lead time: 1-2 week(s)
- Task Design: create the tasks to be implemented - time: 4 hours - 4-8 hours
- Interface Elements: list interface elements that are needed to support the task - time: 1 day
- Prototype Creation: create walkthroughs for each task, perform formal run-through without users - time: 1-4 days
- Usability Testing: perform usability tests with users - time: 1-2 days
- Iterative Refinement: list issues and revise prototype - time: 1-2 days
- Action Plan: track issues, discuss solutions, solve and adress problems - time: 4 hours
- Communication: summarize top-10 issues, write report, create an interface spec - time: 1 day
Pros and Cons
There are many advantages to paper prototyping:
- Fast way to mock up an interface — no coding required
- Finds a wide variety of problems in an interface, including many of the serious ones
- Allows an interface to be refined based on user feedback before implementation begins
- A multidisciplinary team can participate
- Encourages creativity from the product team and users alike
On the other hand, paper prototyping:
- Doesn't produce any code
- Does not find all classes of problems with an interface
- Can affect the way users interact with the interface
- Makes some development teams nervous because they fear users will think it unprofessional
The main difference in paper prototype testing is the addition of the human Computer, who manipulates the paper interface pieces to mimic the behavior of the system. Users are instructed to "click" (touch) buttons or links, and "type" (handwrite) data directly onto the prototype. The Computer responds to those actions as the system would. The Computer does not explain the interface (most machines can't talk), so it's up to the users to figure out how to accomplish their tasks.
Being the Computer does not require any special training, though this role should be played by someone who understands how the interface behaves. Typically, the Computer is one of the lead developers, though technical writers, marketers, training specialists, and customer support reps may also have sufficient knowledge of the product to play this role. Some teams find it helpful to have a second person as a Co-processor. Regardless of who is Computer, they should practice the tasks a few times before the first usability test.
Tools and Preparation
- White Posterboard - fixed background for other elements
- Blank Paper - lots of it
- Smaller Index Cards - for dialogs, popups, drop-down menus
- Markers/Pens - needs to be thick enough, colors are good
- Removable Tape - to simulate dialogs, quick fixes
- Scissors - to cut screenshots into pieces
- Invisible Tape - to assemble elements
- Overheads and Pens - simulate text entry, get wet-rease pens
- Correction Fluid - for quick fixes
- draw a browser background (for web applications) on the posterboard
- identify possible dialogs, learn how to simulate them using paper
- create a user profile with 4-6 characteristics
- target testing using 5-8 users
- schedule at most 4 hours of test per day
Tasks need to:
- have Appropriate Scope (i.e. can be completed in minutes with paper prototype)
- have a Finite and Predictable Set of Possible Solutions (maybe limit possibilities)
- have a Clear End Point (avoid exploratory tasks, users decide whe the task is finished)
- Elicit Action, Not Just Opinion (users need to USE the interface, not look at it)
- Use Task Template to create tasks.
- Create enough tasks for the test length minus 10-20 minutes.
- Multiply expert time by a factor 5-10 for time estimation.
- Describe goals of task for user instructions.
- List paper prototype elements needed to complete task
- Use realistic data
- limit time, not creativity when designing
- neatness and size doesn't count much, monochrome is OK
- keep elements organized (folder, envelopes, etc)
- do an internal walkthrough within the team as early as possible
The Actual Test
- a facilitator (who can be also the observer)
- a "Computer" (needs in depth knowledge how the interface behaves)
- a user (signs a NDA where appropriate)
Follow up with a debriefing meeting summarizing observer top observations.