Reviewing a Prototype Without Losing the Spec

A prototype review generates decisions faster than any other kind of review. Somebody clicks through and says drop the confirmation step, show the count in the header, let members see the archive too. Each of those takes ten seconds to say, and each one changes a requirement.

Almost none of them reach the spec. They get made in the prototype, or in the meeting notes, or in someone's memory, and two weeks later the prototype and the PRD disagree about what the feature does. Engineering builds from whichever one they opened first.

The fix is not a process. It is one stance and three habits. The stance: the spec is the source, and the prototype renders a version of it. The habits: checkpoints, annotations, and a light rule for change.

Three kinds of prototype feedback

Every comment in a prototype review is one of three things, and each lands somewhere different.

Feedback	Example	Where it lands
Rendering fix	"The spec says owners only, but members can see the button"	The prototype. The spec was right.
Spec change	"Archiving is reversible, so it should not need a confirmation"	The spec first, then the prototype
Exposed gap	"What happens to scheduled reports in an archived project?"	The spec, as a new decision

The test for the middle row: would an engineer build something different? If yes, it is a requirement change, however small it looked on screen. Copy tweaks and spacing usually fail that test and can stay in the prototype. A removed step, a changed permission or a new state always pass it.

The third row is the valuable one. It is what walking a prototype hostile is for: every screen the prototype had to guess at is a question the spec did not answer.

Checkpoint one: before you build

Review the spec first. A prototype is persuasive, and one built from an unreviewed spec will sell its gaps to everyone who clicks it.

Then pin the version. The prototype carries a label, built from spec v3, 9 October. Without it, nobody can tell whether a mismatch is a rendering bug or a spec change made afterwards, and that is the first question every mismatch raises.

Checkpoint two: the review itself

Annotate before reviewers see it. Each screen gets a tag naming the section it renders. Anything the prototype shows that the spec does not say gets marked as a guess: a default sort order, a confirmation dialog, the wording of an empty state.

Annotations change what reviewers do. Without them, people respond to the screen and assume everything on it was decided. With them, a reviewer can see the empty state was a guess and ask the question the guess was hiding. They also make comments citeable: "section 5, the archive dialog" lands in the right place; "that popup" does not.

Ask reviewers to label their own comments with the three kinds above. They will sometimes get it wrong, but asking makes them decide whether they are critiquing the rendering or the requirement.

Change control without a committee

One rule: the prototype never leads. A change that alters behaviour goes into the spec first, or the same day, and then into the prototype. Never the other way round.

Each spec change gets three lines: what changed, why, and who agreed. It is the same amendment habit that keeps a spec honest in an agile cadence, applied to the decisions a review produces. It takes a minute per change, and it is the difference between a review that improved the spec and one that forked it.

If a change was made to the prototype in the room before anyone wrote it down, the author closes the gap before the meeting ends, while everyone is still there to confirm the wording.

There is a quick test for whether the rule is holding, and it is sharpest when the prototype is generated from the spec. Ask: if we regenerated the prototype from the current spec right now, would we lose anything? Every answer is a decision that exists only in the prototype. With a hand-built prototype the question is the same, just harder to run, because nobody will rebuild it to find out. The answer you want is "no, only the colours".

Comments on the prototype follow the same discipline as comments on the doc. Type them, decide who can close them, and require a written resolution, the rules from async PRD review. A prototype comment marked "done" with no reply has the same problem as a spec comment marked "done": nobody can tell whether the spec changed.

Checkpoint three: before sign-off

Before anyone signs, compare the two:

• Does the prototype show any behaviour the spec does not describe?
• Has the spec changed since the prototype was last rendered?
• Is every marked guess either confirmed in the spec or removed from the prototype?

Then decide what the approval covers. A prototype can carry layout, flow and copy. It cannot carry the requirements that have no picture: permission rules, limits, non-functional thresholds, data retention. A stakeholder who approves the prototype has approved what it shows, and nothing else.

So sign-off belongs on the spec, with the prototype referenced for the sections it illustrates: flows in sections 3 to 5 approved as rendered in the v3 prototype; sections 6 to 8 reviewed in text.

Fidelity changes the feedback

A polished prototype gets comments about colour and button copy. A plain one gets comments about the flow. If the decisions you need are about behaviour, keep visual fidelity low and functional and data fidelity high, and say what question you want answered before anyone starts clicking.

A worked pass

An illustration. A spec for archiving projects in a team workspace, v3, prototyped and reviewed by five people. The review produced six comments:

1. Members can see the archive button. Rendering fix: the spec says owners and admins only.
2. Archiving should not need a confirmation, because it is reversible. Spec change: section 4 updated, dialog removed.
3. What happens to scheduled reports in an archived project? Gap: new decision in the spec, reports pause and resume on restore.
4. The empty archive list says "Nothing here yet". A marked guess: the spec was silent, so the wording was added to section 5.
5. The archive button should be grey. Rendering only: no change in behaviour, so it stays in the prototype.
6. Do archived projects count toward the plan's project limit? Gap: open, owner billing, Friday.

Three of the six changed the spec, and a fourth is still open. Without the rule, all of them would have lived in the prototype and the meeting notes. The engineer building from the spec would have built a confirmation dialog nobody wanted, with no answer about reports and no idea the limit question existed.

Review what the review changed

The decisions made in a prototype review are among the least-reviewed requirements in a project. They were made quickly, by people looking at a screen, and they skipped whatever scrutiny the original spec got.

So review the amended spec again before sign-off. Our critique runs the same eleven passes on v4 that it ran on v3 and lands its findings as comments marked blocker, major or minor, each with a suggested rewrite, so the new states and rules get the same check as the old ones.

FAQ

How do you keep a prototype and a PRD aligned? Pin the spec version, tag screens to sections, and change the spec before the prototype.

Should prototype feedback change the PRD? When an engineer would build something different because of it, yes.

What should a prototype review check? Traceability to the spec, marked guesses, walkable unhappy paths, and decisions written back.

Can stakeholders sign off on a prototype instead? Only on what it shows. Sign-off belongs on the spec.