The cheapest mistake is the one caught in a prototype.
A prototype is the cheapest place to be wrong. For Scott Sports it was the entire deliverable: a design proposal for the online platform, handed over as something clickable rather than as a deck. A colleague took the experience, I took the interface. On longer projects it does quieter work. Flows go in front of real people before they go into a build, so what reaches development is what survived contact with someone who does not work on it.
Prototypes are cheap arguments. Instead of defending a concept in a slide deck, I put something clickable in front of the people who will use it and let their behaviour settle the discussion.
Four steps, run in short loops rather than one long waterfall.
- 01
Sharpen
The question the prototype has to answer gets written down first. One question, and one that can be answered. Without it, testing produces opinions instead of decisions.
- 02
Build
Real content, believable data, working navigation. Fidelity is set by the question: sometimes paper is enough, sometimes it needs to feel like production.
- 03
Test
Five to eight users is usually plenty. I moderate, the team watches, and everybody leaves the session with the same understanding of what just happened.
- 04
Decide
Findings, a recommendation and a revised prototype. The output is a decision with evidence behind it, not a document nobody reads.
A prototype is a question made clickable. I build them just real enough to get honest answers: real content, believable data, true motion.
The same prototype aligns stakeholders, tests with users and briefs development. One artefact, three jobs.
Not every project needs all of it. These are the parts.
Clickable flows in days: real content, real navigation, realistic data. Enough fidelity to get honest reactions before a line of production code exists. Fidelity is set by the question rather than by habit, so sometimes a rough flow is enough and sometimes it has to feel indistinguishable from the finished product.
A focused week from question to tested concept: map, sketch, decide, prototype, test, with stakeholders in the room and evidence on the wall by Friday. Sprints work because they force the expensive decisions into daylight early, with the people who can actually make them present.
Moderated sessions, unmoderated panels and quick guerrilla rounds, matched to the question and the budget, always ending in decisions rather than a list of findings. I write the script, recruit the participants, run the sessions and cut a short highlight reel so the insight survives the meeting.
Prototyped transitions and easing curves that define how the product should feel, handed to developers as specs they can actually implement. Motion is easier to agree on when you can watch it than when it is described in a document, and specifying it properly keeps the built version from drifting.
