Extremely cheap, suited to early structural exploration
Aliases: cheap paper prototypes · early structure exploration
What it is
A paper prototype simulates an interface with paper, pens, sticky notes, and swappable scraps. Its decisive advantage is not the hand-drawn look; it is that the marginal cost of a change is near zero—swap a card to change navigation, rearrange scraps to change hierarchy. That makes it fit early structural exploration, when grouping, task paths, and page responsibilities are still unstable. Rettig and Snyder placed it as a way to throw away a wrong structure before writing code, not as discount visual design.
Why it happens
Structural exploration needs high-throughput failure. Paper compresses “make a clickable version” from hours to minutes, so a team can afford to compare several information architectures side by side instead of stopping at the first demo-able scheme. Physical scraps also make structure something that can be pointed at and moved: a participant who relocates Settings from the tab bar into a list is making a structural claim, not a verbal suggestion. With no compile, alignment, or component-library constraint, implementation detail does not narrow the search early. The cheapness holds only for questions paper can express; once the question moves to timing, performance, or pixel control, the bargain vanishes.
Studying it
Early exploration often runs the same tasks through several paper structures and compares: can the task complete, can error paths recover, can participants say what a page is for. Outcomes are problem finds, path choices, and spontaneous rearrangements—not completion time, which handing paper contaminates. Snyder treats “can we revise and retest within an hour” as a sign the method is still in exploration. Photograph the desk before and after each rearrangement, or the discarded structures disappear into a verbal summary.
Where it stops holding
Low cost covers structure, copy skeleton, and coarse flow. Questions that need precise touch, motion, sound, or device sensors get false confidence from paper. Remote tests and large samples raise logistics until the cheapness disappears. Teams that treat paper as a deliverable to be “made pretty” can outspend a wireframe tool. For participants who do not read or who have visual impairments, simulating screen text on paper is itself unfair.
Applying it
- Give each sheet one structural hypothesis, with swappable nav bars and content blocks, rather than one poster-sized drawing.
- Run at least two mutually exclusive structures in the same session to force comparison.
- Cut and restick in the room; do not adjourn to “tidy it into a digital version and then test.”
- Carry only the structures that still stand into the next tool; photograph the rejected ones so they cannot return undocumented.