What to Prototype and What to Just Specify

A prototype shows what a thing looks like. A spec says what must be true about it. Those are different claims, and the gap between them is where most "we prototyped it, so we're aligned" projects go wrong.

The useful question is not should we prototype this but which requirements does a prototype carry, and which ones can it not carry at all. Some have a picture. Many of the most consequential ones do not.

The test

For any requirement, ask: could I settle a disagreement about this by pointing at a screen?

If yes, prototype it — you will resolve it faster by looking than by describing. If no, no amount of prototyping will specify it, and the only question is whether you wrote it down somewhere else.

What a prototype is the right medium for

Layout and hierarchy. What is prominent, what is secondary, what got buried. Three people reading "the primary action should be clear" agree completely and picture three different screens.

Flow length and order. How many steps, in what sequence, with what backtracking. Flow problems are almost invisible in prose and obvious the moment you click through them.

Density at real volume. A table designed for eight rows behaves differently at four hundred. Populate a prototype with realistic data and the pagination question answers itself.

Affordance. Whether a thing reads as clickable, whether a disabled state reads as broken, whether an inline edit is discoverable. You cannot reason your way to this; you have to look.

Comparisons. Two layouts, two flows, two placements. Prototypes are the cheapest way to make an A-or-B decision, and the decision usually takes minutes once both exist.

What has no picture

This is the half that gets lost when a prototype is treated as the specification.

Acceptance criteria. The pass/fail conditions that decide whether the built thing is correct. A screen shows one outcome; it does not state the rule that produces it or the boundary where the rule changes. Testable criteria are text, permanently.

Non-functional requirements. Latency, availability, concurrency, capacity, security posture. A prototype is infinitely fast and never fails, which makes it actively misleading about the requirements most likely to hurt you.

Permission rules. Mostly defined by absence — what a role cannot do and what they see instead. Prototypes are almost always built as one privileged user, so the entire permission surface is invisible in the artifact.

Data lifecycle. Retention, deletion, export, what happens to records when a workspace closes. Consequential, frequently regulated, and completely unrepresentable in a clickable screen.

Rollout and phasing. Which cohort, in what order, with what exit criteria. A prototype shows the end state, never the sequence to reach it.

Rules and calculations. Pricing, proration, scoring, ranking. A prototype displays a number. It does not say how the number was derived, and the derivation is the requirement.

Notice the pattern: the invisible half is disproportionately the half that produces incidents rather than complaints. A confusing layout generates feedback. An unspecified proration rule generates refunds.

The dangerous middle

Between clearly-visual and clearly-textual sits the category that actually burns teams: requirements that appear in a prototype and therefore feel specified, but are not.

An empty state rendered once looks like a decision. It does not say when it appears — new user, or filtered result with no matches, or all items deleted — and those are three different messages.

A validation message shown on one screen looks like validation. It does not say which inputs trigger it, whether it fires on blur or submit, or what happens to the rest of the form.

An error toast in the prototype looks like error handling. It says nothing about which failures produce it, whether the user's work survives, or what gets logged.

The mechanism is the same each time: the screen exists, so the decision feels made. Nobody writes the rule, and the rule is the part that gets built. This is why "we have a prototype" is not an answer to "is this specified" — and why the strongest specs pair the two rather than substituting one for the other.

The allocation rule

One line to carry away:

Prototype the things you would argue about by pointing. Specify the things you would argue about by asking "what happens when…".

Almost every requirement sorts cleanly under that test. "Is the button prominent enough" is a pointing argument. "What happens when two people edit at once" is a what-happens argument, and no screen will settle it.

When something sorts into both — an empty state, a validation, an error — it needs both: the screen so people can see it, and the rule so people can build it.

Order of operations

Two sequences work and one reliably does not.

Prototype early, then specify. Right when the shape is genuinely unknown. Explore, decide the form, then write the spec that makes it buildable. The prototype is a thinking tool and gets thrown away.

Specify, review, then prototype. Right when the requirements are the hard part. The prototype becomes a check on a document that has already been pressure-tested, and clicking it surfaces whatever the review missed.

Prototype an unreviewed spec and show stakeholders. This is the one that goes wrong. A clickable artifact is far more persuasive than a document, so you will secure approval for requirements nobody checked — and the approval will feel like validation rather than a risk you took.

If you only remember one thing about sequencing: review before you make it persuasive.

FAQ

Can a prototype replace a PRD? No. It is a visual medium, so it can only carry visual requirements — and the non-visual ones cause the incidents.

What belongs in a prototype? Anything you would argue about by pointing: layout, flow length, density, affordance, A-or-B comparisons.

Why isn't a prototyped screen specified? It shows one instance of a state, not the rule that produces it. The screen looks decided, so the rule never gets written.

Prototype before or after the spec? Early to decide shape, late to verify a reviewed spec. Never on an unreviewed spec in front of stakeholders.