Prototype

Raise the fidelity of a discussion by making a cheap, rough, concrete artifact to react to. Prototypes are throwaway — once the decision is captured on the wayfinder map, the prototype code is deleted.

When to use

• A wayfinder ticket typed as prototype
• When "how should it look?" or "how should it behave?" is the key question and plain-English options aren't resolving the decision
• Especially valuable for anything touching UI or complex state machines

Two modes

Logic prototype

For state machines, algorithms, edge-case behavior.

• Terminal app (Node/Python script, whatever's fastest)
• Exercise the specific state transitions or edge cases under discussion
• Output should make the behavior visible: print state transitions, show before/after, highlight the edge case
• Keep it under 100 lines — it's a conversation piece, not a draft

UI prototype

For visual design, layout, interaction patterns.

• Self-contained HTML file with inline styles
• Multiple variants switchable via URL params (?variant=a, ?variant=b)
• Use real (or realistic) data, not lorem ipsum — decisions change when content is real-shaped
• Open in browser for the user to react to
• No framework, no build step — raw HTML/CSS/JS only

Process

1. Confirm which mode fits (ask if unclear)
2. Build the minimal artifact
3. Present it to the user
4. Capture the decision on the wayfinder map
5. Delete the prototype code

What this skill must never do

• Never let a prototype survive past the decision it was built to inform
• Never build a prototype as a "head start" on implementation
• Never spend more than 15 minutes on a prototype — if it's taking longer, the question needs more grilling first