Cheap Enough to Throw Away: Prototyping

Two designers, one week, the same brief.

The first spends it on a single screen: real content, exact spacing, a shadow tuned over an hour, three rounds of self-critique. By Friday it's genuinely beautiful.

The second spends Monday sketching five different structures on paper, shows them to four colleagues, throws away three, builds a rough clickable version on Tuesday, tests it with three people on Wednesday, discovers the whole flow assumes something users don't have, rebuilds it on Thursday, tests again on Friday.

The first has a beautiful answer to a question nobody checked. The second has an ugly answer to the right one. Only one of those is fixable in the remaining time.

A prototype is a question

The most useful habit in this whole area: write the question above the prototype before you build it.

"Will people understand that these two things are connected?" "Do they look for this in the menu or on the object itself?" "Is three steps acceptable, or do they abandon at two?"

If you can't state the question, you aren't prototyping — you're producing a picture. That's a legitimate activity, but it's presentation work, and confusing the two is how weeks disappear.

The question also determines everything else: what fidelity you need, how many people, and — crucially — what would count as a bad answer. Decide in advance what result would make you change the design. Otherwise you'll get the answer you brought.

The fidelity ladder

Fidelity isn't a measure of quality. It's a dial you set according to the question.

Sketch on paper. Answers: what are the possible structures? Minutes each. The right medium for generating options, because it's fast enough to make five and cheap enough to bin four.

Paper prototype. Answers: does the flow make sense? Screens on paper, a person "runs" the interface by swapping sheets when the tester taps.

Wireframe. Answers: is the structure and hierarchy right? Boxes, real text, no styling. Real text matters — lorem ipsum hides every problem that words cause.

Clickable prototype. Answers: can people complete the task? Linked screens with the main path working. This is where most usability testing happens.

High-fidelity prototype. Answers: does it feel right? Real visuals, motion, states. Necessary for judging perceived performance and micro-interactions, and useless for judging structure — by now nobody will suggest changing it.

Coded prototype. Answers: what happens with real data, real latency, real devices? The only fidelity that reveals what forty-character names, slow networks and actual database contents do to your design.

Two rules govern the ladder. Only go as high as your question requires — a question about structure answered with a polished prototype has cost you five times what it should. And go up only after the level below has survived contact with people.

Rough things get honest answers

Marc Rettig's 1994 paper "Prototyping for Tiny Fingers" made the argument that still holds: paper prototypes find most of the same usability problems as working software, at a tiny fraction of the cost.

But the deeper reason to stay rough early has nothing to do with cost. It's about what people will say to you.

Show someone a sketch and they'll say "this bit doesn't make sense, why would I do that here?" Show the same person a polished screen and they'll say "looks great, maybe the button could be a bit bigger." Polish reads as finished, and criticising something finished feels like an attack on someone's work rather than help with a decision. You've made the interface look expensive, and the honesty went away with the pencil lines.

Roughness isn't a shortcut. It's what buys you honest answers.

Faking the expensive part

Two techniques for testing things you can't afford to build.

Wizard of Oz. A person behind the curtain does what the system would do. The user believes it's automated; a colleague in another room is typing the answers. Invaluable for anything expensive or slow to build — automated matching, recommendations, an assistant that answers questions. You learn whether the interaction works before spending months on the engine that would power it.

Fake door. Put the entry point for a feature in the real product and measure how many people try it, then show an honest "this isn't ready yet — want to be told when it is?" A cheap read on demand. The ethical line matters: never let anyone believe they've completed something they haven't, never take money or data for a thing that doesn't exist, and always close the loop with the people who clicked.

Why you must stay able to throw it away

Dan Ariely, Michael Norton and Daniel Mochon documented the IKEA effect in 2012: people value things they assembled themselves far above their objective worth. Add ordinary sunk-cost reasoning, and you get the mechanism that quietly ruins design processes.

The more hours you've put into a prototype, the less capable you become of hearing that it's wrong. Not because you're stubborn — because the evaluation is genuinely distorted. And the sequence is predictable: the more polished it is, the fewer objections people raise; the fewer objections, the more confident you get; the more confident, the more you polish.

The counter-rule is worth memorising: fidelity should lag conviction. Raise the polish only after evidence, never in the hope of getting some.

A practical version: build the second version rough too. First versions get thrown away naturally; the dangerous attachment forms around the one you fixed.

Prototype the risk, not the easy bit

The strongest instinct is to prototype the screen you already know how to draw. Resist it.

Ask: which assumption, if wrong, kills this? Usually it's not the visual design. It's whether people will hand over that data, whether they'll understand the core concept, whether the task is worth the number of steps it needs, whether they have the information the first screen demands.

Prototype that. It'll be an uglier week and a shorter project.

A prototype is also an argument

There's a second job prototypes do that documents can't. A ten-page specification produces ten opinions; a clickable prototype produces a decision, because everyone is finally looking at the same thing.

One caution. A high-fidelity prototype reads as a promise — to stakeholders it looks like software that already exists, and expectations calibrate to it. Say out loud what's fake, what data is invented, and what would actually take three months. Designers have lost more credibility to that misunderstanding than to any bad design.

In practice

Write the question at the top of the file. Literally, in the canvas. If you can't fill it in, stop and think before drawing.

Decide the failing result in advance. "If two of five can't find it, we restructure." That single sentence is what makes a test a test.

Use real text, never lorem ipsum. Real names, real lengths, real error messages. Half of all layout problems are text problems in disguise.

Sketch five before refining one. On paper, ten minutes each. The first idea is rarely the best, and it's certainly not comparable to anything yet.

Test the ugly version deliberately. When you catch yourself polishing before showing, that's the signal to show it now.

Fake the expensive feature before building it. A human behind the curtain for one afternoon beats three months of engineering on a guess.

Check yourself

Close the article and answer in your own words:

What must be written above a prototype, and what happens without it?
Match the fidelity levels to the questions they answer.
Why do rough prototypes get more useful feedback than polished ones?
What is a Wizard of Oz prototype and when is it the right tool?
Where's the ethical line on fake-door tests?
What is the IKEA effect and what rule does it imply about fidelity?
Which part of a design should you prototype first, and why isn't it the easy screen?

In short

A prototype is a question. Write the question above it and decide in advance what result would change your mind.
Fidelity is a dial set by the question: sketches for options, paper for flow, wireframes for structure, clickable for tasks, high-fi for feel, code for real data.
Rough prototypes get honest criticism; polished ones get compliments. Roughness buys candour, not just speed.
Wizard of Oz fakes the expensive engine with a person; fake doors measure demand — both need honesty with participants.
The IKEA effect and sunk cost make you deaf to problems in what you've polished. Fidelity should lag conviction.
Prototype the assumption that would kill the project, not the screen you already know how to draw.
A prototype settles arguments a document can't — but a high-fidelity one reads as a promise, so say plainly what's fake.