A prototype is a question, not an answer.

A successful prototype can leave the central uncertainty untouched. What a test means depends on the question and the help supplied along the way.

A person completes a prototype without hesitation. The team takes that as a good sign. Then someone points out that the maker explained the task immediately before the test. What, exactly, did the team learn?

Perhaps the sequence works once someone knows where to start. That is useful information. It does not establish that a customer would recognize the need, choose the product, or understand the sequence without an introduction. A successful test can leave the central question untouched when the question was never stated clearly.

Which decision can the test inform?

Before building, connect the uncertainty to a decision. If someone cannot find the right record without help, the team might need to change the navigation before implementing more screens. If they can find it but do not want to use the service, another navigation test will not answer the adoption question. Write down which choice the observation is supposed to inform.

The prototype's finish follows that uncertainty. Rough screens may be enough to test a sequence. They may be inadequate for understanding whether someone would trust an unfamiliar service with important work. More polish is useful when it removes a distraction from the test; it is wasteful when it makes an unanswered question feel settled.

The maker's presence matters too. A person can continue because stopping would feel impolite. They can ask for help because help is available, or understand a step because of a comment made earlier. Observing a pause, a workaround, or a mistaken assumption can tell the team something a compliment cannot. The observation still needs interpretation in the context of the test.

Deciding beforehand what would make the team reconsider protects the test from attachment. It should not mean declaring the whole idea disproved by one person's hesitation. The observation may expose a confusing label, an unsuitable participant, or a wrong assumption about the need. Work out which explanation the test can distinguish before drawing a larger conclusion.

What remains open

The useful record is narrower than "people liked it." It says who attempted which task, what help they received, what happened and which decision that supports. It also says what the test leaves open. A team can proceed with limited evidence while remaining honest about those limits.

A prototype earns its time when that account helps the team choose the next step: implement, revise, investigate something else, or stop. If the team cannot name a result that would change what it builds next, it has scheduled a demonstration rather than a test.

Even a finished implementation leaves that possibility open. Customers may work around a feature that performs exactly as designed. We find something reassuring in treating a prototype as an inquiry we can continue, rather than a verdict we have to defend. The work can become more dependable while our understanding of its usefulness is still changing.