Paper Prototype Testing

Purpose

Test concepts using hand-drawn or printed paper screens manipulated by a human “computer” who swaps screens in response to user actions, enabling concept exposure and iteration at near-zero cost and within minutes rather than hours.

When to Use

Use paper prototype testing when:

• Maximum iteration speed is needed (redesign between sessions—literally redraw a screen in minutes)
• Budget is extremely limited (no prototyping tool licences, no designer available)
• Concepts are simple enough to represent as individual screens with clear state transitions
• The team wants to test multiple design alternatives within a single session (swap in a different paper version mid-session)
• Very early stage: exploring whether the core interaction logic works before investing in any digital artefact

Do NOT use when:

• The concept involves complex transitions, animations, or scrolling that paper cannot represent —use clickable digital prototypes instead
• Users need to type, search, or interact with dynamic content (paper can't simulate input effectively)
• Remote testing is required (paper prototyping requires physical co-presence or a document camera setup)
• Stakeholders will not take paper artefacts seriously enough to fund testing (rare, but some corporate cultures resist)

Sample Size and Duration

Preparation: 30–60 minutes per concept (faster than any digital prototyping method)

Per session: 45–60 minutes

Between-session iteration: 5–15 minutes

Participants: 5–8 per concept

Expected output: Behavioural data + 2–4 iterations of the paper prototype within a single testing round

Prerequisites

• Concept sketches or wireframes from A2.2 (used as basis for paper screens)
• Paper, card stock, scissors, markers, sticky notes
• Three roles: Facilitator (runs session), Computer (manipulates paper), Observer (takes notes)
• Task scenarios (from A2.3 Step~1 research plan)
• Participants matching target user profile
• 45–60 minutes per session

Complete Procedure

Step 1: Prepare Paper Screens (30–60 minutes per concept)

1. Draw or print each screen on a separate piece of paper or card stock (A4 or letter size)
2. Create “overlays” for interactive elements: drop-down menus on separate strips, modal dialogs on separate cards, form-field entries on sticky notes
3. Prepare state-change screens: “before” and “after” versions of screens that change in response to user actions (e.g. “empty dashboard” vs. “dashboard with data loaded”)
4. Number or label each screen for the Computer's reference (“Screen 3B—after clicking Save”)
5. Create a “screen map” for the Computer: a flowchart showing which screen to present in response to each user action

Step 2: Assign Roles

1. Facilitator: Runs the session—introduces the task, manages think-aloud, asks follow-up questions. Does not touch the paper.
2. Computer: Sits beside the prototype and swaps screens in response to user actions. Does not speak except to say “processing…” when swapping screens (maintains illusion of a system responding). The Computer must be rehearsed on the screen map.
3. Observer: Takes notes on user behaviour, think-aloud narration, errors, and timing. Does not interact with the user.

Step 3: Conduct Session (35–45 minutes)

1. Facilitator introduces: “This is an early concept made of paper. Pretend it's a real screen on a device. Point to what you would tap or click, and tell me what you're thinking.”
2. User points to interface elements; Computer swaps to the appropriate next screen
3. If user points to an element with no prepared response, Computer says “That feature isn't available in this version” (note this as a gap for iteration)
4. Facilitator prompts think-aloud: “What are you looking for?” “What do you expect to happen?”
5. After tasks: post-task interview (same protocol as think-aloud method, the referenced method Step~3)

Step 4: Iterate Between Sessions (5–15 minutes)

1. Immediately after each session, the team reviews notes: what worked? What confused the user?
2. Redraw or modify paper screens to fix obvious issues (the core advantage of paper: iteration in minutes)
3. Test the revised version with the next participant
4. Document which version each participant saw (for analysis: pre-fix vs. post-fix)

Quality Criteria

1. All critical screens prepared (happy path + 1–2 error states)
2. Screen map documented and rehearsed by Computer
3. Roles clearly assigned (Facilitator, Computer, Observer)
4. ≥5 participants per concept
5. Between-session iterations documented (which version each participant saw)
6. Think-aloud and behavioural data captured per session

Theoretical Foundation

Seminal references:

• : Comprehensive guide establishing that paper prototypes produce comparable usability findings to digital prototypes for early-stage concept evaluation. Key insight: users engage with paper prototypes as seriously as digital ones when the facilitator maintains immersion (“pretend this is a real screen”).
• : Seminal practitioner article demonstrating paper prototyping in industrial practice, with evidence that paper-based iterations can be completed in minutes (redraw a screen) vs. hours (rebuild a digital prototype).

Contemporary references:

• : Positioned paper prototyping within the broader philosophy of sketching as thinking: the roughness of paper artefacts signals ambiguity, inviting critique that polished artefacts suppress.
• : Clarified that paper prototypes primarily test the “looks like” and “behaves like” roles of a concept —not the “works like” role. This is appropriate for A2.3, where desirability and usability (not technical performance) are the selection criteria.

Challenges and Solutions

Challenge 1: Users Don't Take It Seriously

• Symptoms: Laughter, “This is just paper,” superficial engagement
• Solution: The Facilitator's tone sets credibility. Maintain professional framing: “We find that testing at this stage gives us the most honest feedback before we invest in building anything.” Most users engage seriously within 60 seconds once tasks begin.

Challenge 2: Computer Can't Keep Up

• Symptoms: Long pauses while Computer searches for the right screen; immersion breaks
• Solution: Rehearse. The Computer must practise the screen map 2–3 times before the first session. Organise screens in a logical stack or spread on a hidden surface beside the Computer.

Challenge 3: Complex Interactions

• Symptoms: Scrolling, typing, drag-and-drop cannot be represented
• Solution: For scrolling: use a long strip of paper pulled upward through a “window” frame. For typing: user speaks input, Computer writes it on a sticky note and places it in the field. For drag-and-drop: user points to source and target, Computer moves a paper element. If the interaction is too complex for these workarounds, upgrade to a clickable digital prototype.

Relationship to Other Methods

Paper Prototype Testing receives input from:

• A2.2 sketches or wireframes (basis for paper screens)

Paper Prototype Testing complements:

• Think-Aloud Testing (the referenced method): Paper prototyping is the artefact; think-aloud is the observation method used during the session
• Comparative Preference Testing (the referenced method): Multiple paper prototypes can be compared within a single session (swap in a different paper version)

Paper Prototype Testing provides output to:

• A2.3 Step~4 analysis (behavioural data, iteration log)
• A2.4 Concept Specification (validated interaction logic)

Tools and Templates

• Paper or card stock (A4/letter), markers, scissors, sticky notes, tape
• “Window frame”: a cardboard cutout matching screen dimensions (optional—helps users focus)
• Screen map template (flowchart for the Computer)
• Document camera (for remote paper prototyping via video call)

• B. Buxton (2007). Sketching User Experiences: Getting the Design Right and the Right Design. Morgan Kaufmann.
• C. Snyder (2003). Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann.
• M. Rettig (1994). Prototyping for Tiny Fingers. Communications of the ACM. 37(4). pp. 21–27.
• S. Houde & C. Hill (1997). What Do Prototypes Prototype?. In Handbook of Human-Computer Interaction. North-Holland.