Prototypes

A prototype is useful when static appearance cannot answer the question.

Live behavioral evidence

Exercise the states that could reverse the decision.

Open complete artifact

Path

Resolve one blocker and prepare a release.

States

Blocked, pending, failure, recovery, and ready are operable.

Boundary

The prototype demonstrates behavior without claiming a backend.

Build the narrowest credible flow

Choose one path that represents the product decision. Give it realistic inputs, feedback, and transitions. Avoid building unrelated screens simply to make the artifact feel complete.

Include the relevant states

The important states depend on the flow, but commonly include:

• loading or pending work;
• empty content;
• validation failure;
• recoverable error;
• disabled controls;
• successful completion;
• keyboard focus and navigation.

Implement states because they affect the judgment, not to satisfy a checklist detached from the product.

Preserve the product boundary

A prototype should make clear what it is demonstrating and what remains illustrative. It should not imply a backend, permission model, or capability that has not been established.

Verify it as an interface

Test the prototype at desktop and mobile sizes. Use the keyboard. Confirm labels, focus, contrast, and recovery. A broken demonstration creates false confidence.

Make relationships visibleChoose a diagram when geometry carries the hard part of the explanation.