SM Small Proof Studio
Prototype Workshop

Build and Test a Paper Prototype

Small Proof Studio · Updated 2026-07-19 · 4 min read
Build and Test a Paper Prototype
In shortBuild a paper prototype around one task and learning question. Draw only the screens and states needed, using movable cards for menus, dialogs, errors, and confirmations. One facilitator gives the scenario while another person acts as the system, changing paper after each action. Use fictional data, readable labels, and safe cutting and adhesive practices. Record choices, hesitation, errors, workarounds, and completion without teaching. Separate observation from interpretation, revise one variable, and test again. Move to interactive tools when timing, input, accessibility, or system behavior becomes the question.
Contents

Build only enough interface to test one risky flow

Build a paper prototype by choosing one task, drawing the minimum screens or states needed to complete it, and preparing movable controls, overlays, and a test script. One facilitator acts as the system, swapping paper when the participant points or “clicks.” Observe without teaching, then revise the paper rather than defending it.

Paper is especially useful before visual polish or code makes a weak flow expensive to question. It cannot test load time, real accessibility behavior, device input, data integrity, or technical feasibility. A rectangle drawn around the word “magic” remains admirably low fidelity.

Choose the test question and stopping point

Write one scenario and one learning question. For example: Can a first-time user find the correct order and change its delivery address? Define success as observable behavior, not “likes the concept.”

Limit the path to the starting state, key decisions, error or empty state where relevant, and completion. Do not draw the full product. Use neutral fictional data that resembles the real structure without exposing personal, client, regulated, or confidential information.

Recruit participants with relevant experience and explain the purpose, time, note-taking, recording, privacy, compensation, and right to stop. A paper interface may be informal; research consent should not be.

Browse prototype workshop for more small-proof formats.

Use simple, safe materials

Useful materials include plain paper or index cards, removable notes, markers with readable contrast, transparent sleeves, tape, reusable adhesive, and a backing board. Create separate pieces for menus, dialog boxes, keyboards, notifications, and error messages so the “system” can respond.

Use scissors or craft knives only on a stable protected surface, away from the participant area, and according to tool instructions. Cut away from hands and bodies, store blades securely, and provide age-appropriate supervision. Use adhesives and markers with ventilation and surface protection as their labels require.

Rounded corners are optional. Keeping blood off the onboarding flow is not.

Make every state legible

Write large enough for the participant and observer to read. Use consistent control names and obvious state changes. Include a back path, cancel path, loading or confirmation state where it affects the task, and an error response instead of allowing every action to succeed.

Do not make the prototype prettier than the question requires. Visual branding can bias a participant's reaction and consume revision time. Add accessibility considerations early—clear language, contrast, focus order concept, labels, and alternatives—but recognize that paper cannot verify screen-reader, keyboard, touch-target, motion, or device behavior.

Number each screen on the back so notes can identify it without revealing labels to the participant.

Rehearse the human computer

One person facilitates; another can move the paper as the system. Practise the expected path and at least one unexpected action. Decide how the “computer” responds when a control is missing: usually with no change or a neutral request for the participant to show what they expect.

Do not explain where to tap. Ask the participant to think aloud only if that suits the method and does not overburden them. When they hesitate, wait. The paper interface is currently learning to take responsibility for its own labels.

Visit customer discovery for neutral prompts and consent.

Run the task without selling

Give the scenario, not step-by-step instructions. Ask the participant to indicate actions physically or verbally, then swap states promptly. Record first choice, navigation path, hesitation, errors, questions, workaround, completion, and comments.

Avoid praise that reveals the intended answer. Thank the participant without calling a particular action correct. After the task, ask what they expected, what felt unclear, and what they would do next.

Use our non-leading interview guide for the debrief.

Revise one variable and test again

Separate observation from interpretation. “Pointed to the heading three times” is observable; “did not understand navigation” is a hypothesis. Change the label, position, grouping, sequence, or state most directly connected to the behavior.

Save a photograph or version note before revising, with appropriate consent and no unnecessary participant information. Test the changed flow with another relevant participant rather than explaining it to the first until it sounds clear.

Move to an interactive prototype when the question depends on timing, input, focus, responsive layout, accessibility technology, or realistic system behavior. Move to code when technical feasibility or integration becomes the main risk.

The paper prototype is finished when it has answered the decision question, not when every future screen has been drawn. Recycle or securely dispose of sheets according to their contents. Cheap evidence has done its job; the markers may now return to arguing about who left a cap off.

FAQ

What can a paper prototype test?

It can test a user's interpretation of labels, grouping, sequence, navigation, task flow, expected states, and basic error handling before code exists. It is less suitable for performance, real data behavior, responsive layout, device input, animation, precise visual design, or assistive-technology interaction. State the learning question first and use paper only when a human-operated low-fidelity flow can produce evidence relevant to that decision.

What materials do I need for paper prototyping?

Plain paper or index cards, removable notes, readable markers, tape or reusable adhesive, transparent sleeves, and a backing board can be enough. Make separate pieces for menus, dialogs, keyboards, and messages. Use cutting tools on a protected stable surface according to instructions, store blades securely, and use adhesives and markers with suitable ventilation and surface protection. Materials should make revision easy, not make the prototype look finished.

How does a paper prototype user test work?

Give a participant one realistic scenario without step-by-step directions. Ask them to point or say what they would do. A human acting as the system swaps screens and components in response. Observe the path, pauses, errors, expectations, and completion. Avoid teaching or praising the intended action. Afterward, ask what they expected and what was unclear, then separate observations from interpretations before changing the design.

Should a paper prototype look polished?

Only enough to be readable and support the question. Heavy branding and detailed visual design can consume time, discourage revision, and influence reactions unrelated to the flow. Use consistent control names, clear contrast, and legible states. Include back, cancel, error, and confirmation behavior where relevant. Move to a higher-fidelity prototype when typography, responsive layout, motion, timing, or realistic interaction is the risk you need to test.

When should I stop paper prototyping?

Stop when the prototype has answered the current decision question or when the remaining uncertainty depends on behavior paper cannot represent. Move to an interactive prototype for timing, input, focus, responsive layout, and accessibility technology; move to code for technical feasibility, integration, or real performance. Preserve version notes and unresolved findings. Do not draw the entire imagined product merely because the paper and markers are already on the table.