Paper Prototyping

In Brief

Paper prototyping is a low-fidelity usability test where you draw screens or interface elements on paper and have a real user interact with them as if they were a working product. One person acts as the user while another swaps paper screens in response to each action, simulating the product’s behavior. The output is direct observation of where users get confused, stuck, or surprised — giving you design feedback in minutes without writing any code.

Description

Paper prototyping is a low-fidelity usability test where hand-drawn screens stand in for a working interface. A real user attempts a real task, tapping or pointing at the paper. A second person — the “computer” — swaps screens or moves cutouts in response to each action, simulating how the product would behave. A facilitator coaches the user to think aloud; one or more observers take notes. The technique is documented end-to-end by Carolyn Snyder in Paper Prototyping — Carolyn Snyder, Morgan Kaufmann 2003, which traces the method back to Wizard-of-Oz studies in human–computer interaction.

Use paper prototyping when the questions you have are about flow and structure: does the user understand what to do next, do they look in the right place for a function, do they recognize the labels you chose. The empirical case for using paper at all comes from Marc Rettig’s Prototyping for Tiny Fingers — Marc Rettig, CACM 1994, which argued — and was later widely confirmed — that low-fidelity paper sessions surface substantially the same usability defects as code-based prototypes, at a fraction of the cost. Paper is the wrong tool when the question is about visual placement, scroll behavior, animation, micro-interactions, or anything keyboard- and pointer-specific. For those, you need a clickable prototype or the real thing. Bill Buxton’s Sketching User Experiences — Bill Buxton, Morgan Kaufmann 2007 makes the same point from the design side: a sketch is meant to invite change, a finished mockup is meant to defend a decision, and confusing the two costs you the feedback you came for.

AI wireframe tools — v0, Figma AI, Galileo and similar — can collapse the prep cost of a “paper” prototype to a few minutes. The trade-off is that their default output looks polished enough to push testers into design feedback (color, typography, layout opinion) instead of flow feedback (where they got stuck, what they expected to happen). If you go that route, deliberately strip the fidelity back: turn off color, replace real copy with placeholder text, and tell the participant up front that the visual treatment is not the subject of the test.

How to

Prep AI Prompt

1. Define the task. Write the user task you are testing in one sentence — for example, “A first-time user signs up and creates their first project.” If you cannot state it in one sentence, you are testing too many things at once.
2. Sketch the happy path, then the branches. Draw the screens a user sees when they complete the task without trouble. Then add screens for the most likely error or branch states (validation failure, empty state, “not found”). Keep the fidelity deliberately rough; per Buxton, polished sketches invite the wrong kind of feedback.
3. Recruit five testers who match your real user. Snyder’s working number is five participants per round — beyond that, new defects arrive slowly. The catch is selection bias: five people who already understand your domain will not surface the issues a real beginner would. Recruit against the actual target user, not your network.
4. Assign roles before the session. Decide in advance who plays the “computer” (swaps screens, never speaks), who facilitates (prompts the user to think aloud, stays neutral on the design), and who observes (takes notes, watches body language). Mixing these roles mid-session is how facilitators accidentally lead the user.
5. Pilot once internally. Run the full script on a teammate who has not seen the screens. You are looking for missing screens, ambiguous prompts, and any place the “computer” has to improvise — those are the screens you forgot to draw.
6. Decide how you will capture data. Pick one of: a written defect log per session, a photo of every screen state the user reached, or a recorded screen of a tappable digital version. You only need one — pick before you start.

Analysis AI Prompt

You are looking for places where the customer got stuck, could not find what they were looking for, or accidentally went down the wrong path. Anything misleading, confusing, or hard to find is noteworthy. For each, dig into what information the customer was missing that led to the confusion and how that information could be provided — or how the need for it could be eliminated. Watch for situations where the response by the “computer” was not defined, or where an action was possible that you did not want to be possible. Also revisit assumptions about the customer’s motivations and the knowledge or experience base they bring; the test will often expose assumptions that did not hold and suggest ways to improve the solution.

Cluster the friction observations across all five sessions before deciding what to change. A single confused tester might be noise; the same hesitation in three out of five is a defect. Rettig’s original argument was specifically that low-fidelity sessions catch substantially the same defects as high-fidelity ones — so trust what you saw, and do not wait for a polished prototype to “really” test it.