Your prototype is an argument, not an artifact

There is a particular kind of prototype that eats a week and settles nothing. It is beautiful. Every screen is polished, every transition eased, every state accounted for. It gets shown, everyone admires it, and then the same open questions that existed before the prototype are still open after it. The work went in. The decision did not come out.

The problem is a category error, and it is in the name people give the thing. A prototype treated as an artifact, a small finished product to be admired, is aiming at the wrong outcome. A prototype is an argument: a thing built to settle a specific disagreement, convince a specific room, or reduce a specific unknown. Get clear on which argument you are making, and the prototype gets faster, cheaper, and far more useful.

Fidelity is a cost

The instinct that fidelity is always good is where most prototyping time goes to die. High fidelity feels like progress, because it looks more like the real thing, so it must be closer to done. But every bit of polish is time spent, and time spent on the wrong question is just expensive procrastination that photographs well.

Fidelity should be a deliberate choice matched to the argument, not a default you climb toward. If the open question is whether the flow makes sense, a grey-box clickthrough answers it as well as a pixel-perfect one, in a fraction of the time. If the question is whether a micro-interaction feels right, then you need real motion and real timing, but only there, on the one screen where the feeling is the argument. Polishing the other twelve screens to match is decoration charged to the project's clock.

Name the argument first

Before building anything, the useful question is narrow: what exactly is this prototype trying to prove, and to whom? The answer decides everything about how to build it, and usually reveals that you need far less than you were about to make.

Proving the flow is coherent is an argument to yourself and the team, and it needs breadth at low fidelity: every step present, none of them pretty. Proving an interaction feels responsive is an argument to your own judgment, and it needs depth at high fidelity on exactly one moment. Proving to a skeptical stakeholder that a direction is worth funding is a persuasion argument, and it needs just enough realism on the one flow that carries the pitch, not the whole product. Three different arguments, three completely different prototypes. Building the same maximal prototype for all of them is how a week disappears.

Build it to be thrown away

The last shift is the hardest to accept: the best prototypes are disposable, and treating them as precious is a trap. Once a prototype has settled its argument, whether the flow works, the interaction feels right, or the stakeholder said yes, its job is done. Its value was the decision it produced, not the file it left behind.

The trap is that a beautiful prototype feels too valuable to discard, so teams try to grow it into the real thing. Sometimes that is fine. Often it drags prototype-grade shortcuts into production, because the thing was built to make an argument quickly, not to be maintained. Holding a prototype loosely, and being willing to bin it the moment it has served its purpose, is what keeps it honest and fast. A prototype you are afraid to throw away is a prototype you built too carefully.

Takeaways

Before you open the tool, write one sentence: what is this prototype trying to prove, and to whom. Match fidelity to that argument: broad and rough for a flow, deep and real for a feeling, just enough realism for a pitch. Refuse to polish anything the argument does not need. Put the high fidelity on the single moment that is the argument, and leave the rest grey. And when the argument is settled, let the prototype go. Its output was the decision, not the file.

A prototype is not a small product. It is a question, made just concrete enough to answer. Build it to answer the question, and nothing more.