Name what the prototype must prove
A prototype might test whether people understand a new mental model, whether a multi-step task feels manageable, or whether a risky interaction can be operated accessibly. That question determines which states need fidelity and which can remain simple.
Without a named uncertainty, teams often polish the easiest screens and leave the hardest behavior unexplored.
Choose fidelity per decision
Paper flows are enough for sequence and information architecture. Clickable wireframes can test navigation and comprehension. Code is justified when timing, responsive behavior, browser semantics, or real data materially affect the answer.
- Use the cheapest artifact that can answer the question.
- Include empty, loading, error, and recovery states.
- Test realistic content rather than perfect placeholders.
- Record the decision produced by the test.
A prototype is evidence, not production code
Even a coded prototype may contain shortcuts that are unsafe for production. Mark those boundaries explicitly so an agent or developer does not treat exploratory implementation as an approved foundation.
The durable output is the learning: what was tested, what happened, what changed, and which requirement revision now reflects the result.