Wireframe vs Prototype: the difference, with examples

What is a wireframe, really?

A wireframe is a screen drawn as structure only. Rectangles where images will go, lines of grey "Lorem ipsum" text where words will go, boxes for buttons with labels like "Place order". No real colours, no real fonts, no photographs. It is deliberately ugly.

The ugliness is the point. When a screen looks polished, every review conversation becomes about the colours and the wording. When it is grey boxes, the conversation stays on the questions that matter first: is everything on this screen needed? Is the order right? Is anything important missing? Fix structure cheaply, before polish makes changes expensive.

A good wireframe contains:

• Layout: which blocks sit where (header, product list, order summary, button).
• Hierarchy: the primary action is visibly bigger or placed first (compare Visual Hierarchy (/skill/visual-hierarchy)).
• Content labels: what each block is, in words: "Restaurant name", "Delivery time", "Total".
• Nothing visual: if you are picking a colour or a font, you have left wireframing and started designing; go back.

You can wireframe on paper, on a whiteboard, or in Figma with plain grey rectangles. The tool does not matter at this stage; the thinking does.

What is a prototype, and what is it not?

A prototype is a design you can click. You take screens, they can be rough wireframes or polished mockups, link them together, and suddenly tapping "Place order" actually moves you to the confirmation screen. You are not running a real app; behind the button there is no code, no database, no payment. But for the person tapping, it *feels* like the app.

What a prototype is not:

• Not a demo of a finished product. Nobody should leave a prototype review thinking the app is built.
• Not a design with fake polish. A prototype of wireframes is often better for testing, because people criticise the flow instead of the colours.
• Not throwaway. The screens you link in a prototype usually become the real design. Prototyping is design, not a side quest.

Prototypes exist to answer interaction questions: can a person find the "Track order" button? Do they understand what happens after they pay? Where do they hesitate? Those questions cannot be answered by staring at a static screen.

Wireframe vs prototype: the difference in one table

The short version: a wireframe is a map of one place; a prototype is a walk through several places. You need the map before the walk makes sense.

When should you use each one?

Wireframe when: you are deciding layout, which elements belong on a screen, in what order, and what the primary action is. Also when you need to show an idea fast: a wireframe photographed from your notebook is enough to start a useful conversation.

Prototype when: the layout is settled enough and your questions are about movement. Does the person find the next step? Do they get lost between screens? Prototype before any code is written, because finding a confusing flow at this stage costs an hour to fix; finding it after development costs days.

Both when: the flow is the product. In a checkout, a sign-up, or an onboarding sequence, the screens are simple but the *order* is everything. Wireframe the screens, then link them and walk the flow yourself before anyone else does.

The switch point: when wireframing becomes prototyping

Beginners either prototype too early (linking screens before the layout works. Then every layout change breaks the links) or never prototype at all (showing static screens and asking "does this make sense?", which nobody can answer by looking).

The switch point is a sentence: you switch when your questions stop being about one screen and start being about moving between screens. "Should the total come before the button?" is a wireframe question. "After they tap the button, do they understand what happens next?" is a prototype question. When you catch yourself asking the second kind, link the frames.

Worked example: an order-confirmation screen, from wireframe to clickable prototype

The scenario (practice, not real data): a small food-delivery app. The flow is Home → Restaurant menu → Checkout → Order confirmation. We will wireframe the confirmation screen, then link all four screens into a prototype you can click through.

Part 1: the wireframe (paper or Figma, ~15 minutes).

1. Draw one rectangle: the phone screen. Inside it, from top to bottom, place grey blocks for: a header ("Order confirmed"), the order number, the restaurant name, a list of 3 items (grey lines), the total, and one big button labelled "Track order".
2. Ask the wireframe questions only: Is the order number more important than the total? (Yes. It goes higher.) Does the button say what happens next? ("Track order" does; "Continue" does not.)
3. Change nothing visual. If you want a colour, write it down in the margin for later and stay with grey.

Part 2: the prototype in Figma (~30 minutes).

1. Create four frames (or draw them), one per screen: Home, Restaurant menu, Checkout, Order confirmation. Even rough versions are fine.
2. Select the "View restaurant" button on the Home frame. Open the Prototype tab in the right sidebar. Drag the blue connector dot that appears on the button onto the Restaurant menu frame.
3. In the interaction details that open, set: On click → Navigate to → Restaurant menu, animation Instant (speed does not matter for a test).
4. Repeat for the whole flow: menu → Checkout (from "Add to cart"), Checkout → Order confirmation (from "Place order"), and Confirmation → Home (from a "Back to home" link).
5. Click the Present (play) button at the top right. Figma opens the prototype in a new tab. Click through the whole flow exactly as a user would.
6. Watch for hesitation in yourself: if *you* pause anywhere, that is where a real user will pause. Fix the screen, not the link.

What this proves: in under an hour, with zero code, you have something a real person can try. That is the whole power of a prototype, and it is why the Figma-in-depth weeks (7–11) of the UI/UX Designer roadmap (/roadmap/ui-ux-designer) spend so much time on clickable prototypes.

Common mistakes

• Polishing the wireframe. Adding real colours, fonts and photos turns it into a mockup, and then nobody will criticise the layout, which is the only thing that matters yet. Grey is a feature, not laziness.
• Prototyping before the layout works. Linking screens whose layout will change means re-doing the links with every change. Settle the wireframe first; the switch point above tells you when.
• Testing a prototype on yourself only. You know where everything is, you designed it. The prototype's job is to be tried by someone who has never seen it. One friend, five minutes, watch silently.
• Linking everything. A prototype needs the happy path and one or two error states, not every edge case. Prototype the flow you are unsure about; skip the rest.
• Presenting a prototype as a finished app. Tell anyone who tries it: "This is clickable pictures, not a working app." Otherwise their feedback will be about features, not flow.

Frequently asked questions