skip to content

In UX design, when is a paper prototype a better choice than a click-through prototype, and what can each not show?

level: juniorimportance: nice to knowfreq 28%

answer

  1. a person plays the computer
  2. change it mid-session
  3. linked screens with hotspots
  4. remote and unmoderated reach
  5. only the paths you linked

basics

~20 s

Paper suits very early work: minutes to make, editable mid-session, and it invites candid critique, but it cannot show timing, scrolling or gestures. Click-through prototypes reach remote users with realistic flow, yet follow only the paths the team linked.

solid answer

~50 s

A **paper prototype** is a set of hand-drawn screens where a facilitator acts as the computer, swapping sheets as the participant taps. It is best **very early**: screens take minutes, the team can redraw one **during** a session, anyone can make one, and participants criticise it freely. It cannot show **timing**, scrolling, gestures, real data or visual design, and it needs a skilled facilitator present. A **click-through prototype** links static screens with clickable hotspots. It suits **slightly later** work: it feels closer to the product, can run **remotely or unmoderated** at larger scale, and is easy to share with stakeholders. But it follows **only the paths the team linked**: a car-rental participant who types an unexpected city or taps outside a hotspot hits a dead end, and free input, errors and dynamic states are faked or missing. Choose paper to explore; choose click-through to check a flow people can walk alone.

go deeper

for a junior

Recall that paper prototypes use a person as the computer and suit early exploration, while click-through prototypes link static screens with hotspots.

for a middle

Explain what each cannot show — paper lacks timing and visuals; click-through follows only linked paths and fakes input — and pick one for a given stage.

for a senior

Show how you plan a sequence from paper to click-through to a coded slice, and which findings each stage is not allowed to claim.

for a principal

Decide how much remote, unmoderated prototype testing a team relies on versus facilitated sessions, weighing reach against depth of insight.

## Paper prototypes A **paper prototype** is a set of hand-drawn or printed screens and interface pieces — pop-ups, lists, keyboards — that a facilitator manipulates in response to what a participant does. The facilitator effectively **plays the computer**: when the participant taps “Search”, the facilitator puts down the results sheet. This is a specific case of the broader **Wizard-of-Oz** technique, in which a human secretly performs what the system will later do. **Strengths:** - **Minutes to make**, with no special skills or tools. - **Editable mid-session**: if every participant misreads a label, the team can redraw it before the next task. - **Candid feedback**: obvious roughness tells participants nothing is decided. - **Co-design**: participants can draw their own versions, which is hard with any digital prototype. - **Complex logic is cheap to fake**: the human computer can respond to any input, including an unexpected search term. **Limits:** - no **timing** or perceived speed, since the facilitator sets the pace; - no realistic **scrolling**, gestures, animation or hover states; - no **visual design** or brand perception; - needs a **skilled facilitator** in the room, which limits scale; - awkward for **remote** sessions, and some audiences dismiss it as unserious. ## Click-through prototypes A **click-through prototype** is a set of static screens — wireframes or visual designs — linked by clickable **hotspots**, so tapping an element moves to the next screen. **Strengths:** - **Feels closer to the product**, especially with real visual design. - **Runs without a facilitator**, so it can reach remote and unmoderated participants at larger scale. - **Easy to share** with stakeholders and to walk through in reviews. - **Consistent**: every participant sees the same behaviour. **Limits:** - **Only the linked paths exist**: taps outside hotspots do nothing, and alternative routes dead-end. - **Free input is faked**: a typed search usually leads to one prepared result, whatever was typed. - **Dynamic states are missing**: errors, empty results, loading, sold-out items — unless each is drawn and linked. - **Timing is unrealistic**: screens change instantly, flattering anything that will be slow in reality. ## Side by side | | Paper | Click-through | |---|---|---| | Effort to make | Minutes | Hours | | Change during a session | Easy | Possible but slower | | Facilitator needed | Yes, as the computer | No | | Remote or unmoderated | Awkward | Natural | | Free input and surprises | Handled by the human | Usually a dead end | | Timing, scrolling, gestures | Not shown | Partly shown, timing flattered | | Best stage | Early exploration | Checking a settled flow | ## A car-rental example Early on, a team unsure how to present pick-up options draws three paper versions — a list, a map, a single suggested branch — and runs quick sessions, redrawing between participants. Once the list-plus-map approach is chosen, it builds a click-through version to check that people can move from search to a chosen car without help. In that click-through, a participant who types “airport” when the prototype expects a city name sees the same prepared result regardless — a reminder that findings about input handling need a different prototype. ## Common mistakes - **Drawing paper screens too neatly**, which removes the invitation to criticise and costs time the method was meant to save. - **Forgetting the pieces the computer must supply** — empty results, error messages, a keyboard — so the facilitator improvises inconsistently. - **Reporting click-through smoothness as validation** of error handling or input, when those paths were never built. - **Writing tasks the prototype cannot support**, so participants fall off the linked path and the session measures the prototype rather than the design. - **Treating either as a finished spec** for engineering; both show intent, not the full set of states a build needs. ## Choosing 1. **Exploring directions, changing fast** → paper. 2. **Checking a mostly settled flow with more people** → click-through. 3. **Questions about free input, speed or dynamic data** → neither; a small coded prototype. Both work equally for web and native mobile products; for touch interfaces, paper can be laid over a phone-sized frame so hand positions stay realistic.

  • What is a Wizard-of-Oz prototype, and how does it relate to paper prototyping?
    A Wizard-of-Oz prototype has a hidden human performing what the system will later do automatically — choosing search results, generating replies. Paper prototyping is a visible, low-tech version of the same idea: the facilitator plays the computer. It lets teams test behaviour that would be expensive to build before knowing it is wanted.
  • How do you reduce dead ends in a click-through prototype?
    Link the likely alternative paths as well as the happy path, add simple screens for errors and empty results, and give off-path taps a neutral response rather than nothing. Most importantly, write tasks the prototype can support, and note which findings about input or errors need a different prototype.

saying these in an interview costs you the question

  • Paper prototypes are only for people who cannot use design tools.
  • A click-through prototype can respond to anything a participant types.
  • Paper prototypes can show whether the interface feels fast.
  • Click-through prototypes need a facilitator to play the computer.
  • If a click-through test goes smoothly, error handling has been validated.