A prototype should answer one question

Prototypes have a way of getting dressed up like products before they have earned it.

The navigation works. The empty states are written. The settings screen has a tasteful toggle. Someone has spent an afternoon deciding whether the corner radius should be ten or twelve pixels. The prototype looks complete, which makes everyone feel productive, but the important question is still sitting there unanswered.

This usually happens because we ask a prototype to prove too much. We want it to confirm the idea, the flow, the visual direction, the business model, and whether people will come back. That is not a prototype. That is a small product carrying the expectations of a large one.

I get better results when I write the question before I make the screen.

Can someone understand which critique issue matters most? Can a designer feel the difference between two spring settings? Can a parent decide whether a place will work today without opening six more tabs?

Those are prototype questions. They describe one person, one moment, and one uncertain decision. They also tell me what has to be real.

If I am testing motion, the motion cannot be a placeholder. The surrounding interface can be ugly, the data can be fake, and the button can go nowhere, but the thing I am asking someone to feel has to actually move.

If I am testing comprehension, the words and hierarchy have to be real. A polished shell filled with lorem ipsum cannot tell me whether the explanation works. If I am testing a flow, the backend might be disposable, but the sequence and consequences cannot be.

Fidelity is not a level applied to the whole prototype. It is a decision about where truth is required.

The rest should stay visibly unfinished. That is not sloppiness. Rough edges protect the experiment from accidental conclusions. They remind everyone that this object exists to learn something, not to win approval as a miniature launch.

A useful prototype also needs the possibility of failure. If every reaction can be interpreted as validation, there was never a real question. I want to know what would make me stop, change direction, or narrow the idea further before I begin.

The prototype is finished when the uncertainty changes. Sometimes the answer is yes. Often it is not yet, or only for this audience, or the interaction works but the premise does not. Those are good results. The point was never to make a convincing object. The point was to make the next decision less imaginary.