What is the difference between a wireframe, a mockup and a prototype?

In short

All three are ways of showing a screen before it is built. The difference is how closely they resemble the finished product. That is called fidelity.

The individual terms are in the glossary: wireframe and prototype. In this guide I explain the difference between all three and when I use which.

What is a mockup?

A mockup is an image of a screen that resembles the finished product but doesn’t work. Wikipedia defines a mockup in general as a scale or full-size model of a design or device. In software, the most common use is showing end users what the software will look like.

According to the same article, a software mockup looks like the real thing but does nothing beyond what is visible. If it offers at least part of the functionality and lets you test the design, it counts as a prototype. I use this boundary too: if something happens on click, it is a prototype.

In the team I use this definition: the mockup is the static state of the wireframe layout, dressed in colour, type, real text and images. This definition is mine; the sources don’t draw the word’s boundaries so sharply.

The fidelity of a mockup varies too. In Laubheimer’s survey, the “pixel-perfect” mockup is listed as a separate item. The name describes a drawing that matches the finished screen pixel for pixel. In most projects I don’t go that far; details that allow a decision on colour and type are enough.

Comparison table

Kara Pernice of NN/g doesn’t see fidelity as a single measure. According to her, it can be high or low separately for interactivity, visuals and content. Read each cell of the table as a tendency.

Criterion	Wireframe	Mockup	Prototype
Fidelity	Low. Grey boxes and a few labels.	High visually, none interactively.	Interactive. Can be paper or a file very close to the finished product.
Purpose	Talk about the placement and order of elements.	Get visual decisions such as colour and type approved.	Try the flow with users.
Tool	Paper and a thick pen, or grey boxes in a design tool.	Design tool, design system components, real images.	Linking screens in the design tool, a paper prototype or code.
For whom	Team discussions and development.	Mostly external clients.	Test participants, development and clients.
Time	Shortest. If it is wrong, delete it and draw again.	Medium. Every visual decision takes time.	Longest. Linking the screens is work too.

The time row is based on my own experience. I don’t give hours, because it depends heavily on the size of the screen and how prepared the team is. Pernice also writes that a clickable prototype can take time.

The “For whom” row is based on a survey. In Page Laubheimer’s 2015 NN/g survey of 86 UX professionals, the static wireframe was the most frequently created deliverable. 71% of respondents said they created it “often”.

In the same survey, pixel-perfect mockups were considered effective only with external clients. In client work, 47% of respondents chose the mockup; to communicate ideas to executives, only 25%. In client work, only one deliverable ranked above the mockup: the clickable prototype, with 67%.

In work with development too, the clickable prototype was the most effective deliverable. The static wireframe made the top five on that list.

One screen, three levels of fidelity

The example below is a screen for adding money to a transit card. The layout is the same in all three states. Only the fidelity changes.

One screen, three levels of fidelity

1. Wireframe

Amount

102050

Add money

2. Mockup

←Card balance

Transit card •••• 4821

Balance

$12.50

Amount to add

$10$20$50

Add $20

Image The buttons are drawn; nothing happens when you press them.

3. Prototype

Because JavaScript is off, both screens are shown one below the other.

←Card balance1 / 2

Transit card •••• 4821

Balance

$12.50

Amount to add

$10 $20 $50

Add $20

Money added2 / 2

$20 added

New balance: $32.50

The receipt was sent to your email address.

Back to start

The card, amounts and balance are made up. Use the selector at the top to switch between three states of the same screen; the arrow keys work too. In the prototype, choose an amount and press Add money, and the second screen opens. Without JavaScript, the three states are shown one below the other.

At each stage I ask a different question. In the wireframe: does the amount selection come before the button? In the mockup: is the balance on the card comfortable to read?

In the prototype I watch the user. If they press the button without changing the amount, do they notice on the second screen that the balance went up? The answer to these questions can only be seen on a screen that can be clicked.

That is why I write down the question first and then choose the fidelity. Reverse the order and the team polishes things whose answer it already knows.

When to use which

Wireframe: when the structure is still open

When the discussion is about which element goes on the screen and in what order, I start with the wireframe. Deleting a grey box is cheap, and nobody talks about colour. Once the layout of menu and pages, that is, the information architecture, is settled, this step goes quickly.

Kelley Gordon (NN/g) recommends a thick pen and a time box for wireframing. Both stop you getting stuck on small visual details.

Mockup: when the look is waiting for approval

If a decision on brand colour and type is needed, you need a mockup. Contrast and legibility also show for the first time at this stage. If colours and components come from a design system, the mockup stage gets shorter.

Prototype: when you test the flow

If you want to see whether a user can complete a task from start to finish, you need a prototype. A usability test is done with this material. How many people to test with is covered in the guide how many users to test.

According to Pernice, testing the finished product is risky. Ripping out code is expensive; tearing up a paper prototype isn’t.

An example: the cart page

Suppose you are redesigning an online store’s cart page. The first question is about structure: do the shipping costs go above or below the product list? You discuss that in the wireframe, drawing two or three versions side by side and comparing them.

Once the layout is set, you move to the mockup. Does the coupon code field stand out too much; is the total big enough? Those are questions about colour and type size.

In the last step, you give the user a task with the prototype: “Remove the second product from the cart and go to checkout.” If the user can’t find the remove button, a static drawing wouldn’t have shown you that. The payment step itself is covered in the checkout pattern.

Questions I ask when choosing fidelity

Before I work on a screen, I ask myself a few questions. The answers often choose the fidelity by themselves.

1. What do I need to learn this week? If the layout is being discussed, wireframe; the look, mockup; the flow, prototype.
2. Who will I show it to? If it is a team discussion, a rough drawing is enough. If an external client approves, the look counts too.
3. What do I throw away if it is wrong? The more expensive that is, the rougher I start.
4. Are the components ready? If there is a design system, high fidelity becomes cheap. Otherwise every screen is drawn from scratch, and the mockup takes longer.
5. Where will the user see the screen? Testing a phone flow on a desktop screen misleads me. I open the prototype on the user’s own phone.

I don’t apply this list exactly the same way in every project. But if I can’t answer the first two questions, I don’t draw anything yet.

Is this order required?

No. The Wikipedia article on mockups also says that the three terms aren’t clearly separated in software and systems development. That makes sense to me, because fidelity doesn’t grow along a single line.

If you show wireframes you drew on paper one after another, you have a low-fidelity prototype. If you link mockups together, you get a high-fidelity prototype. Both are prototypes; they differ on the visual axis.

Sometimes I skip the mockup altogether. If the product has an established design system, the components are already coloured and ready. Then I go from the wireframe straight to a clickable prototype or into code.

The reverse happens too. With a new brand without a settled visual language, I bring the mockup forward. If colours and images trigger long discussions in the team, it helps me to separate that discussion from the layout decisions.

Common mistakes

• Mockup too early. If a coloured screen is shown before the layout has been discussed, the meeting tips into colour. According to Pernice, users find it easier to criticise a rough design. I see the same in meetings with stakeholders.
• Flow test with the mockup. With a static image you ask the user: “What happens if you press here?” What you measure is their guess. To see the flow, link the screens.
• Polishing every screen before the test. Pernice writes that designers are less attached to low-fidelity prototypes. If the test goes badly, it is harder to let go of a polished screen.
• Giving development only a mockup. A static image doesn’t show what happens on press, and no error state either. Development has to guess. Draw error messages as a screen too.

My note

Most screens I review in audits look as if they never went through the wireframe stage. Colours and images are careful, but the order of elements doesn’t fit the user’s task. The cause is usually the skipped first step.

My default order: wireframe on paper, clickable prototype with the design system, a short test, then code. I only make the mockup a separate step when someone has to approve the look. Laubheimer’s survey also shows that the mockup helps most with external clients.

Keeping design and code with one person shortens this order. The Design & Ship Sprint is for that: in two weeks from wireframe to a working screen in your repository. If you already have a product live, it is cheaper to start with the UX audit and see where users get stuck.