comparison 4 min read
How to choose a prototype for the question you need to answer
Choose a product prototype by the uncertainty it must resolve, from a simple concept sketch to a realistic workflow, and define what its results can support.
THE SHORT ANSWER
What you need to know
Choose the least detailed prototype that can answer the next product question credibly. A sketch can test understanding, while a realistic sequence may be needed to examine task completion. Match the prototype’s content, interaction, and context to the uncertainty. State which questions it cannot answer so feedback does not become accidental proof of demand or delivery readiness.
Key takeaways
- Define one primary uncertainty before choosing fidelity.
- Use realistic information for the task being tested.
- Separate interface learning from demand and feasibility.
- Record what the prototype deliberately leaves unresolved.
Match fidelity to the decision
Prototype fidelity is not a ladder that every team must climb. It is a choice about which details need to behave realistically for the question to be answered. A team exploring a shared meal-planning service might first need to know whether people understand who chooses meals and who buys ingredients. A simple sequence of screens can expose that confusion. If the question becomes whether users can adjust a plan around unavailable ingredients, the prototype needs realistic choices and consequences. Adding visual polish before clarifying the decision can make the team slower without making the evidence more useful.
Recreate the relevant task conditions
Use content that resembles what participants would actually handle. Empty cards and friendly sample names rarely reveal how someone manages conflicting preferences, long notes, or a missing item. In the meal-planning example, include a plausible dietary constraint and an unavailable ingredient, while avoiding unnecessary sensitive details. Give participants a goal rather than instructions for which controls to click. Observe their route and interpretation. If the prototype does not support a possible action, note the limitation instead of attributing every failure to the participant or the proposed concept.
Keep the learning categories separate
A participant completing a prototype task offers evidence about that interaction under the test conditions. It does not automatically show that they will adopt the product, that the team can obtain reliable ingredient information, or that the service will remain useful. Label the question being tested and place other observations in a separate queue. When someone asks whether a feature will exist, explore why it matters without promising delivery. Clear boundaries allow useful prototype feedback to inform design while leaving commercial and technical questions available for their own investigations.
Review behavior before visual preference
After a session, summarize what the participant understood, attempted, completed, and questioned. Compare those observations with the intended task and the prototype’s limitations. A confusing responsibility model may need a different workflow, while an unclear label may need a small revision. Avoid treating requests for more detail as a reason to build everything. The action checklist is to name the decision, choose necessary fidelity, prepare realistic content, define the task, observe behavior, and record limitations. Build the next prototype only when it serves a clearer question than the current one.
Prepare a short limitation note for the moderator before testing. In the meal example, ingredient availability may be invented while responsibility and editing are being investigated. If a participant questions availability, capture it as a separate issue and explain the test boundary. This keeps the session honest and prevents a realistic-looking detail from being mistaken for a capability the team has already established.
A useful prototype result should lead to a commitment, not indefinite polishing. Review whether the evidence is sufficient to proceed, narrow the direction, or investigate one remaining risk.How to decide when to stop product discovery
Common questions
When is a clickable prototype necessary?
Use one when sequence, navigation, or the consequence of an action affects the question. If the uncertainty concerns the offer’s meaning, a static concept may be sufficient.
Should prototypes look like the final brand?
Only when visual presentation is relevant to the decision. Otherwise, enough consistency to support comprehension is useful; elaborate styling can distract from unresolved workflow questions.
Can a prototype be used with an existing customer?
Yes. Set expectations about what is experimental and observe a realistic task. Familiarity with the current service should be recorded because it can shape their interpretation.
References & further reading
These primary references support the background. The practical frameworks and illustrative examples are written for this guide.
Prepared with AI assistance. Examples are illustrative; no client results are implied. Read our editorial approach.