playbook

Build a clickable prototype to decide

Turn a spec into a single openable web page you can click through — a throwaway you build to feel the flow and make the call, never to ship.

متوسّط ~30 min

متى تلجأ إلى هذا

Specs and Figma frames let people nod along without ever feeling the thing. The moment you can actually click a flow, real reactions show up — "oh, the Saved tab should be next to the article, not buried in a menu." This system has Claude build a single self-contained web page you open in your browser and click around, so you can react to a real artifact before a single engineer touches it. The whole point is to learn and decide cheaply. A prototype is to decide, not to ship — it's a throwaway, and treating it as a head start on production is how you end up shipping fake-data spaghetti.

جهّز هذا أولًا

The v1 spec from **Pressure-test an idea into a v1 spec** — or at least the core flow and screens in a spec.md.
The one decision this prototype has to settle — "does the save-then-find flow feel obvious?" — so you build toward a question, not toward polish.
A few realistic example items (3-5 fake article titles, a couple of fake user names) so the screen feels real, not Lorem ipsum.

الـ workflow

01
State the decision, then have Claude plan the screens

Build toward a question, not toward a finished product. Naming the decision up front keeps the prototype small — you only build what's needed to answer it.
أنت تطلب
```
I want a clickable prototype to answer ONE question: does the save-article-then-find-it-in-Saved flow feel obvious to a first-time reader? From spec.md, list the minimum screens and clicks needed to test that — nothing more. Don't write any code yet.
```
ما تحصل عليه A tiny screen plan — "a list view with 5 articles each having a Save button, and a Saved tab that shows what you saved; clicking Save moves it, clicking the article opens a stub." If it's proposing login screens and settings, pull it back to the one flow.

A prototype that tries to show everything proves nothing. One question, the fewest screens that answer it.
02
Have Claude build a single openable page

Ask for one self-contained file with everything inline, so opening it is a double-click — no install, no build step, no server. That's what makes it a throwaway you can hand to anyone.
أنت تطلب
```
Build a single self-contained `prototype.html` with all the HTML, CSS, and JavaScript inline — no external files, no frameworks to install. A list of these 5 fake articles, each with a Save button; clicking Save moves the article into a 'Saved' tab; the Saved tab can remove a save. Make it openable by double-clicking the file.
```
ما تحصل عليه One prototype.html you can open straight in your browser and actually click. Save moves an article to the Saved tab, remove takes it back — the real flow, running locally, built from fake data.

If you'd rather build this yourself step by step, the *Recipes* tab walks through making a clickable page from scratch — same idea, more hand-holding.
03
Click it like a confused first-timer

Use it the way a real user would, not the way you designed it. The friction you hit clicking around is exactly the feedback you came for — and it's free now, expensive later.
أنت تطلب
```
I clicked through it. Here's what felt off: [the Saved tab was hard to find / saving gave no confirmation / I couldn't tell what was already saved]. Update prototype.html to try a fix for each, and tell me what you changed and why.
```
ما تحصل عليه A revised prototype.html plus a short list of the changes — "added a 'Saved ✓' state on the button so you can see what's already saved; moved the Saved tab up next to Articles." You iterate on a real artifact in minutes.
04
Write the decision the prototype produced

The deliverable isn't the page — it's the call you can now make. Capture what you learned so the prototype can be deleted without losing the lesson.
أنت تطلب
```
Based on how this prototype felt, write a 5-line decision note: does the flow work as-is, what needs to change before we build it for real, and is this still worth eng time? Be honest if the answer is 'not yet.'
```
ما تحصل عليه A short, defensible note — "flow works once Save shows a confirmed state; the Saved tab needs to be top-level; worth building, est. small. Open risk: what happens to saves when an article is unpublished." That note, not the HTML, is what you carry forward.

اجعله ملكك

**Compare two flows:** build two prototypes of the same feature and click both, then ask Claude to summarize which felt clearer and why — a cheap A/B before committing a direction.
**Hand it to a real user:** the single-file page can be sent to one trusting customer to click; pair it with **Synthesize feedback into a roadmap signal** to fold their reaction into the wider pattern.
**Take it to eng:** once you've decided, feed the prototype and decision note into **Read your codebase in plain English** to scope where the *real* version would live.

انتبه إلى

A prototype is to decide, not to ship. This is fake data and throwaway code by design — handing it to eng as a starting point ships exactly the shortcuts you took to move fast. The output is the *decision*, then you delete the page.
Don't seed it with real customer data to make it feel real — invent example articles and names. A prototype with live PII in a single HTML file is a leak waiting to be forwarded.
Claude builds the prototype; you make the call. "It runs" is not "we should build it" — the human still owns whether the flow is worth real engineering time.

ستحصل في النهاية على A clickable, openable prototype you used to feel the flow and a 5-line decision note that captures the call — so you commit eng time on a reaction to something real, not a guess about a mockup.

State the decision, then have Claude plan the screens

Have Claude build a single openable page

Click it like a confused first-timer

Write the decision the prototype produced