What is prototyping in product design?
Prototyping is the practice of building interactive models of a product, from clickable wireframes to fully coded prototypes. They let a team test an idea with users and stakeholders before development spends real money. A prototype exists to answer a question cheaply: it makes a design decision testable, and reversible, while being wrong still costs almost nothing.
Why prototype before building?
Because development is where mistakes become expensive. A flaw caught in a clickable prototype costs a revision. The same flaw caught after launch costs a rebuild, and takes a support queue and a sprint plan down with it. Prototyping moves the risk forward, to the one stage of a project where changing course is measured in hours rather than releases.
A prototype also changes the conversation. Stakeholders stop debating descriptions and start reacting to a thing. Users stop imagining an interface and start attempting tasks on one. Feedback sharpens the moment there is something to touch. And because nothing about a prototype is precious, criticism lands as information.
What is the difference between low-fidelity and high-fidelity prototypes?
Low-fidelity prototypes are deliberately rough: sketches, wireframes, grey boxes with honest labels. The roughness is a feature: nobody hesitates to criticise a sketch, so structural problems surface while structure is all there is to fix. High-fidelity prototypes look and behave like the finished product, with real copy, plausible data and working interactions. They answer what roughness cannot: does the density read, does the motion explain, does the whole feel trustworthy.
The mistake is choosing fidelity once, for the whole project. It is a dial, set per question. Polish changes what people tell you. Once a screen looks settled, the notes drift from whether the flow works to whether the styling pleases.
Fidelity by question
- The question
- Is the sequence of steps right?
- The right fidelity
- Boxes and arrows
- Usually built in
- Whiteboard or FigJam
- The question
- Does the layout survive real data?
- The right fidelity
- Real records at full volume
- Usually built in
- Figma or HTML
- The question
- Do users trust the wording?
- The right fidelity
- Real copy, real numbers
- Usually built in
- Figma or HTML
- The question
- Does the motion explain itself?
- The right fidelity
- Working interaction
- Usually built in
- Code
| The question | The right fidelity | Usually built in |
|---|---|---|
| Is the sequence of steps right? | Boxes and arrows | Whiteboard or FigJam |
| Does the layout survive real data? | Real records at full volume | Figma or HTML |
| Do users trust the wording? | Real copy, real numbers | Figma or HTML |
| Does the motion explain itself? | Working interaction | Code |
Has AI changed prototyping?
Yes, at the top of the ladder. A working prototype in the browser was the rung most projects never reached, because someone had to hand-build it first. AI-assisted coding does the repetitive part of that build, so a fidelity we once had to ration is available early. Everything it produces still passes a senior designer or engineer before anyone outside the team sees it.
That buys more polish if we want it. The better purchase is more directions: two or three concepts alive at once, and several iterations of each. Each round proves or kills the assumption underneath it, and works a rough idea into an interaction worth keeping. Roughness is still right for structural questions. It is no longer the cheaper option, so we choose it for what it does to the feedback.
How do you prototype?
- 01
Name the question
Every prototype starts as a written assumption: who the user is, what they are trying to do, and what result would prove the idea wrong. If failure isn't possible, we rewrite the question until it is.
- 02
Choose the fidelity
Sequence questions get boxes and arrows. Density questions get real data, and trust questions get real copy. Where two directions are both plausible, we build both and let the test settle it.
- 03
Build it fast
Clickable within days rather than weeks, because a prototype's value starts the moment someone outside the team can touch it. AI-assisted coding is what keeps a second and third version inside the same window.
- 04
Test it with users
Participants who match your users attempt genuine tasks against the prototype. What they do, not what they say, and not what we hoped, decides what the next revision changes. Where recruiting participants is out of budget, the archetypes the research produced stand in, and someone walks the prototype as one of them, step by step, looking for where they would stall. That produces a considered guess rather than an observation, and it is worth knowing which of the two a decision rests on.
- 05
Decide and record
Each round ends in a decision: proceed, revise, or retire the idea. We write the evidence down, so the build that follows inherits answers and not opinions.
Where we stand on Prototyping
- 01A flaw caught in a prototype costs a revision. The same flaw caught after launch costs a rebuild.
- 02A prototype that only works when driven in the right order can only produce applause. Applause is not evidence.
- 03Fidelity is a dial set per question, not a setting the whole project shares.
- 04AI-assisted coding removed the penalty high fidelity used to carry. The better purchase is more directions, not more polish.
- 05Every prototype starts as an assumption that could be proved wrong, and ends in a decision written down.
Work featuring Prototyping
SBS-ED
Stellenbosch Business School Executive Development Website
A new website for the executive education arm of Stellenbosch University's business school
Web DesignContent Management SystemContent DesignPrototyping
Travelstart
Online Flight Booking Platform
Product design for one of South Africa's leading travel booking platforms.
Platforms & SaaSMobile AppPrototyping
The London Practice
Psychotherapy Practice Website
A website for a London psychotherapy practice, built around finding the right practitioner.
Web DesignContent Management SystemBrand AuditDesktop ResearchPrototyping
What’s included in Prototyping?
- Clickable wireframes
- Grey-box screens wired together so a flow can be walked end to end.
- Interaction & motion prototypes
- Working motion and transitions built to be judged in the browser rather than described in a comp.
- Coded prototypes
- Working software in the browser, with real data, real latency and real motion.
- Technical proof of concept
- A build made to answer whether a thing is possible in the stack, separately from whether it is desirable.
- Design sprints
- A week from question to tested prototype: map, sketch, decide, build, test.
- Concept validation
- Prototypes aimed at the riskiest assumption in an idea, run before anyone scopes a first release.
Final questions
What is the purpose of a prototype?
To settle a specific question about a product while the answer is still cheap to act on. A prototype lets a team watch real users attempt real tasks, gather evidence about what works, and catch flaws while they are still quick to fix. Debate about how a design might behave gives way to observation of how it does.How long does prototyping take?
Days to weeks, set by the question and the fidelity it needs. A clickable wireframe answering a structural question takes a few days to build and test. A coded prototype with real data and motion takes a week or more. A prototype that runs much longer is usually answering several questions that should have been split apart.Prototype vs MVP: what is the difference?
A prototype is a disposable model built to answer a question. An MVP is a real product built to be used. A prototype is cheap by design, with nothing behind it and everything open to revision. An MVP carries production code, live data and actual users, and must hold up from day one. Prototype until the big questions are settled, then let the MVP earn its keep in the market.Do you test prototypes with real users?
Yes, where the budget permits it. A prototype that is never put in front of anyone is a rehearsal, not a test. We run moderated sessions where participants who match your users attempt real tasks against it, and their behaviour ranks what the next revision must fix. Where recruiting participants is out of budget, we walk the prototype as the archetypes the research produced, looking for where each of them would stall. That is weaker than watching someone do it. Testing is how prototyping pays for itself.What tools do you prototype in?
Figma and code, chosen per question. Figma is fastest for structure, flows and layout, and its clickable prototypes are ready for testing within days. Code is more honest than any design tool about how a design behaves under realistic data, with real inputs and interactions. Questions of feel and performance graduate to a coded prototype in the browser.