The Fundamental Problem
A spec describes what something should do. A prototype shows what something does. The difference seems subtle but it's everything.
Specs require readers to imagine the experience. Prototypes let users feel it. Imagination is unreliable. Feeling is data.
What Specs Can't Capture
Timing. The difference between 200ms and 400ms feedback delay changes how an interaction feels. You can write "fast feedback" in a spec, but you can't know if 200ms is fast enough until you feel it.
Cognitive load. A screen might look simple in a mockup but feel overwhelming in use. The spec can't predict which element users will look at first, or whether they'll understand the hierarchy.
Muscle memory. Gesture-based interfaces depend on physical intuition. No amount of documentation can predict whether a swipe will feel natural or awkward.
The Prototype Advantage
Prototypes create shared understanding. Instead of debating what "intuitive" means, you watch users interact. Instead of arguing about timing, you measure it.
Prototypes surface problems early. A spec might pass review and fail in production. A prototype fails in your hands, not your users'.
Prototypes accelerate decisions. "Does this work?" becomes answerable in hours, not weeks.
SPEC
- → Describes intent
- → Requires imagination
- → Fails in production
PROTOTYPE
- → Demonstrates behavior
- → Creates experience
- → Fails in your hands
When Specs Work
Specs aren't useless. They're useful for documentation after validation, for communicating decisions to stakeholders who weren't in the room, for creating a record of what was built and why.
But specs should follow prototypes, not precede them. Document what you've validated, not what you hope will work.