Wireframe, Mockup, Prototype: What’s the Difference?

Monday morning, project meeting. The managing director says: “Just send me the prototype.” The designer sends a PNG of the fully designed homepage. She clicks the “Book now” button, nothing happens, and she replies: “The prototype is broken.” Meanwhile, the developer has been waiting a week for “the wireframes” and ends up with the same PNG, which he thinks is a mockup.

Three people, three terms, three different expectations. Wireframe, mockup and prototype are among the words you hear most often in UX design, and among the ones that get mixed up most often. This is more than a squabble over vocabulary. If you build the wrong thing at the wrong time, you end up debating colors before the navigation is settled, or you spend days on a clickable design when a paper sketch would have answered the question in an hour.

You’ll find short definitions of all three terms in the glossary. This article tackles the question that comes next: when do you need which, how do they blend into each other, and who should see what? One example project will guide you from the first sketch all the way to testing.

Three designs, three questions

The easiest way to tell the three apart is to look at the question each one answers. Design software maker Sketch sums it up in a similar way: a wireframe shows structure, a mockup shows appearance and a prototype shows functionality.

Wireframe: what goes where?

A wireframe is the floor plan of a page or app screen. It shows where navigation, headings, text, images and buttons go, usually in shades of gray with placeholder boxes for images. Colors, fonts and photos are left out on purpose. Figma describes wireframes as a basic, low-fidelity blueprint that captures an idea at an early stage.

The value of a wireframe lies precisely in this sparseness. Since nothing looks pretty, nobody talks about looks. The discussion stays on the questions that need answering first: what’s the most important thing on this page? What does someone need to be able to do next? Is any content missing?

Mockup: what does it look like?

A mockup is a static, visually polished design. Colors, fonts, images, spacing and copy are largely the way they will appear in the finished product. But you can’t interact with it. Figma puts it neatly: mockups focus on form, not functionality.

A mockup lets you check how a product comes across: is the main button visible right away? Does the imagery fit the brand? Is the text easy to read? It’s also the format that clients, executives and investors grasp fastest, because it looks like what they have in mind.

Prototype: how does it feel?

A prototype simulates the experience of using the product. You can click, tap, fill in forms or move through a flow, at least as far as the question at hand requires. A prototype answers questions like: can people get from A to B? Do they understand what happens after a click? Where do they get stuck?

An important point if you’re just starting out: a prototype doesn’t have to be pretty. A stack of paper sketches, with one person playing the computer and laying down the right sketch after each “click,” is just as much a prototype as an elaborate design built in a design tool. The Nielsen Norman Group (NN/g), a well-known usability research and consulting firm, describes a prototype as a hypothesis: a proposed solution that still has to be tested.

Why the usual order makes sense

In many projects, the three come in exactly this order: wireframe first, then mockup, then a detailed prototype. Figma places wireframes in the early discovery phase and mockups in the design phase, before high-fidelity prototyping and developer handoff. That’s not a rule, but there are good reasons for it.

The most important one: every decision builds on the previous one. If a mockup reveals that a whole section is missing or a flow needs rearranging, all the visual details for that section go out the window. In a wireframe, the same change takes a few minutes, because it’s just boxes.

The second reason is feedback. The more finished a design looks, the more people comment on surface details. NN/g also points out that designers feel less attached to rough designs, and that test participants are more likely to voice negative reactions when a design is visibly unfinished. A rough design tells everyone involved: everything is still open here.

Still, the order isn’t a waterfall where one phase has to be neatly wrapped up before the next one starts. You’ll often go back, for example when a prototype test shows that the structure doesn’t hold up. Then it’s back to the wireframe, and that’s a good sign, not a failure.

One project, three designs: the climbing gym

Here’s what this looks like in practice. A climbing gym wants visitors to book online: pick a time slot, enter the number of people, add rental gear, pay. So far, everything runs through phone calls and a list at the front desk. The team consists of a designer, a developer and the gym’s management.

Step 1: sketches and wireframes

The designer doesn’t start at the computer but with pen and paper. Within half an hour, she has three rough variants of the booking page. Variant A leads with a calendar, variant B with a list of the next available time slots, and variant C first asks how many people are coming.

She talks the sketches through with the gym’s management. It quickly becomes clear that most visitors come spontaneously, on the same day or the next. For them, a monthly calendar is a detour. Variant B wins, with a small “Choose another date” link added. Something else stands out too: an important piece of content is missing. First-time climbers need to book an introductory session. Nobody had thought of that.

Next, the designer turns the structure into digital wireframes, in gray but with real copy instead of placeholder text. Only with real copy does it become obvious that “Rental gear (shoes, harness, belay device)” doesn’t fit into a narrow column.

Step 2: the clickable wireframe

Before a single color is chosen, the designer links the wireframes together. Clicking a time slot leads to the number of people, then to rental gear, then to a summary. That’s already a prototype: gray and plain, but usable.

The team asks five regulars at the front desk to run through a booking with it. The result: four out of five miss that they have to book the introductory session for their first-time companions separately. The fix, a simple question “Is anyone climbing with us for the first time?” right after choosing the number of people, takes ten minutes to add in the wireframe. The glossary entry on usability testing explains how to set up a test like this.

Step 3: mockups

Now that structure and flow are settled, the designer creates mockups of the key screens: with the gym’s colors, the logo, photos of the climbing wall and the final typeface. The management sees for the first time what the booking will look like “for real” and only discusses visual questions: is the orange too loud? Should the time slots show how busy the gym is?

Because the structure has already been tested, this round doesn’t move any sections around. It refines the look. To keep all screens consistent, the designer sets up colors, font sizes and buttons as reusable components, a small first step toward a design system.

Step 4: the detailed prototype

Finally, the designer links the mockups into a detailed prototype. Now the team can test questions that a gray design can’t answer: is the occupancy indicator easy to understand? Is the note about the introductory session noticeable without being annoying? Does the page feel too crowded on a phone?

The developer also uses this prototype as a reference for building the feature. He can see which screen follows which and how buttons behave. Questions that would otherwise have come up halfway through development are cleared up early.

What matters in this example is less the exact sequence than the principle: each design answers the question that’s currently on the table, with as little effort as possible.

Fidelity isn’t an on/off switch

Talk about designs for any length of time and the word fidelity comes up. It means how closely a design resembles the finished product. “Low fidelity” stands for rough and sketchy, “high fidelity” for close to the real thing. Sometimes there’s “mid fidelity” in between, such as a digital wireframe with real copy.

NN/g distinguishes three dimensions of fidelity, each of which can be high or low independently of the others:

• Interactivity: how much can you actually use? Nothing at all, single clicks, or entire flows with inputs?
• Visuals: how close are the colors, fonts, images and spacing to the finished product?
• Content and commands: does it contain real text, prices and labels, or placeholders?

These three dimensions explain why the terms blur in practice. A wireframe has low visual fidelity but can have high content fidelity if it uses real copy. A mockup has high visual fidelity but no interactivity. Link a mockup’s screens together and you only raise its interactivity, and the mockup becomes a prototype. That’s also why the clickable wireframe in the example already counts as a prototype.

Back in 1997, researchers Stephanie Houde and Charles Hill suggested in a widely cited paper that prototypes shouldn’t be classified by tool or polish but by the question they answer. They distinguish three kinds of questions: about the role a product plays in people’s lives, about its look and feel, meaning the concrete sensory experience of using it, and about its implementation, meaning how it works technically. To them, a prototype is any representation of a design idea, regardless of medium. In everyday work, this means: before you build a design, decide what you want to find out. That tells you which dimension needs detail and where rough is good enough.

What research says about rough prototypes

A common worry among beginners: if you test with paper or gray boxes, are the results even meaningful? The research is encouraging. In 2017, Jeff Sauro of MeasuringU summarized a number of studies that compared prototypes of different fidelity.

Several of them, including Virzi, Sokolov and Karis (1996) and Walker, Takayama and Landay (2002), found no substantial difference in the number of usability problems uncovered with paper versus computer prototypes. Walker and colleagues did observe, however, that the types of problems found differed. In a study by Sefelin and colleagues (2003), participants offered a similar amount of criticism on paper and computer prototypes, but 92% preferred the computer prototype.

Sauro’s conclusion: rough prototypes are a reasonable, if not perfect, substitute for finding usability problems. They’re less reliable when it comes to task times or judging visual appeal. That matches the principle above: rough is fine for questions about structure and flow. For questions about impression and speed, you need more detail.

Who sees what?

Much of the confusion from the introduction arises because different people on a project need different things. A few rules of thumb help.

Your own team gets the most out of wireframes and sketches. This is where decisions about structure, content and flows are made, and the faster you can create and discard variants, the better.

Clients and executives find mockups and detailed prototypes easiest to understand. If you show them wireframes, say clearly up front what they’re looking at: “This is the floor plan. Colors and images come later. Today we’re only checking whether everything important is there.” Otherwise, someone will inevitably ask whether the website is really going to be gray.

Test participants always get a prototype, because you can only observe how people behave if there’s something they can use. How detailed it is depends on what you’re testing.

Developers mainly need clarity: which screens exist, how do they connect, and what do they look like in different states? A detailed prototype built from mockups is a good basis for that. It helps even more to involve developers at the wireframe stage. That way, it becomes clear early on if something will be technically difficult or expensive.

Whoever you show something to, label it: say what it is and what it isn’t. A line like “Mockup, not clickable” or “Prototype, only the booking flow works” prevents the Monday morning mix-up.

Common misconceptions

“A prototype has to look almost finished”

No. A prototype is defined by the fact that you can use it, not by how it looks. A paper sketch with one person playing the computer is a fully valid prototype for early questions. NN/g does note one downside of such static prototypes: the person playing the computer can make mistakes too. A little practice before the test pays off.

“Every project needs all three”

Also no. For a small change to an existing product with an established design system, it can make sense to go straight to a mockup, because colors and components are already defined. On the other hand, a clickable wireframe might be enough for an internal admin interface where looks barely matter. What counts is the question you want answered, not a fixed sequence.

“Once the prototype is done, it just needs coding”

A prototype simulates a product; it isn’t one. Error cases, empty states, loading times, real data and edge cases are usually missing. A prototype isn’t a minimum viable product either: an MVP is a first real version that people actually use. A prototype exists to learn from and can be thrown away afterwards.

“The name doesn’t matter”

Almost true. Which term you use is secondary, as long as everyone on the team means the same thing by it. That’s exactly why it’s worth agreeing on the terms briefly at the start of a project. It takes five minutes and saves plenty of misunderstandings.

How to decide in everyday work

When you face a new task and aren’t sure where to start, three questions help.

What do I want to find out? If it’s about structure and content, a wireframe will do. If it’s about impression and visual design, you need a mockup. If it’s about whether people can complete a flow, you need a prototype.

How sure am I already? The more that’s still open, the rougher the design can be. Rough designs invite people to throw them out, and that’s exactly right at the start.

Who needs to understand it? For your own team, a sketch is often enough. For clients, test participants or developers, you need more detail, but only in the dimension that matters right now.

An example: you’re asked to design a filter feature for an online store. Whether the filters sit on the left, at the top or in an expandable panel, you can figure out with a few wireframes. Whether people understand how to combine several filters, you can test with a clickable prototype that may well stay gray. Whether the filter chips are legible and stand out from the rest of the page, only a mockup will show.

Which tool you use is secondary. Many teams today handle all three stages in a tool like Figma. For first sketches, though, pen and paper are often faster than any software.

Conclusion

Wireframes, mockups and prototypes aren’t stages to tick off but tools for different questions. The wireframe clarifies what goes where. The mockup shows what it looks like. The prototype lets you test whether it works. The boundaries are fluid: a clickable wireframe is already a prototype, and so is a linked mockup.

So the most important habit to build early on isn’t memorizing definitions. It’s pausing briefly before every design to ask: what do I want to find out, and what’s the smallest design that will show me? Work this way and you’ll argue less about colors before the structure is in place, and you’ll find problems while they’re still cheap to fix.

Checklist

• Before each design, it’s clear which question it should answer.
• Structure and content are settled in the wireframe before anyone discusses colors.
• Wireframes use real copy instead of placeholder text early on.
• Flows are tested with a clickable prototype, gray or on paper if need be.
• Fidelity is high only where the question requires it.
• Every shared design is labeled: wireframe, mockup or prototype, and what parts of it work.
• The terms are agreed on with the team and clients at the start of the project.
• Developers are involved early, not only once the prototype is finished.

Sources

• Kara Pernice: UX Prototypes: Low Fidelity vs. High Fidelity. Nielsen Norman Group, 2016
• Figma: Wireframe vs. mock-up: what’s the difference? Figma Resource Library
• Sketch: Wireframe vs mockup vs prototype: What’s the difference? Sketch Blog
• Stephanie Houde, Charles Hill: What Do Prototypes Prototype? In: Handbook of Human-Computer Interaction, 2nd edition, Elsevier, 1997
• Jeff Sauro: Does the Fidelity of a Prototype Affect Results? MeasuringU, 2017
• Hoa Loranger: Paper Prototyping. Nielsen Norman Group, 2011