A wireframe, a mock-up and a prototype are three ways of showing software before it is built, and the main differences between them lie in what each one leaves out. A wireframe shows structure: what is on each screen and how the screens connect, drawn in plain boxes and labels. A mock-up shows appearance: the same screen with its real colours, type and branding, as a still picture. A prototype shows behaviour: something you can click through, or in some cases a working slice of the system. Each answers a different question, and when you approve one you are approving a different thing.
The three at a glance
| Wireframe | Mock-up | Prototype | |
|---|---|---|---|
| Shows | The structure and content of each screen | What the finished screens will look like | How the system behaves in use |
| Looks like | Grey boxes and plain text | A polished picture | Screens you can click or tap through |
| Question it answers | Is the right information here, in the right order? | Does it look right, and is it consistent? | Can someone complete the task? |
| Effort to change | Lowest of the three | Moderate | Highest of the three |
| What you are approving | Content and layout | Visual design | The flow of the task |
The wireframe: structure without decoration
A wireframe is deliberately plain. It may be a sketch on paper or a drawing made in a design tool, but it has no colour, no logo and no finished wording. For the stock list in a stock system, a wireframe would show which columns appear, which filters sit above them and what opens when you select an item.
The plainness is the point. Shown a grey box, people comment on whether the right information is there. Shown a finished-looking screen, they comment on the shade of blue.
A set of wireframes usually comes with a screen flow, a diagram showing how one screen leads to another. Together they are the cheapest place to discover that a field is missing or that a task takes too many steps. When you review them, take a real example, such as an order from last week, and walk it through. Check that everything the user needs is on the screen, that nothing unnecessary is in the way, and that the order of the fields matches the order in which the work is done.
The mock-up: appearance without behaviour
A mock-up, also written mockup and often called a high-fidelity design, is a still image of a finished screen. Its purpose is to agree the visual design: brand, colour, type, spacing and the look of each kind of control.
Mock-ups carry a risk. They look finished, so people assume the software nearly is. There is nothing behind the picture. The parts that take the time, such as the data, the business rules and the connections to other systems, are invisible in it.
Mock-ups also tend to show the ideal case: a tidy list of eight items with short names. Ask to see the awkward ones as well:
- the screen with no data yet;
- a list with two thousand rows;
- a very long customer name;
- an error message;
- the same screen on a phone.
On an internal system, a mock-up of every screen is often unnecessary. If the build uses an established component library, a ready-made set of buttons, tables and form controls, then mock-ups of two or three representative screens set the style and the rest follow it. On a customer portal, which your customers will judge you by, more of them are justified.
The prototype: something you can use
The word covers two different things, so ask which is meant.
A clickable prototype is a set of wireframes or mock-ups linked together, so that pressing a button moves you to the next screen. It has no real data and no logic. It is made in the design tool and its job is to let real users try a task before any code is written.
A working prototype is real code. It usually covers a narrow slice of the system and often runs on real data, for example the contents of the spreadsheet it is meant to replace. Its job is to prove a risky part: an awkward connection to another system, a difficult calculation, a search across all your records. Working prototypes have become much quicker to produce now that AI-assisted tools can generate code from a description or a design. Figma Make, for instance, generates code-backed prototypes from a text prompt.
The old advice was that a prototype should always be thrown away and the real system started afresh. The better rule is to decide before it is built whether it is disposable. A prototype made quickly to learn something leaves out security, error handling and automated tests, and putting it into production carries those gaps forward. One built on the same foundations as the eventual system can be kept. Ask the supplier which kind you are looking at, and get the answer in writing.
A prototype is also not a minimum viable product. An MVP is a released system with real users doing real work in it. For the case for prototyping and how to go about it, see the importance of prototyping and how to prototype an app without design skills.
Which ones your project needs
Few projects need all three for every screen. It depends on how much is at stake and who will see the result.
- A small internal tool replacing a spreadsheet. Wireframes of the main screens, then a working version. The spreadsheet itself is the best specification there is, which is how our spreadsheet to web application work begins.
- A customer portal. Wireframes, mock-ups of the main screens because the brand matters, and a clickable prototype tried by a few customers.
- A larger system with several kinds of user. Wireframes throughout, and a prototype of the riskiest tasks.
The common mistake is to skip the wireframes and start with mock-ups. The discussion then turns to colours while the structure is still wrong. Structure and appearance are the two halves described in the difference between UI and UX design.
The tools, and what to check before you approve
You do not need to choose the design tool, but you do need to be able to open what you are sent. Five that are actively maintained in October 2026, and which between them cover everything from rough wireframes to detailed prototypes:
- Figma runs in a web browser and handles wireframes, mock-ups and clickable prototypes in one place.
- Balsamiq produces deliberately rough wireframes.
- Sketch is a design application for the Mac.
- Axure RP is aimed at detailed, realistic prototypes.
- Penpot is open source and can be hosted on your own servers.
This is not a ranking. Two names from older articles need care. Adobe XD is in maintenance mode: Adobe fixes bugs and security problems but is adding no new features. InVision closed its design collaboration service at the end of 2024. If a supplier proposes either, ask why.
Whichever tool is used, ask for a link you can open in a browser without buying a licence, and for a PDF or image export at each approval so there is a record of what was agreed.
Then, before you approve anything:
- Wireframe. Walk a real example through every screen.
- Mock-up. Look at the awkward cases listed above.
- Prototype. Give it to someone who was not in the meetings, set them a task, say nothing and watch.
- All three. Write down what the approval covers. Approving a mock-up means approving how the screen looks. It does not mean every button in the picture is included in the price, unless the written scope says so.