What Is a Prototype?

A prototype exists to answer one question before production work starts: does this design actually work for the people using it? How it simulates the product varies. Early-stage prototypes can be paper screens that a person swaps by hand, most web prototypes are mockup screens linked into a clickable flow in a design tool, and some teams build working versions in temporary, throwaway code.

A prototype rarely includes every feature planned for the final product. It carries just enough screens and behavior for people to attempt realistic tasks, so you can watch where they succeed, where they stall, and what they ignore. That feedback arrives while changing course is still cheap.

Prototype vs. mockup vs. wireframe

Design work usually moves from structure to visuals to behavior, and each deliverable answers a different question:

• A wireframe settles structure: a plain sketch of layout and content placement, with no colors or styling.
• A mockup communicates visuals: real colors, typography, and imagery applied to that layout, still as a static image.
• A prototype simulates behavior: the design made testable, most often as screens linked into a clickable flow.

The handy tell from the mockup side: if you can click through it, it's a prototype.

Low-fidelity vs. high-fidelity prototypes

Fidelity is how closely a prototype resembles the finished product, and it's a spectrum, not a pair of fixed grades.

• Low-fidelity prototypes are paper sketches or clickable wireframes with placeholder text. They're fast to build and cheap to throw away, which suits early rounds while the concept itself is still in question.
• High-fidelity prototypes are near-final mockup screens wired together, with real copy, colors, and transitions. They suit usability testing and stakeholder sign-off once the design is close to settled.

The rule: stay low fidelity while big changes are still likely, and add polish only when you need feedback on the real look and feel rather than on the idea itself.

How to make a website prototype

You don't need to write code. The standard workflow has 4 steps:

• Start from screens the team has already agreed on, usually wireframes or mockups.
• Link those screens into a clickable flow in a prototyping tool. Figma led the UX Tools 2024 Design Tools Survey of 2,220 designers (fielded November 2024 through January 2025) with an 82.3% share of UI design tools, and it topped the same survey's basic-prototyping rankings, ahead of ProtoPie and Adobe XD.
• Give real users a task and watch them attempt it without coaching. Nielsen Norman Group's research (Jakob Nielsen, 2000) found that about 5 users surface roughly 85% of a design's usability problems.
• Fix what you saw, retest, and only then hand the flow to development.

As a worked example: take a 4-screen checkout flow (cart, shipping, payment, confirmation), link the screens into a clickable path, and test it with 5 users. If 3 of your 5 testers hunt for a guest checkout that isn't there, you've caught the problem in a prototype revision instead of a rebuilt checkout.

When to prototype, and when to skip it

Prototype after the structure is agreed and before anyone writes production code. That window is the point of the exercise: a broken flow found in a prototype costs a revision, while the same flow found after launch costs a rebuild. The classic order (wireframe, mockup, prototype) is a convention rather than a rule, and in a tool like Figma the same file often doubles as mockup and prototype.

You can skip a separate prototype when the behavior you'd be testing already exists somewhere clickable, which is why very small sites and theme-based builds often go without one. When in doubt, prototype only the riskiest flow. One tested flow beats an untested site.

Where prototypes go wrong

The most common failure is a prototype that looks too finished. Stakeholders mistake it for a nearly built product, and the development schedule gets compressed to match the illusion. Share early rounds in visibly rough form, and say plainly what is and isn't real when you demo it.

The second failure is shipping the prototype. Code written to fake a flow was never built to survive production, and teams that promote it inherit every shortcut as technical debt. Treat a prototype as disposable: keep what it taught you, rebuild what it is.