A wireframe is a rough sketch of a screen's layout with no visual design, used to agree structure. A mockup is a finished visual design of a screen, used to agree the look. A prototype links mockups together so that they can be clicked through, used to test the flow with users and show investors. They come in that order, and reviewing each at the right stage saves rework later.
In plain terms
Designing a house: the wireframe is the floor plan, the mockup is the architect's rendering, the prototype is a walk-through model. You would not comment on paint colours on the floor plan, and you would not rearrange rooms on the rendering. Each stage answers a different question, and a good project asks them in order.
The three, side by side
| Wireframe | Mockup | Prototype | |
|---|---|---|---|
| What it looks like | Grey boxes and placeholder text | The real screen: colours, type, images | Mockups linked together, clickable |
| Question it answers | What goes on this screen and where? | What does it look like? | Does the flow work for a real person? |
| What to review | Structure, priority, what is missing | Brand, clarity, consistency | Whether users complete the task without help |
| What not to review | Colours, fonts, exact wording | Whether the screen should exist | Pixel details |
| Time to produce | Hours per screen | Days per screen | Days to link, once mockups exist |
| Cost to change | Minutes | Hours | Hours |
Why the order matters
Each stage locks in the decisions of the one before. Changing the structure of a screen at wireframe stage takes minutes. Changing it after the mockup is finished wastes the visual work. Changing it after the screen has been built by developers takes days and costs real money. Founders who review wireframes carefully and mockups lightly get better products for less. Founders who wave through wireframes and then redesign at mockup stage pay twice.
What should a founder do at each stage?
- Wireframes: check every user journey from the brief is represented, the most important action on each screen is the most prominent, and nothing the user needs is missing. Ignore how it looks.
- Mockups: check the brand is right, the text is clear, and the screens feel like one product. Do not reopen structural decisions unless something is genuinely wrong.
- Prototype: put it in front of five people who match your users, ask them to complete the core task, and watch without helping. Their confusion is your bug list.
Related terms
A clickable prototype is what this post calls a prototype. A functional prototype is different: working software for one part of the product, with a real backend. A design system is the set of reusable components and rules that mockups are built from, so that every screen is consistent and new screens are faster to design.
Questions to ask your design team
- Which stage is this, and what kind of feedback do you need?
- Have we wireframed every journey in the brief?
- Who will test the prototype, and when?
Related terms
Frontend, functional prototype, writing an app brief, what to expect from kickoff to launch.
Frequently asked questions
Can we skip wireframes and go straight to mockups?
You can, and it usually costs more, because structural changes then happen on finished designs. Wireframes are cheap and fast. Skipping them saves days and risks weeks.
Do I need mockups for every screen?
For the first release, yes, at least for every screen users see. Admin and rarely used screens can often be built from wireframes plus the design system, which saves design time.
How many people should test the prototype?
Five who match your target users will find most of the major problems. More is better if it is cheap, but five real users beat fifty friends.