Why We Prototype Ideas Before Code

A client once described a feature to me for twenty minutes with complete fluency. He knew what it did, who it was for, why it mattered. Then I asked him to draw it. He drew a box, hesitated, drew another box, and stopped. We sat with that for a while. Eventually he said: I think there are two different features here and I have been describing them as one.

Twenty minutes of articulate speech had concealed a structural confusion that ninety seconds with a pen exposed. This happens so consistently that I now treat it as a property of language rather than an accident. Speech is forgiving. It permits vagueness to pass as understanding, because the listener does the work of assembling meaning and neither party notices the assembly happening.

Speech lets vagueness pass as understanding. A drawing does not have that mercy.

What a prototype is for

The word gets used for two unrelated activities. One is building an early version of the real thing, to test it. The other — the one I mean — is constructing a cheap artifact whose only purpose is to answer a question you cannot answer by thinking.

That distinction determines everything about how you build it. If the prototype is an early product, you care about it working and you are reluctant to throw it away. If it is an instrument, you care only about the answer, and the correct fate of the artifact is the bin.

The most useful prototypes I have made were made of nothing. Paper. A written narrative of a user's first session. A spreadsheet standing in for a system. A conversation where I played the software and the client played themselves, out loud, which is absurd and works alarmingly well. None took more than a day. Several changed what got built.

State the question first

A prototype without a question is just unstructured building, and it will teach you whatever you were already inclined to believe. Before making anything, I write down what I am uncertain about, in one sentence, in a form that could be answered.

Will someone understand what this is within ten seconds. Is this three steps or seven. Does the value survive when the data is messy. Would a person actually do this thing at the moment we are assuming they would. These are answerable. Is this a good idea is not, and prototypes built to answer it produce only opinions.

Writing the question also reveals when you do not have one, which is a useful thing to discover before spending a week. Sometimes the honest answer is that nothing is uncertain and you should simply build the thing.

The fidelity trap

There is a strong pull toward making prototypes look finished, and it has become stronger now that finished-looking things can be produced in an afternoon. It is almost always a mistake.

Polish changes the feedback you receive. Show someone a rough sketch and they tell you the idea is wrong. Show them a polished screen and they tell you the button should be blue. People are considerate; they respond to the apparent stage of the work, and if the work appears nearly done they will not raise the question that would require starting over. The roughness is not laziness. It is an invitation to say difficult things.

Polish also changes you. Anything you have made carefully becomes harder to discard, and a prototype you cannot discard has stopped being an instrument and become a commitment you made before you had the information.

Show a sketch and people tell you the idea is wrong. Show a finished screen and they tell you the button should be blue.

Prototyping the idea, not the interface

Most prototyping effort goes into interfaces, but the more consequential uncertainties usually sit underneath. Whether the concepts hold together. Whether the workflow matches how people actually spend their day. Whether the economics work when you write out the numbers rather than gesture at them.

Those can be prototyped too, and more cheaply. Write the pricing page before building the product; if you cannot explain the value in a paragraph, the paragraph is the problem. Write the launch announcement first and see whether it is interesting. Write the help article for the hardest feature and notice how long it becomes. Each of these is a prototype of the idea, and each one has saved me more work than any interface mock ever did.

Why this matters more, not less, now

The obvious objection is that building has become so cheap that prototyping is redundant. Just make the real thing and look at it.

I understand the reasoning and I think it is backwards. When building was expensive, its cost imposed deliberation. Now that it is cheap, nothing imposes deliberation, and the danger has shifted from building too slowly to building the wrong thing at high speed and then defending it because it exists.

A generated product also arrives looking finished, which triggers the fidelity trap immediately. You have skipped the rough stage entirely — the stage where the real questions get asked — and gone straight to a state where feedback is about buttons.

So the practice survives, and its purpose has narrowed usefully. Prototyping is no longer about seeing what something looks like; you can have that in minutes. It is about finding out what you believe before you spend anything defending it. That has never been cheap, and no tool has yet made it so.

If there is an idea you have been describing fluently for a while, it may be worth drawing. I am glad to sit down with a pen and find out what happens.