Craft
Prototype Examples: Five Specs and What Each Had to Guess
Five illustrative spec-and-prototype pairs, from password reset to notification settings: what each spec decided and what the prototype had to guess.
If you are searching for prototype examples, you probably want to see one. Screens on their own teach less than they seem to, though. A polished mockup tells you what someone built. It does not tell you which parts were decided and which were made up along the way.
So the examples below come in pairs: a short spec, and the prototype built from it. For each, what the spec decided, what the prototype had to guess, and the question the guess should have raised.
All five are illustrations constructed for this post, not customer projects. They are deliberately small, so each one fits on a screen.
How to read them
Every element in a prototype has one of three sources. The spec said it. The spec implied it, the way a date field implies a date picker. Or someone guessed, a designer or a generator, because the spec was silent and a screen cannot be.
The third kind is the one to look for. A plausible guess looks like a decision, and nobody reviews something that looks decided.
1. Password reset
The spec:
Users who forget their password can request a reset link by email. The link expires after 30 minutes. Passwords must be at least 12 characters.
The prototype: four screens. Enter your email; check your inbox; set a new password, with a length hint; success, with a link to sign in.
Decided: the channel, the expiry, the length rule.
Guessed: what the check-your-inbox screen says when the email has no account. The prototype showed the same message either way, which happens to be the safer choice, since a different message tells anyone which addresses have accounts. Safe by accident. And the expired-link screen did not exist at all.
The question: should the response reveal whether an account exists? That is a security decision, and it was settled by whatever the template did.
2. Team invite with a seat limit
The spec:
Workspace owners can invite members by email and assign a role, admin or member. Each plan includes a fixed number of seats.
The prototype: a member list with role and status, an invite dialog, a role dropdown.
Decided: who can invite, the two roles, that seats are limited.
Guessed: whether a pending invite uses a seat. The prototype counted only accepted members, so the counter read 9 of 10 with three invites outstanding. And what happens at the limit: the invite button simply stayed enabled.
The question: at the limit, do you block the invite, warn and allow it, or offer an upgrade? Each is a different screen and a different billing rule.
3. Export orders to CSV
The spec:
Admins can export the orders table to CSV using the filters currently applied. Columns: order ID, date, customer, total, status.
The prototype: an Export button above the table, and a toast saying the download has started.
Decided: who, which columns, that filters apply.
Guessed: that every export is instant. Fine for forty rows, not for an account with a year of orders, which needs a background job and an email when it is ready. Also guessed: the timezone of the date column, and what an export with no matching rows produces.
The question: above what size does export run in the background, and how does the admin get the file? That is a limit and a state, and neither has a picture until someone decides it.
4. Onboarding checklist
The spec:
New workspace owners see a four-step checklist: create a project, invite a teammate, connect an integration, publish a first doc. It disappears when all four are complete.
The prototype: a card on the home screen with four rows, ticks and a progress bar.
Decided: the steps, the audience, the end condition.
Guessed: whether steps can be skipped. The prototype added a skip link to the integration step, because it looked optional. Whether the card can be dismissed early: the prototype gave it a close button. And whether "invite a teammate" counts as done when the invite is sent or when it is accepted.
The question: what counts as done for each step? A progress bar implies four crisp events, and two of these are not crisp at all.
5. Notification preferences
The spec:
Users can choose email and in-app notifications per category: mentions, comments, weekly summary, billing.
The prototype: a settings page with a grid of four categories by two channels, every toggle on.
Decided: the categories, the channels, that settings are per user.
Guessed: the defaults, set to everything on. And that every toggle can be switched off, including billing email, which means a user can opt out of hearing that their payment failed.
The question: which notifications are mandatory, and what does a new user start with? Both are rules, and the grid shows neither.
What the five have in common
| Example | What the prototype guessed | Kind of requirement |
|---|---|---|
| Password reset | The reply for unknown emails; the expired link | Security rule, state |
| Team invite | Whether pending invites use seats; the limit | Rule, limit |
| CSV export | Large exports; timezone; empty result | Limit, state |
| Onboarding checklist | Skipping, dismissing, what "done" means | Rules |
| Notifications | Defaults; mandatory categories | Defaults, rule |
Not one guess is about layout. Every spec described its screens well enough. What they left out were rules, limits, defaults and states: the requirements with no picture. A prototype cannot leave those blank, so it fills them with something plausible, and the plausible thing ships unless somebody asks.
That is why these make better examples than a gallery of finished screens. The screens were the easy part.
Make your own pair
You can run the same exercise on any spec of your own:
- Build a prototype from the spec as written. Do not fix the spec first; the point is to see what it leaves open. Keep this one to yourself until the guesses are answered, because a clickable artifact wins approval whether or not the requirements underneath are sound.
- List every element on every screen: text, buttons, defaults, states.
- Mark each one said, implied or guessed.
- Turn every guess into a question, and answer it in the spec, not in the prototype.
For the password reset above, step three produces something like this: the email field, said. The length hint, implied by the 12-character rule. The identical message for unknown emails, guessed. The expired-link screen, missing, which is a guess too, since the prototype guessed nobody would need it. Two of the four lines become questions for the spec.
Step four is where the work is. Keeping those answers in the spec through review and sign-off is its own discipline, covered in reviewing a prototype without losing the spec.
Thinkr's Prototype builds a clickable prototype straight from a PRD, which makes step one quick. Steps two to four are still yours.
FAQ
What is an example of a prototype? A clickable password-reset flow, shown beside the spec it came from.
What makes a good prototype example? One you can trace: every element said, implied or marked as a guess.
What is a simple one to start with? A single flow of three to five screens with one real decision in it.
Are these from real projects? No. They are illustrations constructed for this post.