Write the question before choosing the finish.
Imagine a hypothetical guided selector for a small set of options. The team is unsure whether visitors understand the difference between two categories. A prototype focused on that question needs understandable names, descriptions, and a realistic choice. It may not need an account screen, payment flow, or a detailed visual identity.
Another team might already understand the choice but need to examine how a complex interaction responds on a small display. That prototype needs a different kind of detail. The uncertainty determines the useful fidelity.
Write the question in a way that can change a decision. “Does this look good?” is broad. “Can someone explain the difference between these two routes after reading the introduction?” gives the review a more specific purpose.
Separate visual, content, and behavioral fidelity.
A prototype can be visually polished while using fictional information. It can contain realistic content but only a narrow interaction. It can also implement meaningful behavior with a deliberately simple appearance. Treating fidelity as one slider hides those distinctions.
Choose the necessary detail in each layer. Realistic text may be essential when examining comprehension. Working focus movement may be essential when reviewing a custom control. Decorative imagery may add little to a question about a selection sequence.
Record the choice so reviewers know what they are seeing. A polished screen can create assumptions about functionality, readiness, or available data that the prototype does not support.
Use a representative slice.
The smallest useful slice includes enough context to make the task interpretable. A button in isolation may not reveal whether the visitor knows when to use it. A single screen may be enough if it includes the relevant explanation, choice, and feedback.
Include a plausible awkward example when it matters: a long option name, no selection, a corrected choice, or an instruction that needs more room. These details can reveal design constraints without requiring an entire product.
Label fictional material clearly. A sample service, user, or result should not be presented as evidence of an existing company capability or completed engagement. The prototype is an instrument for a discussion, not a substitute for factual company information.
Observe the question, not the presentation.
A review can drift into a broad critique of every visible detail. Bring it back to the intended uncertainty. Which observation would support one approach, and which would suggest a revision? Record what actually happened separately from an explanation of why it happened.
A demonstration by the person who made the prototype is useful for explaining behavior, but it is not equivalent to independent user research. If a project requires research with participants, plan recruitment, consent, methods, and handling of findings as a distinct activity.
Avoid treating one favorable reaction as a general result. The appropriate confidence depends on the review method and evidence, not on how convincing the prototype looks.
Know when the prototype has done its job.
A prototype can stop when it has made the next decision clearer. The result may be a revised concept, a narrower scope, a production implementation plan, or a decision not to continue. More screens are not automatically more learning.
Keep a short record of the question, the prototype boundary, the observations, and the open decisions. That record helps the next phase use the work without mistaking a focused experiment for a finished product.