Prototype

When a team agrees on something only in writing, everyone leaves the meeting holding a different picture. The sentence in the document is identical, but the person who wrote it pictures a panel opening on the right, the designer pictures a separate page, and the engineer pictures one more row under the list. All three read the document correctly. Prose simply doesn't carry layout and order.

A requirement can be precise about what happens and still say nothing about where it happens. "The user can turn a paragraph into a task" fixes the behavior and leaves the position, the order of steps and the visibility of the control entirely open, and those are exactly the things that decide whether anyone finds the feature. Reviewers sign off on the sentence because the sentence is correct. Everyone then builds the part it left blank out of their own habits.

The mismatch surfaces after everything is built. At Pagedeck, Mia wrote up a feature for turning a paragraph into a task without leaving the document, and Theo spent six weeks building it. Two weeks after launch, seven percent of users had touched it once. The reason wasn't that the feature was bad. The button for creating a task sat inside a toolbar at the bottom of the document, and nobody knew it was there. Confirming one piece of placement had cost six weeks of an engineer's time.

What makes that expensive is how the price of a change climbs. Moving a button on a paper sketch takes five minutes. Moving it in a design file takes half a day. Moving it halfway through the build takes several days. After release it stops being a question of time at all: people have gotten used to the old spot, so moving it creates fresh complaints and needs an announcement and a note in the product. The same decision can cost a hundred times more depending on when it gets made.

A prototype exists to pull that decision forward, and the trick is leaving the inside empty. There's no database, nothing saves, nobody logs in — but from where the viewer sits there is a screen, it responds, and it goes somewhere next. That's enough to see whether a person gets stuck. It takes half a day to make, and if the answer is no, it gets thrown away. Being cheap enough to throw away is the defining property.

That's also why it sits in its own group in product. Four things get made before the finished article: an MVP is the smallest working product you release to real users to test an assumption, a proof of concept (PoC) checks in a small way whether something is technically possible, and a pilot runs the finished product with a handful of customers first. The prototype is the only one of the four allowed to be hollow.

The terms under this name split along a single axis: how close to real the thing is built, its fidelity. There are four, and the effort and the range of answers rise together.

1. Paper prototype — hand-drawn screens laid on a table, tapped with a finger while someone swaps the sheets. It takes half an hour to make and shows whether the order makes sense and whether there are too many steps. Paper is an advantage rather than a limitation here: people say a rough sketch looks wrong without hesitating.
2. Low-fidelity prototype — color, type and imagery stripped out, structure carried by boxes and lines. It answers what goes where and what needs to be larger. It looks almost identical to a wireframe; the difference is that a wireframe is a still drawing and this one can be clicked through.
3. Clickable dummy — a shell where only the screen transitions work. Press the button and the next screen appears, but nothing you type is kept and the count on the list never changes. It follows one fixed path, which suits walking a single scenario end to end. It really cuts along interactivity rather than fidelity, so it can be built rough or polished.
4. High-fidelity prototype — close enough to the real screen that people can't tell, with color, wording and spacing in place. It takes a day or several, and in exchange it can answer questions that live in the surface: whether a label reads ambiguously, whether a button stands out. It's also what gets shown to investors and customers.

Which fidelity to use is decided by the question, not by taste. Checking whether a flow makes sense needs paper. Checking which of three labels confuses people least needs the polished version. Building above the question costs more than time — it blurs the answer. Show a fully colored screen and people stop saying the order is strange and start saying the blue would be better. If the order was the question, that session was wasted.

Teams generally climb from low to high. Settle the flow on paper, move to low fidelity once the structure holds, build a clickable dummy when a scenario needs following through, and go high when wording and color have to be decided. Not every change walks all four steps. Adding one button to a screen that already exists usually starts at the clickable dummy. The test is whether an open question remains, not whether every rung got used.

Deciding what to ask comes before deciding what to build. Asking whether people get lost on one screen needs two screens; asking whether they would use a feature at all needs the whole path that leads to it. Without a question set in advance the screen count keeps growing, and past a point the building costs more than the thing it was meant to check.

The four terms also aren't four separate products. They're four settings on the same dial, and most teams move a single idea through two or three of them in a week. What changes between the settings is not the idea but how much of it is committed to. Paper commits to an order, low fidelity commits to a layout, a clickable dummy commits to a path, and high fidelity commits to the words. Each rung makes a smaller set of things still cheap to change, which is the reason to spend as little time on the high rungs as the question allows.

Three situations account for most use. The first is putting it in front of users and watching. Give five people the same task and note where they stop, and the large problems usually show themselves. The second is aligning a team, where a link to the screens attached to the requirements keeps those three different mental pictures from forming. The third is a design sprint, a five-day workshop that runs from framing a problem to testing an answer. Building on day four and testing with five users on day five is the backbone of that week, so here the work is already written into the schedule.

"This is a prototype, so nothing saves. Just click around."

The screen looks real, but nothing happens behind it.

"Let's run a clickable dummy past five people before we write the requirements."

Narrow the direction with real reactions before committing anything to prose.

"We don't need high fidelity here. We're only checking the order, so paper is enough."

The build is heavier than the question deserves.

When Pagedeck went back to fix the feature that reached seven percent, it reversed the order. Noa built a clickable dummy in one day: three versions of the same screen, identical except for where the button sat — inside the bottom toolbar, as a small marker beside the paragraph, and in a panel on the right. Theo built nothing at this stage.

Mia pulled five colleagues in and gave them one task: turn this paragraph into a task. On the toolbar version, four of the five hunted around the top of the document and never found it. On the version with the marker beside the paragraph, all five found it within three seconds. The right-hand panel was easy to find, but three people said it squeezed the document. The decision was made in that room, and Theo's rebuild took four days. Six weeks of building and one day of prototyping had produced the same kind of answer.

The most common mistake is reading a prototype as the first version of the software. It has screens and they respond, so it looks like something you can keep building on. In fact it was made to be discarded. There is no logic inside, the data is typed in by hand screen by screen, and error cases don't exist at all. Move that into production code and the temporary scaffolding ends up in the middle of the product, and months later that part is the hard part to touch. Often there's nothing to move anyway, since screens built in a design tool aren't code.

Assuming higher fidelity is always better comes up nearly as often. The closer to real, the more accurate the reaction seems. Two things arrive with the polish, though. Viewers start talking about color and wording instead of structure, and the person who spent two days on the screen no longer wants to throw it out. The second is worse, because it silences the suggestion to change course at the only moment changing course is cheap. Nobody minds binning a paper sketch. Standing in front of something that took days, the same sentence tends not to get said. Raise fidelity only as far as the answer requires.

High fidelity leaving the building causes its own trouble. Show a customer or an investor a screen indistinguishable from the product and they will take it as something that already ships. This is how a screen demoed once in a sales meeting turns up in contract terms weeks later. It's why many teams attach one sentence when they present: this part isn't built yet. Internally it can go unsaid; outside, leaving it out is hard to walk back.