6.3.1 Prototyping - Paper Prototype
At a Glance
Other names Paper Prototype · Low-Fidelity Prototype
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.
Common Use Case
You have multiple design directions for a key part of your product and you are not sure which one makes sense to users. Before investing in a digital prototype, you want fast, cheap feedback from real people. You put rough paper sketches in front of them and watch where they tap, hesitate, or get confused.
Helps Answer
- What basic shape might our solution take?
- Where do users get stuck or confused in our design?
- Is our product intuitive enough to use without instructions?
- Are there situations or errors we did not think of?
- What information do users need to complete a task?
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. It is the lowest-fidelity variant in Prototyping, the first round you run before building a clickable prototype.
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. 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. Keep the fidelity deliberately rough: a sketch is meant to invite change, while a finished mockup invites the user to defend or critique the visual treatment instead of the flow you came to test. If you would rather not draw by hand, an AI wireframe tool can draft the screens from a text description in minutes — but its default output looks polished enough to push users toward design feedback, so strip the fidelity back: turn off color, use placeholder copy, and tell the user up front that the visual treatment is not what you are testing.
How to
Prep
- 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.
- 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; polished sketches invite the wrong kind of feedback.
- Recruit five users who match your real target user. Five users per round is the working number — 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.
- 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.
- 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.
- 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.
Execution
- Lay out the screens. For each screen or interface state in the task, lay out the paper mockup illustrating what the user would see. For quick internal ideation, paper is faster than any digital tool — you can sketch, rearrange, and discard in real time with no overhead. For external sessions (especially remote ones), an AI-generated low-fidelity wireframe is easier to share and modify between sessions. In either case, keep fidelity deliberately rough: if users start commenting on visual polish rather than flow and structure, the prototype is over-engineered.
- Assign the user. One person (or a pair) plays the user attempting the task.
- Assign the “computer.” Another person (or several) plays the “computer” — the software simulator that swaps screens in response to each action.
- Run the task. The user interacts with the paper prototype as if it were a real application, physically tapping or pointing at the interface. Encourage them to explain their thinking aloud as much as possible.
- Swap screens silently. For each action the user takes, the computer moves or swaps the paper to reflect the new state. As a general rule, the computer does not talk. Breaking that rule is the most common way a paper-prototype session collapses into a tutorial.
- Observe and facilitate. For more formal sessions, observers watch for additional insights and capture notes. A facilitator may also be useful, prompting the user to think aloud without coaching them through the flow.
- Iterate on the spot. If a layout or interaction clearly is not working, mock up an alternate flow on the spot and re-run the same task. Paper is cheap, so iterating mid-session costs almost nothing.
Analysis
You are looking for places where the user 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 user 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 user’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 user might be noise; the same hesitation in three out of five is a defect. Trust what you saw on paper, and do not wait for a polished prototype to “really” test it.
- Confirmation bias A facilitator or observer who knows the design too well can drop “hints” that lead the user through the flow. Brief facilitators to stay neutral, read prompts as written, and respond to questions with “What would you expect?” rather than an answer.
- Social desirability bias Users may hide feedback when they are worried about appearing incompetent or offending the team. Reassure them up front that you are testing the design, not the person, and that confusion is data you need.
- Observer effect A user who knows they are being watched behaves more carefully and deliberately than they would in real use, masking the careless mistakes a real user would make. Keep the framing casual, ask them to work at normal speed, and treat unusually flawless runs with suspicion.
Learn more
Case Studies
Palm: PalmPilot wooden mock
The Computer History Museum documents Jeff Hawkins’s circa-1995 wooden block prototype with a chopstick stylus, used to test PalmPilot interactions by taking pretend notes in meetings before the device shipped in 1996.
TenTune: Pencil-iterated music app
A small music-product team used paper sketches and pencil iteration to settle on a core interaction model, discarding two early designs that tested poorly before writing any code.
IBM: Enterprise paper-prototype adoption
Among the first large firms to standardize paper prototyping in the mid-1990s; Carolyn Snyder’s book documents IBM-team work showing paper finds substantially the same usability problems as higher-fidelity prototypes.
Further reading
- Paper Prototyping — Carolyn Snyder, Morgan Kaufmann 2003
- Prototyping for Tiny Fingers — Marc Rettig, CACM 1994
- Sketching User Experiences — Bill Buxton, Morgan Kaufmann 2007
- The Design of Everyday Things — Don Norman, MIT Press 2013 rev. ed.
- PalmPilot wooden model — Computer History Museum
- NN/g: Paper Prototyping
Got something to add? Share with the community.
