Paper and clickable: the first two levels

Overview

Lesson 2 gave you the filter any prototype has to pass: learn, no real implementation, disposable. This lesson gets into the first pair of fidelity levels — paper (a sketch, drawn by hand or with a simple tool) and clickable (a navigable mockup, with no real backend at all, but that you can interact with by tapping or clicking). Both are cheap compared to building for real, both are legitimate prototypes according to lesson 2's check — but they aren't interchangeable, because they answer different questions.

Today you define the fidelity-level catalog's first two objects —paper and clickable— with their relative cost and the list of questions each one can answer, and you verify with canAnswerQuestion() which of the two is enough for a concrete question about recommendations.

How this connects to the module. The paper and clickable objects you define today don't change for the rest of the module — lesson 4 adds them a third sibling (wizardOfOz), lesson 5 a fourth (fakeDoor), and lesson 6 brings all four together, with no changes at all, into a single comparison table. What you build today is, literally, the full catalog's foundation.

An everyday analogy: a film's storyboard and animatic

Before filming a scene, a film crew almost never jumps straight to the camera. First they draw a storyboard: a sequence of static, hand-drawn panels showing each shot's framing, one after another. The storyboard is cheap — an artist produces it in hours — and answers a very specific question: does the sequence of shots tell the story in the right order? Is there a missing in-between shot for the action to make sense?

If the storyboard is convincing, the next step —before filming with real actors and cameras— is sometimes an animatic: the same storyboard panels, now put in sequence with real timing, sometimes with provisional dialogue or music audio. The animatic still has no real actor, no real location, no special effect — but now it can be "played," and that lets you answer a question the static storyboard couldn't: does the scene's pacing feel right? Does a transition drag on too long, or too short?

A paper sketch is a product's storyboard: static, cheap, perfect for verifying sequence and structure. A clickable mockup is the animatic: it adds the dimension of time and interaction —tapping, navigating, advancing— without yet adding anything it would take to actually film (or build) it for real.

Worked example: canAnswerQuestion() over paper and clickable

We define the catalog's first two levels — each with its relative cost (in person-days, the same unit as module 1's timeToEvidence) and the list of questions it can answer — and check which of the two is enough for the first question Mercado's team wants to resolve about the recommendations feed.

// L3: partial fidelity-level catalog -- only paper and clickable for now
// (wizard-of-oz and fake door get added in lessons 4 and 5). `cost` is in
// person-days: how much it costs the team to BUILD this prototype, not
// the real product -- same unit as `personDays` in timeToEvidence (module 1).
const paper = {
  type: 'paper',
  cost: 0.5,
  canAnswer: [
    'the flow makes sense from start to end',
    'the screen order makes sense',
  ],
};

const clickable = {
  type: 'clickable',
  cost: 3,
  canAnswer: [
    'the flow makes sense from start to end',
    'the screen order makes sense',
    'the interaction feels natural',
    'users complete a multi-step task without help',
  ],
};

function canAnswerQuestion(prototype, question) {
  return prototype.canAnswer.includes(question);
}

const question = 'the flow makes sense from start to end';
console.log('=== Who can answer: "' + question + '"? ===\n');
[paper, clickable].forEach((p) => {
  console.log(p.type + ' (cost=' + p.cost + ' person-days): ' + (canAnswerQuestion(p, question) ? 'YES can' : 'CANNOT'));
});
console.log('\ncost difference: clickable costs ' + (clickable.cost / paper.cost) + 'x what paper costs, to answer the SAME question.');

What to expect. When you run the file with Node, the output is exactly this:

=== Who can answer: "the flow makes sense from start to end"? ===

paper (cost=0.5 person-days): YES can
clickable (cost=3 person-days): YES can

cost difference: clickable costs 6x what paper costs, to answer the SAME question.

Both can answer the same question — but one costs six times more than the other to arrive at exactly the same place. Notice, though, clickable's canAnswer list: it has two more questions paper doesn't have — "the interaction feels natural" and "users complete a multi-step task without help." Those two questions need something a static sketch, by definition, can't give: the possibility of someone actually tapping, navigating, going forward and back, and the prototype responding to those actions. A paper sketch can simulate that to some extent —someone "acts as the computer" and flips the page based on what the user points to—, but it loses fidelity quickly as soon as the interaction gets complex.

Why clickable doesn't replace paper, even though it can do everything paper can

Looking at clickable's canAnswer list —which includes everything paper answers, plus two more questions—, it's tempting to conclude it's better to always use clickable: "if it can answer more questions, why not just skip the paper step directly?". The answer is in the cost, not the capability: if this week's question is only about screen order, paying cost=3 for a capability you're not going to use is exactly the waste this whole module exists to avoid. Lesson 7 is going to formalize this criterion with a complete algorithm —pickFidelity—, but the intuition is already here: more capability isn't free, and paying for capability you don't need for today's question is a real cost, not a harmless precaution.

Common mistakes

Skipping paper and starting straight with clickable, "because that's how it's always done". What happens: the team, out of habit or because clickable mockup tools are easy to use, starts directly in Figma with a navigable prototype, without going through any paper sketch first — even when that week's question was only about screen sequence. Why it happens: modern design tools make a clickable mockup feel almost as fast to put together as a sketch, so paper's cost advantage stops feeling urgent — even though it's still real. How to spot it: nobody on the team remembers the last time they tested an idea with pencil and paper before opening a design tool. How to fix it: before opening any tool, explicitly ask what question is being answered — if the answer fits paper's canAnswer list, start there, even if it only takes a few minutes less than the clickable.

Using paper for a question that needs real interaction. What happens: the team tries to validate "do users complete a multi-step task without help?" by showing a series of paper sketches, one at a time, with someone on the team manually flipping pages based on what the user "would do" — and ends up with a confusing signal, because the person flipping pages ends up, without meaning to, guiding the user instead of letting them navigate alone. Why it happens: flipping paper pages feels similar to navigating a mockup, and it's easy not to notice the difference until the user gets stuck at a point paper can't simulate well. How to spot it: the question you want to answer includes words like "without help," "alone," or "independently" — exactly the questions that, in this lesson's catalog, only show up in clickable's canAnswer, not paper's. How to fix it: check each level's canAnswer list before choosing — if the specific question isn't on paper's list, don't force paper to answer it; move up to clickable.

Thinking a rough sketch condemns the final product to look rough. What happens: someone resists showing a paper sketch to a real user, arguing "it looks unprofessional" and could give a bad impression of Mercado as a brand. Why it happens: it's easy to confuse the prototype's visual fidelity with the final product's quality, when they're actually completely different things — a rough sketch predicts nothing about how polished the finished product is going to be. How to spot it: the objection centers on how the prototype looks in front of the user, not on whether it answers the question that needs answering. How to fix it: be explicit with the user about what they're looking at — "this is a very early sketch, it doesn't look like the final product yet" — and remember that the real visual craft, when it's time to build, is ui-systems-and-design-implementation-guide's job, not this module's.

Exercises

Exercise 1 — Find the question only clickable can answer. Without running Node, of clickable's four canAnswer questions, which two are NOT in paper's list? Explain, in your own words, why a static sketch can't answer them well.

See solution

"The interaction feels natural" and "users complete a multi-step task without help" are clickable's two exclusive questions. A static sketch can't answer the first because "feeling natural" depends on how the prototype reacts to what the user does —how fast the next screen appears, whether there's any animation or delay—, something paper can't simulate without a person constantly acting as the computer. It can't answer the second for the same reason mentioned in this lesson's second common mistake: "without help" requires the user to navigate alone, and a paper sketch almost always needs someone flipping the pages.

Exercise 2 — Calculate the cost of a third question. Without running Node, if the team needs to answer "the screen order makes sense" (which is in both levels' canAnswer list), how many person-days would they save by choosing paper instead of clickable? Express the savings as a percentage.

See solution

paper costs 0.5 person-days, clickable costs 3 — the difference is 2.5 person-days, a savings of (1 - 0.5/3) × 100 = 83.3%, rounded to 83%. This is exactly the kind of calculation pickFidelity, in lesson 7, is going to automate for any question and any list of candidates — today you did it by hand, with the same criterion.

Exercise 3 — Design a paper sketch for a different opportunity. For the opportunity "comparing prices between similar products takes me a long time" (from Mercado's tree, module 3), describe in 2-3 sentences what a paper sketch would contain to answer "does the order of the comparison screens make sense?", and explain why a clickable mockup isn't needed yet for that specific question.

See solution

A reasonable sketch: two or three hand-drawn sheets, each showing one screen of the comparison flow —a product page with a "compare" button, an intermediate screen showing the selected products, and a final table with price and feature columns side by side—, shown in order to a buyer to ask whether the path makes sense before reaching the table. A clickable isn't needed yet because the question is purely about sequence and structure —in what order do the screens appear, is there a missing intermediate step?— exactly the type of question that's in paper's canAnswer, with no need for either of clickable's exclusive capabilities (interaction that feels natural, or completing the task without help).

Summary and next step

In this lesson you defined the fidelity catalog's first two levels: paper (cost=0.5, answers questions about sequence and structure) and clickable (cost=3, six times more expensive, answers those same questions plus two more about interaction). You saw, with canAnswerQuestion(), that both can answer the same simple question about the recommendations flow — and that paying clickable's extra cost only makes sense when the specific question demands it.

Before moving on you should be able to: explain the difference between paper and clickable with the storyboard-and-animatic analogy; name the two questions only clickable can answer; and choose, for a given question, whichever of the two levels is enough without overpaying.

Lesson 4 adds a third level, very different from the previous two: the wizard-of-oz, where the prototype looks and feels completely automatic — but there's a real person, behind the curtain, doing all the work by hand.

Resources

• Jakob Nielsen (Nielsen Norman Group), "Paper Prototyping: Getting User Data Before You Code" — nngroup.com/articles/paper-prototyping. The reference article on why a paper sketch, tested with real users, catches usability problems up to a hundred times more cheaply than fixing them after coding. In English.
• Nielsen Norman Group, "UX Prototypes: Low Fidelity vs. High Fidelity" — nngroup.com/articles/ux-prototype-hi-lo-fidelity. You already saw it in module 1; it's worth rereading with today's catalog in mind — it describes exactly the three axes (visual, content, interactivity) that tell paper apart from clickable. In English.
• IDEO, "Rapid Prototyping" (Design Kit) — designkit.org/methods/rapid-prototyping.html. On why starting with the lowest possible fidelity —including this lesson's storyboard analogy— speeds up learning instead of slowing it down. In English.