Discovery Prototyping

Discovery prototyping

Core principle

A prototype exists to answer one question. Build only what that question needs, and no more. The most common prototyping failure is building a beautiful artifact that answers nothing, because nobody decided what it was for.

Second principle: fidelity is a choice, not a stage. Low fidelity is not a step on the way to high fidelity. It is the right tool when the question is about concept, structure or flow, and the wrong tool when the question is about comprehension, trust or desirability.

Choose by the question

Cagan's four types (Inspired): feasibility, user, live-data, and hybrid prototypes. The list above expands them by question rather than by artifact type.

The fidelity rules

Content fidelity matters more than visual fidelity. Lorem ipsum and placeholder data make a prototype untestable for comprehension, because half of what a user reacts to is the words and the numbers. Real content, low visual polish beats the reverse.

Match fidelity across compared options. If you are testing two approaches, the polished one wins on polish. Equal fidelity or the comparison is invalid.

Low fidelity gets more honest feedback. People are politer about things that look finished, and more willing to redesign something that looks provisional.

Higher fidelity is required for: trust, credibility, purchase intent, first-impression comprehension, and anything visual. You cannot test whether people trust a payment flow with a wireframe.

What to build, concretely

references/prototype-build-guide.md has working patterns you can generate directly:

• Clickable HTML prototype from a described flow, no dependencies, runs from a file
• Fake-door landing page with intent capture and the honest close
• Wizard of Oz operator console: user-facing surface plus an operator view
• Data mock layer so a prototype can use realistic records
• Printable paper prototype sheets

These are real, buildable artifacts. Prototype in the medium the test needs, not in the medium you have a licence for.

Testing a prototype

Full protocol in references/prototype-testing.md. The essentials:

• Tasks in the user's words, never the interface's labels
• Think-aloud
• Do not rescue until the task is genuinely dead
• Two or three options, counterbalanced, never one alone
• Collect the story before showing anything
• Five participants per round per segment, three rounds, fixing between rounds
• Severity-rate the findings

The prototype is not the evidence

A well-received prototype demonstrates that people understood it and were polite about it. It is L2 to L4 depending on how it was tested. Demand evidence requires a commitment step. Say this plainly whenever a prototype test comes back positive, because a positive prototype test is the single most over-interpreted result in product discovery.

Output

Terse by default. One line per point, not a paragraph per point. Prose only where a number would be misread without a sentence of context.

No preamble, no restating the request, no closing summary of what you just said. Drop any section that would be empty rather than filling it.

Ask when a missing answer changes the recommendation, not otherwise. Use the AskUserQuestion tool where the runtime has it and the choice is a real fork between two to four known options, recommendation first. Ask in plain numbered text for open-ended facts only the user holds. Ask nothing where a sensible default exists: state the assumption inline and move on.

Full contract and word ceilings: ../product-discovery/SKILL.md, Output contract.

Read next

Red flags

• Building before the question is written down
• Lorem ipsum in a comprehension test
• One option shown alone
• Unequal fidelity across compared options
• A prototype that took longer to build than the decision it informs is worth
• Positive prototype feedback being reported as demand
• A prototype that has quietly become the production codebase