Paper Prototype¶
Artifact — instantiates Rapid Prototype Learning Loop
A paper-based representation of screens, forms, steps, or objects that can be manipulated during a test.
A paper prototype is a set of hand-drawn screens, forms, or steps that a real person operates during a moderated session while a facilitator "plays computer" — swapping sheets by hand as the user taps and points. Its defining move is that the artifact exists to be manipulated, not admired: the learning is behavioral, drawn from watching a live user drive a flow. Where a static artifact tells you whether a design looks right, a paper prototype tells you whether someone can actually get through it — where they hesitate, tap the wrong thing, or can't find the next step. It is the cheapest possible interactive flow test, and because the "computer" is a human with a stack of paper, a broken step can be redrawn on the spot.
Example¶
A public library is replacing the touchscreen interface on its self-checkout kiosks. Before a line of code is written, a designer draws each kiosk screen on a separate sheet: scan-an-item, member-card prompt, an overdue-fines warning, and receipt options. A patron is invited to a table; the facilitator lays down the "home" sheet and says, "check out these two books." When the patron taps a paper button, the facilitator swaps in the next sheet by hand, saying nothing.
The signals arrive fast. Three patrons in a row try to scan a book before pressing "start," because nothing tells them to press it first. Everyone sails past the "email receipt" toggle — it looks like a label, not a control. Watching a fourth patron stall at the fines warning, the team decides on the spot to add a numbered "1. Scan 2. Confirm" banner and to redraw the toggle as an obvious button. They test the redrawn sheets with the next patron that afternoon. Two flow failures found and one fix confirmed, all before development began.
How it works¶
- Build hand-swappable pieces. Each screen or step is a separate sheet (with loose elements — dropdowns, dialogs — as movable scraps) so the facilitator can assemble any state instantly.
- Run a moderated session. A real user is given a real task in a defined scenario; the user drives, and a human silently simulates the system by presenting the right sheet in response to each action. This staged session is the test context.
- Read behavior as the signal. Hesitation, wrong taps, missed controls, and dead-ends are the evidence — observed navigation, not stated opinion.
- Revise in the room. Friction seen in a session is converted immediately into a redrawn sheet, so the next participant tests the improved flow.
This is what separates it from a Clickable Prototype: there, the interaction is digital and the user self-navigates; here, a human is the runtime and revision costs a pen stroke.
Tuning parameters¶
- Moderation style — think-aloud vs. silent observation; talking aloud surfaces reasoning but can change behavior.
- How strictly the human "plays computer" — a rigidly mechanical facilitator exposes gaps a helpful one would paper over.
- Screen granularity — one sheet per state vs. composable scraps; finer pieces test more transitions but take longer to run.
- Iteration cadence — revise live between participants vs. batch changes after a full round; live iteration learns faster but muddies comparison across users.
When it helps, and when it misleads¶
Its strength is finding flow, sequence, and labeling failures for almost nothing, early enough that fixing them is trivial — and the visible crudeness gives users permission to criticize, because clearly nothing is finished.
Its failure modes are the limits of paper. It cannot test timing, real input latency, live data, performance, or anything that depends on the system responding at speed; a helpful human "computer" can silently rescue a user past a gap that a real, literal system would expose; and a handful of moderated sessions is a small, non-random sample that is easy to over-generalize. The guarding discipline is to keep the facilitator strictly mechanical, hold think-aloud loosely, and treat findings as flow hypotheses to confirm at higher fidelity — not proof of usability at scale. The technique's discipline was codified in Carolyn Snyder's Paper Prototyping (2003), which is largely a manual for running these sessions without contaminating them.[1]
How it implements the components¶
test_context— the moderated session is the context: who sits down, the task scenario they're given, and the facilitator acting as the system.feedback_signal— observed navigation behavior (hesitation, mistaps, missed elements) is the watched evidence, tied directly to the flow hypothesis.revision_decision— friction seen in-session drives an immediate flow revision, redrawn and re-tested within the same round.
It does not implement prototype_fidelity or participant_or_stakeholder_sample in the Mockup's sense — the paper prototype stays deliberately crude and reads behavior, not stakeholder opinion on the look; the mockup is presented, this is operated. Nor does it frame the question, risky_assumption and design_hypothesis — that is the Sketch's upstream role.
Related¶
- Instantiates: Rapid Prototype Learning Loop — the paper prototype is the loop's cheapest interactive test of a flow.
- Consumes: Sketch supplies the framed assumption and hypothesis the session is built to test.
- Sibling mechanisms: Sketch · Mockup · Rough Physical Model · Clickable Prototype · Service Walkthrough · Small-Scale Pilot · Wizard-of-Oz Test
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Paper Prototype operates as an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation because it a paper-based representation of screens, forms, steps, or objects that can be manipulated during a test.
Independent corroboration: The frozen evidence defines Paper Prototype as 'A paper-based representation of screens, forms, steps, or objects that can be manipulated during a test', so its operative form is Experiment, Test & Rehearsal.
Nearest alternative: Representation, Specification & Plan — Paper Prototype includes features of a static representation, map, specification, schema, or prospective plan that externalizes information, but its defining operation is an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Paper Prototype is most directly rooted in human-computer interaction's user-centered traditions of interface design, contextual inquiry, prototyping, and accessibility. The lineage fits its defining practice: A paper-based representation of screens, forms, steps, or objects that can be manipulated during a test.
Related originating lineages:
- Engineering & Design — Paper Prototype also draws materially on engineering and design's traditions of specification, testing, reliability, control, and physical-system construction, which shaped this mechanism rather than merely adopting it as an application.
Review outcome: Independent reviewer agreement; high confidence.
References¶
[1] Carolyn Snyder, Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces (2003) — the standard practitioner reference, most of which concerns how to moderate a session (task framing, the facilitator-as-computer role, avoiding leading the user) so that the observed behavior is trustworthy. registry ↩