Design Thinking Prototype: Bringing Your Ideas to Life!

A design thinking prototype is a deliberately unfinished version of an idea, built to be criticised. It exists so that a team can find out what is wrong before the expensive work begins. That is the whole point, and it is also the reason most first prototypes are made of paper.

This guide covers what counts as a prototype, the seven types teams actually use, what separates a prototype from an MVP, and how to build and test your first one. If you are looking for the method behind the phase rather than the artefacts, our comprehensive guide to prototyping in design thinking goes deeper into the process itself.

What is a prototype in design thinking?

A prototype in design thinking is a simplified, testable representation of an idea, created in the fourth phase of the design thinking process. It can be a paper sketch, a clickable screen flow, a cardboard model or a role-played scene. Its purpose is not to look finished but to answer one specific question: does this solve the problem for the person we built it for?

Prototypes sit between ideation and testing. They turn an abstract concept into something a user can react to, which is the only reliable way to learn whether the concept holds. The five phases of the design thinking process place prototyping directly before testing for that reason, and the loop between the two usually runs several times.

Why prototypes are worth the effort

• Mistakes get cheap. Changing a paper sketch costs minutes. Changing a shipped product costs a release cycle and the trust of the people who already used it.
• Assumptions become visible. Teams discover what they had silently assumed the moment a user takes a different path through the prototype.
• Debates end. A prototype replaces an opinion argument with an observation. Two people who disagree about a flow can watch five users try it instead.
• Stakeholders can react. A clickable prototype gets a decision out of a steering committee far faster than a slide deck describing the same thing.

The 7 types of design thinking prototypes, with examples

1. Paper prototype or sketch. Hand-drawn screens or process steps on paper. Example: sketching the five screens of a booking flow and sliding them across the table while a user narrates what they would tap. Best for the first hours of an idea.
2. Storyboard. A sequence of drawings showing the user in context, before, during and after using the solution. Example: six frames showing a commuter discovering, buying and using a mobility subscription. Best when the value depends on the situation, not the interface.
3. Wireframe. A greyscale layout of a digital screen showing structure and hierarchy without visual design. Example: a dashboard wireframe used to agree on what belongs above the fold. Best for aligning a team before design work starts.
4. Clickable digital prototype. Linked screens that behave like a real app, usually built in Figma. Example: an onboarding flow with working navigation and dummy data, tested remotely with eight users. Best for usability testing.
5. Physical model. A tangible object built from cardboard, foam or 3D printing. Example: a printed housing for a sensor, used to check whether a technician can reach the mounting screws. Best for ergonomics, size and handling.
6. Wizard of Oz prototype. The user believes the system is automated while a human performs the work behind the scenes. Example: an AI assistant that is in fact a colleague typing answers, used to learn what people actually ask before any model is trained. Best for validating demand for automation before building it.
7. Service prototype or role play. The team acts out the service with real staff and real customers, often in the real environment. Example: running a new returns process at a single store for one day. Best for services, where the artefact is the interaction rather than the object. Our article on design thinking for services covers this in depth.

Low-fidelity vs high-fidelity prototypes

Fidelity describes how close a prototype is to the finished product. Neither level is better; each answers a different question.

The practical rule: stay low-fidelity until the idea itself has survived contact with users. Every hour invested in polish makes it harder to throw the concept away.

Prototype, MVP or proof of concept?

These three terms get used interchangeably and mean different things.

• Proof of concept: proves that something is technically possible. It is built for engineers, not users, and is often thrown away afterwards.
• Prototype: shows how the solution would work for a user. It is built to be tested and changed, and it does not need to run in production.
• Minimum viable product: the smallest version that real customers can actually use, in the real world, usually for money. It is the first product, not a test artefact.

A common failure pattern is calling an MVP a prototype and shipping it to customers with prototype quality, or spending months on a prototype that should have been an MVP.

How to build your first prototype in five steps

1. Write down the question. One sentence: what do we need to learn? A prototype without a question produces feedback nobody can act on.
2. Choose the lowest fidelity that answers it. If the question is about the concept, paper is enough. Only interaction and wording questions justify a clickable build.
3. Build only the path that matters. Prototype the one flow you are testing and fake everything around it. Dead ends are fine as long as the tester knows the boundaries.
4. Test with five users. Give them a task, then stay quiet. The instinct to explain the prototype is the single biggest source of false positives.
5. Decide, then iterate. After each round, decide explicitly: keep, change or drop. Prototyping only pays off if the results change something.

Prototyping tools in 2026

The tool landscape has consolidated sharply, and several tools that appear in older articles no longer exist.

• Figma: the default for digital prototypes, with linked screens, components and shared testing links. FigJam covers the workshop side.
• Miro: collaborative whiteboard for journey maps, storyboards and remote workshops.
• Balsamiq: deliberately rough wireframes, useful precisely because they do not look finished.
• Uizard: turns hand-drawn sketches and screenshots into editable digital designs, which shortens the step from workshop to clickable prototype.
• Axure RP: conditional logic and data-driven flows for complex enterprise applications.
• Penpot: open-source alternative that can be self-hosted, relevant where data protection rules out cloud tools.

Two corrections worth noting: InVision shut down all of its services on 31 December 2024 and its Freehand whiteboard was sold to Miro, so it is no longer an option. Adobe XD has not been sold as a standalone product since June 2023 and is in maintenance mode, receiving bug and security fixes but no new features. Recommendations for either tool in older tutorials are out of date.

Common mistakes when prototyping

• Building too much. A prototype that took three weeks will be defended rather than tested.
• Testing with colleagues. Internal users know the intended path and will not stumble where a real user does.
• Asking whether people like it. Ask them to complete a task and watch. Stated preference and observed behaviour rarely match.
• One prototype, one round. The value comes from iteration. A single round tells you the idea has problems but not which fix works.
• Skipping the boring parts. Error states, empty screens and edge cases are where most real usage problems live.

From prototype to a service that is actually live

In a corporate setting, a validated prototype is only halfway. The harder part is getting it through procurement, IT and compliance while the market is still interested. That is why large companies increasingly work with startups that have already built and tested the relevant part of the solution.

This is the model behind Wayra, the innovation hub of o2 Telefónica: startups are matched with concrete business challenges inside the company, and a successful pilot can become a commercial contract. The mechanism is called the venture client model, explained in our overview of Telefónica as a client. For an innovation team, it turns the prototype phase from an internal exercise into a route to a live product. The method behind all of this goes back to the work of IDEO and the Stanford d.school, which we trace in our deep dive on design thinking and IDEO.

Frequently asked questions

What is a prototype in design thinking?

A simplified, testable version of an idea, built in the fourth phase of design thinking to get user feedback before the solution is developed properly. It can be paper, digital, physical or a role-played scene.

What are examples of design thinking prototypes?

A paper sketch of an app flow, a storyboard of a customer situation, a greyscale wireframe, a clickable Figma prototype, a 3D-printed housing, a Wizard of Oz setup with a human behind the curtain, and a service role play run in a real store.

What is the difference between a low-fidelity and a high-fidelity prototype?

Low-fidelity prototypes are quick and rough and test whether the idea is right. High-fidelity prototypes look and behave close to the finished product and test whether the details work. Start low, move up only when the concept has held.

How long should a prototype take to build?

In early phases, hours rather than days. A first prototype that takes longer than a day usually answers a question the team has not yet defined clearly.

How many users should test a prototype?

Five users per round is the widely used rule of thumb, because most usability problems repeat quickly. More rounds with five users beat one round with twenty.

Is a prototype the same as an MVP?

No. A prototype is built to be tested and discarded. An MVP is the smallest real product that customers actually use, usually in a live market.

Conclusion

A design thinking prototype earns its keep by being cheap enough to throw away. Choose the lowest fidelity that answers your question, build only the path you want to test, put it in front of five real users and let the result change the plan. Teams that prototype well are not the ones with the best tools, but the ones willing to be wrong early, while it still costs nothing.