Wireframes, mockups and prototypes: what's the difference?
Three design deliverables that are often confused. Learn what each one is for, what feedback to give and when you need it.
- Published
- Reading time
- 2 min read

Key takeaways
- Wireframes decide structure, mockups decide appearance, prototypes test behaviour.
- Give the kind of feedback each stage is designed for.
- Skipping early stages saves little time and often costs more later.
In design projects you will see three kinds of deliverables. They look different because they answer different questions. Knowing which question each one answers helps you give useful feedback.
Wireframes: what goes where
A wireframe is a simple, usually grey-scale layout of a page or screen. It shows content blocks, navigation, headings and buttons, without final colours, images or styling.
Use it to decide: what each page contains, the order of information, what the main action is and how navigation works.
Good feedback: "Pricing should come before the FAQ", "We are missing a way to contact sales from this page".
Less useful feedback: comments about colour or fonts, which are not decided yet.
Mockups: how it looks
A mockup is a static, high-fidelity design: real typography, colours, images and spacing. It shows exactly what the finished page will look like, but it does not do anything yet.
Use it to decide: visual style, brand expression, readability and how components look in their different states.
Good feedback: "This heading feels too small on mobile", "The photography looks off-brand here".
Prototypes: how it works
A prototype links screens together so you can click or tap through a flow, such as signing up, booking or checking out. It can be built from wireframes (low fidelity) or from mockups (high fidelity).
Use it to decide: whether users can complete key tasks without confusion, and how interactions should behave.
Good feedback: "I didn't notice the next step", "I expected to be able to go back here".
Why the order matters
Each stage makes the next one cheaper. Changing structure in a wireframe takes minutes; changing it after visual design takes hours; changing it after development can take days. Testing a prototype with a few users before development is one of the most cost-effective things a project can do.
How they fit together
A typical sequence is flows, then wireframes, then mockups, then prototype and testing, then handover to developers. Our UI/UX design projects follow this path, adjusted to the size of what we are building.
Frequently asked questions
Can we skip wireframes and go straight to design?
For very small pages, sometimes. For anything with several screens or user tasks, wireframes make structural problems cheap to fix.
Is a prototype the same as a working app?
No. A prototype simulates how screens connect so people can try the flow. It has no real data or back end.


