Wireframe, mockup, prototype

The short answer

All three are versions of a screen made before the real thing is built, and they differ by fidelity - how close each one is to the finished product. A wireframe settles structure: what goes where, in gray boxes. A mockup settles the surface: the actual colors, type, and imagery, at full visual fidelity but static. A prototype settles behavior: a version you can click through to feel how it flows.

Read them as a ladder from cheap-and-rough to polished-and-real. Each rung answers a different question, and each is more expensive to make and to change than the one below it. The skill is knowing which question you are actually trying to answer before you open the tool.

Wireframes (structure)

A wireframe is the skeleton of a screen: layout, hierarchy, and the pieces that need to be present, drawn deliberately without visual styling. Grays and placeholder blocks, sometimes literal "[image]" and "lorem ipsum," because the point is to argue about arrangement without anyone reacting to a color.

• What it answers. What content lives on this screen, in what priority, and how is it grouped? Does the primary action have room to be primary?
• What it deliberately omits. Brand, color, real copy, final imagery, and motion. Leaving them out is the feature, not a shortcut.
• How rough. Anything from a pen sketch on paper to a tidy gray layout in Figma. Low fidelity on purpose so it stays fast to redraw.

The tell of a wireframe: nobody can comment on how it looks, because it does not look like anything yet. That is what keeps the conversation on structure.

Mockups (surface)

A mockup is a wireframe with the visuals turned on: real colors, typography, spacing, icons, and imagery, applied to the agreed structure. It is what most people picture when they hear "the design" - a static, high-fidelity image of the finished screen. This is where a design system earns its keep, supplying the components and tokens so fifty mockups feel like one product.

• What it answers. Does this look right, on brand, and legible? Is the visual hierarchy correct - does the eye land where it should?
• What it still omits. Behavior. A mockup does not respond to a click, show a loading state, or transition between screens. It is a photograph, not a film.
• How finished. Pixel-accurate. A good mockup can be handed to engineering as the visual spec for a single screen.

The tell of a mockup: it is convincing enough that people forget it does not work. That realism is its value and its trap - it invites polish feedback before the flow has been tested.

Prototypes (behavior)

A prototype connects screens so a person can move through them: tap a button, land on the next view, open a menu, hit a dead end. It is the first artifact that behaves like the product instead of just depicting it. Prototypes range from a few mockups wired together with clickable hotspots to fully interactive builds with real data.

• What it answers. Does the flow work? Can a real person get from start to finish without getting lost, and does the sequence feel right in the hand?
• What it is for. Usability testing and stakeholder sign-off. You learn things clicking through a prototype that no static image reveals - a step that feels missing, a screen that arrives too late.
• How real. The most convincing kind. Some AI design tools now produce working, coded prototypes directly - see Claude Design - collapsing the gap between mockup and something you can actually use.

The tell of a prototype: you can be wrong about the flow and find out in minutes, before a line of production code is written.

Side by side

The axes that actually separate the three, at a glance:

How they fit together

The classic order is a fidelity ladder: wireframe to agree on structure, mockup to settle the visuals, prototype to test the flow. Working in that order is deliberate - you lock down cheap decisions before you spend on expensive ones, so you are not restyling forty pixel-perfect screens because the underlying structure was wrong.

In practice it is rarely a clean one-way handoff. Testing a prototype often sends you back to rework a wireframe; a design system can make mockups so fast that teams skip straight from a rough sketch to high fidelity. The three are not always three separate deliverables either - a single Figma file can hold all of them, and an AI tool can jump from a prompt to a working prototype without a formal mockup step. The ladder is a model of increasing fidelity, not a mandatory checklist.

Choosing what to make

Practical guidance, especially when you are reviewing or requesting design work:

• Debating what belongs on a page or in what order? Ask for a wireframe. Anything more finished will pull the conversation to color and waste the polish.
• Structure is agreed and you need to decide how it looks or hand a screen to engineering? You want a mockup.
• You need to know whether the flow works, or to convince someone by letting them use it? Only a prototype will do - a static image cannot answer a question about behavior.
• Matching feedback to fidelity saves the most time: giving pixel-level critique on a wireframe, or flow critique on a mockup, is asking the artifact a question it was not built to answer.

One question sorts almost any request: am I trying to settle where things go, how they look, or how they behave? Structure, surface, behavior - the answer names the artifact.