Most prototypes fail because they try to be the product. They get polished, reviewed, argued over, and eventually shipped half-finished. A prototype has one job: answer a single question, then get thrown away. The throwing away is the point, not the failure.
One question
Before you open Figma or your editor, write the question down. “Does this onboarding feel too long?” “Can a user tell these two states apart?” One question, one prototype.
If you can’t name the question, you’re not prototyping — you’re building. Vague goals produce prototypes that never end, because there’s no moment where they’re clearly done.
The fidelity ladder
Match effort to the question. Climbing higher than you need is the most common way to burn a week.
- Paper or a whiteboard: is the flow right?
- Figma clickthrough: does the layout make sense?
- Coded prototype: does the interaction feel good at real speed?
- Real-data build: does it hold up with long, messy, empty content?
Start on the lowest rung that can answer your question. A flow problem doesn’t need React, and a 200ms timing problem can’t be felt in a static frame.
Throwaway is the point
Prototype code should be fast and ugly. Hard-coded arrays, no tests, no error handling, one big file. You’re buying an answer, not building an asset.
The trap is falling for code that was never meant to last. When the question is answered, delete it and rebuild clean. The knowledge survives; the code shouldn’t.
The rule
One prototype, one question, the lowest fidelity that answers it, deleted when you’re done. Write the question at the top of the file so future-you remembers what you were actually testing. Answer it, keep the lesson, throw the code away, and move on.