Refract Group2026
Glossary
Prototype
A prototype is a model of a product, or part of one, built to answer a specific question before the real thing is built. It includes only what that question depends on, and the rest can be faked.
- Paper sketchOrder of steps
- Clickable screensNavigation
- Coded, in the browserReal content
- Live product (MVP)Repeat use
Prototype in detail
- Also called
- Clickable prototype, Interactive prototype, Paper prototype
- Topic
- Product
- Updated
What it is
Nielsen Norman Group calls a prototype a hypothesis: one candidate answer to a design problem, made concrete enough that someone can try it. It can be a sequence of sketches on paper, linked screens in a design tool, or a coded version running in a browser. How close it comes to the finished product is its fidelity, and the right fidelity is the lowest one that still answers the question.
What a prototype leaves out matters as much as what it contains. A payment screen can look finished while no payment is taken. A dashboard can run on sample data with no integration behind it. Those gaps are fine as long as everyone knows where they are, so the list of what is simulated belongs next to the prototype, and the code is usually thrown away once the question is answered.
Why it matters
Engineering time is the expensive part of software. A prototype lets a team watch a customer try a new setup flow in an afternoon, before anyone writes the version that has to be secure, fast and maintained. When it fails, the cost is a few days of design. When it works, the team starts the build with evidence, a clearer scope and fewer arguments about which option to pick, because they have seen people use one.
How we do it
In product work we map the flow first and prototype the decisions that carry the most uncertainty. We get a working screen into the browser early, because people argue less about something they can click.
Our product sprint puts one in front of users in a week. We audit what exists, prototype the flow in a browser on the client’s own content, test it with their users and finish with a plan for the next build. Real content matters because tidy sample data hides the name too long for its field and the account with four hundred records. We agree the prototype’s format with your team before we start, and judge the result by a measure tied to the task, since a polished prototype is not evidence on its own.
An example
Say a scheduling product wants to let managers swap two staff members’ shifts in one step. The team builds a clickable version on a copy of one customer’s real roster, with no back end at all, and five managers try it. Four of them look for the swap inside the shift itself, where the prototype had put a separate menu. The team moves it, tests again and only then estimates the build.
Common mistakes
- Treating a good demo as proof. A prototype that impresses an investor shows that the idea can be understood, and says nothing about whether customers will pay for it or come back.
- Building more than the question needs. Polish takes time and makes people reluctant to change the design, so every screen beyond what the test depends on slows the learning down.
- Filling it with tidy sample data. Neat placeholder records hide the long names, the empty accounts and the four hundred rows that break a real screen.
- Shipping the prototype’s code. Prototype code takes shortcuts on purpose, and keeping every one of them in production usually costs more than rebuilding the part that was proven.
Prototype vs MVP
A prototype is a model built to answer one question and can fake whatever the question does not depend on, while an MVP is a first usable product that real users rely on to finish a real task.
| Prototype | MVP | |
|---|---|---|
| Built to | Answer one design question | Deliver one complete task |
| Used by | Test participants, for a session | Real users, repeatedly |
| Can fake | Data, integrations, payments | Little that users depend on |
| Proves | People understand the flow | People come back and use it |
Questions
What people ask about prototype.
A prototype answers a question, such as whether people understand a new flow, and can simulate anything the question does not rely on. An MVP is the first version of a product people actually use, so it needs a complete core task, real data handling and a way to catch failures.
A low-fidelity prototype is rough: sketches or plain screens that are quick to make and easy to change during a test. A high-fidelity prototype looks and responds close to the finished product, which suits testing detailed interactions but takes longer to build. Choose the fidelity by the question you need the prototype to answer.
Sometimes a coded prototype can, but check it first. Review its architecture, accessibility, security and data handling before relying on it in production, because a prototype is usually built with shortcuts. It is often cheaper to keep what the test proved and rebuild that part properly.
Where this shows up in our work
Related terms
Working on this now?
Tell us what you’re building and where it’s stuck. We reply within 12 hours.
Most teams start with a call, then a sprint or an audit.
The people you’d work with, from the first call to launch