prototype

Prototype

Build a throwaway prototype that answers named unknowns, operate it, and hand it to the user for judgment.

Step 1: Name What the Prototype Must Settle

Take the open unknowns from what was passed in. When nothing was passed in, derive them from the current work: the questions whose answers in prose would still leave the user guessing, such as what a surface looks like or whether an interaction pattern makes sense in the hand.

State each unknown as a question the user answers by using the prototype rather than by reading a description. When the work that prompted the prototype already named competing alternatives, state the unknown as a comparison between them. Output that list as text before building, and keep anything outside it out of the prototype.

Step 2: Resolve the Prototype Path

Reuse the slug of the plan that governs the work when there is one. Honor an explicit slug or output path the user passed in. Otherwise generate a slug from the task title:

• Lowercase
• Replace non-alphanumeric characters with hyphens
• Collapse consecutive hyphens
• Trim leading and trailing hyphens
• Truncate to 40 characters at a word boundary

Write to .turbo/prototypes/<slug>.html, creating the directory when it does not exist. State the resolved path before writing. Later rounds of the same prototype rewrite that same file. When the path holds a prototype of a different subject, append -2, -3, and so on until the path is free.

Step 3: Build It

Write one self-contained .html file at the resolved path, with markup, styles, script, and sample data inline. It runs from file:// with no build step, no package install, and no dependency on the real application. Start the styles with [hidden] { display: none !important; }: an element whose own CSS sets any display value otherwise ignores the hidden attribute and paints anyway.

Build only what the Step 1 questions require. Hardcode the data behind them, stub anything that would cross a network boundary, and leave persistence out. When the prototype hardcodes real records and the real change would ship that same selection, choose them by one rule and apply it to every candidate alike. In a later round, keep each record the user added or removed as their exception to that rule. Where answering a Step 1 question takes surroundings that question does not put under test, such as panels, controls, or affordances, match how the real application presents them.