Paper Prototype

Teams kept discovering that the screen order was wrong only after everything had been built. A designer would spend three days on a mockup with real colors and real copy, engineering would spend two weeks wiring the screens together, and only then would someone ask why a particular step existed at all. By that point, fixing it cost ten times what it would have cost at the sketching stage.

The harder problem was human. Nobody criticizes work that clearly took effort. Put a polished mockup on the meeting room screen and the comments are predictable: the blue looks a little strong, the spacing could come down a notch. What nobody says is "could we drop this screen entirely." Everyone in the room can see how long the person spent on it.

So the answer was to make the thing deliberately shabby. People have no trouble calling out a screen drawn with a ballpoint pen on a sheet of A4 in under thirty minutes. How closely a prototype resembles the real thing is called fidelity, and a paper prototype sits at the very bottom of that scale on purpose. If the question you are asking is about order and the number of steps, color and typeface are noise that blurs the answer.

One sheet is one screen. You draw each screen on a sheet of A4 or an index card and spread the stack across a desk, and that stack is one prototype. Five things go into it.

1. The screen sheets. Usually five to eight. Past ten, the question you are trying to answer in one session is too big, and splitting the path in two works better.
2. Marks for what can be tapped. Draw a border around buttons and links so they read differently from the text around them. Paper gives no hint about what is clickable, so without those marks people poke anywhere.
3. The rules for moving between screens. Write on the back of each sheet which button leads to which sheet number.
4. The pieces that change. An open dropdown, an error message, a loading indicator — cut those out separately on sticky notes and lay them on top when the moment comes. Drawing every state of one screen as its own full sheet pushes the stack past twenty sheets fast.
5. One line of task for the user. Something like "invite two teammates to this document" — the goal only, never the steps. Spell out the steps and people follow them, which hides the place where they would have gotten lost.

It helps to fix a list of what stays out as well: color, typeface, images, real data, and polished wording. A high-fidelity prototype is the form that carries all of that, and chasing it on paper pushes build time past a day, which is where the whole advantage disappears.

The person drawing is usually a product designer. At Pagedeck that is Noa. Drawing skill isn't part of the job, though, so product managers like Mia often sketch their own.

There are three kinds of reader.

1. Users. They take a task in a usability test and tap their way across the paper. A usability test hands someone a real task and watches for the point where they stall, and paper surfaces the large problems well enough.
2. Engineers. Theo sees the order and the branches before he builds anything, and he says right there if a flow doesn't work with the current schema.
3. The person who drew it. Laying a flow out as separate sheets makes the missing screens visible — where someone who isn't logged in lands after clicking an invite link, for instance.

Reading works differently here than with other documents. The reader doesn't get handed the thing and read it alone; the person who drew it sits next to them and turns the pages. A human plays the part of the computer. That means three people at the table: a facilitator who moves the paper, the user, and a note-taker writing down where the user stopped. At Pagedeck, Noa turns the pages and Mia takes the notes. The test breaks the moment the facilitator starts explaining. When the user asks how something is supposed to work, the only answer is "do whatever the screen tells you."

It also isn't an artifact anyone keeps. When the test ends you take a few photos and throw the paper away. What gets attached to the product requirements document (PRD) is the conclusion drawn from the session, not the paper itself.

"No need to take this all the way into Figma — draw five sheets and show three people this afternoon."

Skip the days a mockup takes and find the flow problem today.

"We ran it on paper and all three people stopped on the third sheet. I think the right move is merging those steps."

The problem reproduced even at low fidelity, so there is evidence for changing the structure.

"We're still on paper, so ignore the wording and look at the order."

Naming the fidelity up front moves the feedback off color and text and onto flow.

The week Pagedeck changed how documents get shared, Noa brought in six sheets of a new flow and pulled three people from a neighboring team with the task "make this document visible to two teammates." All three stopped on the sheet for choosing permissions. The permission screen came before the screen for naming the people to invite, and being asked about permissions before deciding who was being invited felt wrong to every one of them.

They flipped the order and redrew it that afternoon, and in the second round all three reached the end. Without the paper round, the same problem would have surfaced after implementation, where changing the order means rewriting two screens that are already built.

The common reading is that paper is the fallback for when there is no time and no budget. With a pen and some paper as the only tools, it looks that way. But the reason for choosing paper is the question, not the circumstances. When you want to know whether a flow makes sense, paper is the better instrument, and well-funded teams reach for it on that question too. Treat it as a fallback and skip it, and the order problem turns up right before implementation, where it costs more than a redraw — the dates already on the calendar move with it.

The other frequent mistake is thinking the drawing has to look good. It is going in front of other people, so neat feels right, but neat is exactly what kills the advantage. Show a screen drawn against a ruler and people start talking about color and alignment again. A line that visibly wobbles carries a useful signal of its own: nothing here is settled yet.