PRD to Prototype: Turning a Spec Into Something Clickable

A prototype turns a spec you have to read into something you can click. That change of medium is worth more than it sounds, because a document lets a reader nod along and a prototype does not — the moment someone clicks a button that goes nowhere, an unstated requirement becomes visible.

This is a guide to making that transition deliberately: what to fix before you generate anything, what an AI prototype generator can genuinely infer from your PRD, and why the screens it fails to produce are the most useful output of the whole exercise.

Why prototype from the spec at all

Most prototypes get built the other way around — someone opens a design tool, pushes rectangles until it feels right, and the PRD gets written afterwards to describe what was drawn. That works, and it is often the right order for genuinely novel interaction design.

It is the wrong order when the requirements are the hard part. If your feature is mostly rules — permissions, billing states, approval flows, edge cases — then drawing first means designing against assumptions nobody has checked. Generating from the spec inverts that: the document is the source, and the prototype is a rendering of it. When the rendering looks wrong, you have learned something about the document.

There is a second reason, less about correctness and more about politics. A stakeholder who cannot evaluate a twelve-page PRD can absolutely evaluate a screen. Moving from document to prototype moves the review from "does this read well" to "is this the product we want", which is the conversation you actually needed.

What to fix before you generate

A generator is a mirror. Point it at a vague spec and you get vague screens, which are worse than no screens because they look finished.

Three things determine whether the output is usable:

Name every screen. Not "the user manages their team" but "Team settings", "Invite member", "Member removed confirmation". A generator can only compose what your document names. Unnamed screens do not appear.

State the states. Empty, loading, error, success, permission-denied. Most PRDs describe the happy path and nothing else, which is exactly why most generated prototypes are a sequence of optimistic screens with no failure anywhere. If your spec has one state per screen, expect a prototype that cannot show you anything you did not already know.

Use concrete data. "A list of items" produces a placeholder. "A list of enrolled participants showing name, cohort, payment status, and last activity" produces a table you can argue with. The specificity you put into the document comes back out in the fidelity of the screens.

If that list sounds familiar, it is the same standard a reviewer applies. Prototypability is not a separate quality from spec quality — it is a symptom of it.

Review first, then generate

Run the review before the prototype, not after. This ordering matters more than it appears.

A prototype is persuasive in a way a document is not. Put a clickable artifact in front of a stakeholder and they will respond to it — which means a prototype built from an unreviewed spec will sell people on your gaps more effectively than the PRD ever could. You will get approval for requirements nobody checked, and the approval will feel like validation.

Fix the spec first. Then let the prototype do what it is good at: exposing the things a document can hide.

What the generator can and cannot infer

Worth being precise here, because the marketing around AI prototype generators tends not to be.

It can infer screen inventory from named flows, field lists from described entities, navigation structure from the order of your user journey, component choice from the kind of data (a date becomes a picker, a bounded set becomes a select), and copy from your own wording.

It cannot infer anything you did not write. Not the empty state you forgot, not the permission rule you assumed everyone knew, not the error your API returns on a duplicate email. It will either omit those screens or invent something plausible — and plausible-but-invented is the more dangerous of the two, because it looks like a decision when it is a guess.

This is why the honest way to read a generated prototype is to look for what is missing first. The absent screens are the specification gaps, rendered.

Read the gaps, not just the screens

Here is the exercise that makes this worth doing at all.

Generate the prototype. Then walk it as a hostile user. Click the thing you are not supposed to click. Submit the empty form. Remove the last remaining admin. Try to pay twice.

Every dead end is a question the PRD did not answer:

• A button with nowhere to go — an undefined flow.
• A screen with no way back — a missing navigation rule.
• A list that is always populated — no empty state specified.
• A form that always succeeds — no validation or error handling written.
• A role that can do everything — permissions never scoped.

Write those down. That list is your revision queue, and it is usually more honest than the one you would have produced by re-reading the document, because re-reading a spec you wrote surfaces very little. You know what you meant. The prototype does not.

A worked pass

A spec for a team invitation feature, reduced to its prototypable claims:

Workspace owners can invite members by email. Invitees receive a link and join with the role they were assigned. Owners can change a member's role or remove them. The member list shows name, email, role, and status.

Generated, that produces roughly three screens: a member list, an invite dialog, and a role selector.

Now walk it hostile. What happens when you invite someone already on the team? When the invite expires? When the only owner tries to remove themselves? When a member has been invited but has not accepted — what does status actually show? When the workspace has hit its seat limit?

Five questions, none answered in the spec, all of which an engineer will hit in the first afternoon. That is the return on the exercise: not the three screens you got, but the five you could not get.

Where this fits in the loop

Research shapes the problem. The PRD states it. The review pressure-tests it. The prototype makes it clickable, and in doing so pressure-tests it again in a way reading cannot. The proposal takes the result to the people who decide.

Each step is a different kind of check, and the prototype's particular contribution is that it cannot be skimmed. A document can be approved by someone who read the first page. A prototype has to be clicked, and clicking finds the holes.

FAQ

Can AI turn a PRD into a prototype? Yes, for the screens your spec actually describes. What it cannot do is invent what you left out — and the screens it fails to produce are a map of your missing requirements.

What makes a PRD easy to prototype from? Named screens, explicit states, and concrete data. The same discipline that makes a spec buildable.

Should I prototype before or after the review? Review first. A clickable artifact sells stakeholders on flawed requirements more effectively than a document ever could.

Is a prototype a replacement for the PRD? No. Acceptance criteria, non-functional requirements, and rollout rules have no visual representation. The prototype shows what it looks like; the spec says what must be true.