Definition
A prototype is an interactive simulation of a product — built in a design tool (Figma) or lightweight code — that allows realistic testing of flows and interactions before engineering effort is committed.
A prototype answers "will this actually work?" before the team commits to building it. It is one rung up from a wireframe (which is static) and one rung below production code (which is real). The prototype is real enough that a user can attempt the task, and unreal enough that throwing it away and starting over costs a day, not a quarter.
Fidelity varies by purpose. A paper prototype tests information architecture in 30 minutes. A clickable Figma prototype tests visual hierarchy and microcopy in a week. A coded prototype tests performance, animation feel, and edge cases in two to four weeks. The right fidelity is the cheapest one that answers the question.
Origin
From Greek prōtos ("first") + typos ("impression") — "first impression" or "original form". The engineering use predates digital products by centuries; software prototyping became standard practice in the 1980s with the rise of GUIs.
How it works
- State the question the prototype must answer (e.g. "will users discover the new search filter?").
- Pick the lowest fidelity that can answer it — paper, clickable Figma, or coded.
- Build only the path needed to test the question; stub everything else.
- Test with 5+ representative users; observe behaviour, not opinions.
- Synthesise findings; revise the prototype or the underlying design assumptions; re-test if needed.
- Ship the changes into the real design once the prototype proves the direction works.
When to use it
Use when
- When testing a new interaction pattern that doesn't exist in the current product.
- When stakeholders need to feel a flow, not just see screens.
- Before committing engineering to a multi-week build of an unproven idea.
- When pitching to investors or executives — a working demo is more persuasive than a slide deck.
Skip when
- For changes that are obviously safe (copy edits, minor layout tweaks).
- When the prototype effort would be larger than just shipping a small experiment to real users.
Key metrics
- Task completion rate in prototype testing.
- Time on task vs. baseline.
- Stakeholder approval velocity (compared to slide-deck reviews).
- Engineering changes after build started (lower = prototype was effective).
Examples
- The prototype let us A/B-test two onboarding flows in a week.
- Investors saw the prototype and committed before the product was built.
- We threw away two prototypes before settling on the third — that's exactly the point.
In practice at Makreate
Makreate prototypes are the bridge between design and development — they de-risk the build by surfacing flow issues at the cheapest possible stage. On a recent fintech engagement we prototyped four competing onboarding flows in Figma, tested all four with target users in two weeks, and shipped the winner. Engineering built one flow instead of four, and the activation rate was 41% better than the existing product on day one.
UX Design →Common mistakes
- Polishing the prototype until it looks shippable — over-polish discourages honest critique.
- Building every screen and every state. Build only the path the test needs.
- Testing with the team. Use external users; the team has too much context.
- Skipping the analysis step. Five tests with no synthesis is five anecdotes, not an insight.
- Treating the prototype as the final design. Production has constraints (state, error handling, real data) prototypes can ignore.
Frequently asked
How long should a prototype take to build?
A clickable Figma prototype for a 5–10 screen flow: 1–3 days. A coded prototype with real interactions: 1–3 weeks. Anything longer means you're building product, not a prototype.
Figma or code?
Figma is faster and disposable, perfect for flow and microcopy testing. Code prototypes are necessary when you're testing animation feel, performance, or interactions Figma can't simulate.
Should prototypes use real data?
When possible, yes. Real data exposes layout edge cases (very long names, empty states, unusual currencies) that placeholder data hides.