How to evaluate a prototype without polishing away the question

An attractive demonstration may win compliments while leaving the riskiest assumption untouched. Conversely, a rough prototype may produce useful evidence if participants can understand the task and encounter the relevant choice.

Choose the uncertainty first

GOV.UK’s alpha-phase guidance recommends using prototypes to test risky assumptions. A startup should state that assumption before deciding which screens to build.

If the question concerns whether users understand an approval step, a limited interactive flow may be enough. If it concerns integration reliability, a visual mock-up cannot answer it.

An illustrative procurement startup could test whether staff distinguish requesting an item from authorising expenditure. Animations and polished charts contribute little until that distinction works.

Avoid rescuing every participant

Give a realistic task and observe how the participant proceeds. Intervene when necessary for safety or clarification, but record the assistance. A successful task completed through founder coaching is different from independent completion.

Explain which parts are simulated. Do not let a participant assume the prototype has processed a real payment or changed an operational record.

Capture misunderstandings before offering the intended explanation. Once the founder teaches the interface, the session no longer represents a first encounter.

Use the result to change a decision

At the end, compare the evidence with the original uncertainty. Decide which idea to develop, revise or stop. A prototype that produces no product decision may have served as a sales asset rather than a research instrument.

Preserve unresolved technical questions separately. Participants liking a workflow does not establish that it can be built or delivered economically.

Prepare a one-sentence test question and read it before every prototype session. If observers begin judging visual polish or asking for unrelated features, return to that question. Additional findings can be recorded, but they should not silently replace the uncertainty that justified the prototype and its evaluation method.

The right fidelity is the least complexity that yields dependable evidence for the decision. That discipline helps a small team spend its limited development time on learning rather than demonstrating confidence it has not yet earned.