How to create prototypes that test your assumptions without overinvesting. Fidelity levels, prototyping methods, and when to use each one.
A prototype is not a product. It is a question in physical or visual form. You build a prototype to learn something specific, not to demonstrate how polished your design skills are.
This is the most misunderstood stage in design thinking. Teams consistently over-invest in prototypes, spending weeks on high-fidelity mockups when a paper sketch would have answered the same question in an afternoon. The rule of thumb: build the cheapest thing that will test your riskiest assumption.
After ideation, you have one to three promising concepts. But concepts are abstract. You need to make them tangible enough that real people can react to them.
A prototype serves three purposes:
Fidelity refers to how closely the prototype resembles the final product. There is no "right" fidelity level. The right level depends on what you are trying to learn.
Paper prototypes are hand-drawn screens or physical models made from cardboard, paper, and tape. They look rough on purpose.
Use low fidelity when:
Low-fidelity prototypes have a hidden advantage: people give more honest feedback on rough work. When something looks polished, testers feel bad criticizing it. When something looks like it was sketched in five minutes, they feel free to say what they really think.
Wireframes are digital layouts that show structure and flow without visual design. Clickable mockups (using tools like Figma, Sketch, or even PowerPoint) allow users to tap through a flow.
Use medium fidelity when:
High-fidelity prototypes look and sometimes function like real products. They include visual design, real content, and interactive elements.
Use high fidelity when:
For more on choosing the right approach and building quickly, see our Rapid Prototyping guide.
Before building any prototype, write down the single most important question it needs to answer. Not three questions. One.
"Will users understand the value proposition from the landing page?" is a question. "Will users click the signup button?" is a question. "Does the checkout flow feel trustworthy?" is a question.
When you try to answer multiple questions with one prototype, you end up with something too complex and too expensive, and the feedback you get is muddy. Build the simplest thing that answers your most critical question.
Over-investing in fidelity. If you are spending more than a few days on a prototype, you are probably building too much. The goal is to learn quickly, not to impress.
Falling in love with the prototype. Once you have invested effort in building something, it is psychologically hard to throw it away. But prototypes are disposable by design. If testing shows the concept does not work, the prototype has done its job by saving you from building the wrong thing at full scale.
Not prototyping the risky parts. Teams tend to prototype the parts they are most confident about. But the purpose of prototyping is to test uncertainty. Identify your riskiest assumption and build the prototype around that.
Skipping prototyping entirely. Some teams go straight from ideation to development. This almost always results in expensive rework because assumptions that seemed obvious turn out to be wrong when real users interact with the product.
Take your prototype into the Test stage. Put it in front of the real people from your empathy research and watch what happens. Their reactions will tell you whether to refine, pivot, or move forward with confidence.
Related guides: test stage · initialize stage · empathize stage
Design Thinker Labs Home · All Guides · How It Works · Pricing