By Mehdi HassanWireframe, mockup and prototype get used interchangeably in meetings, briefs and proposals, which causes real problems: a client expects clickable screens and gets grey boxes, or a developer receives a pretty picture with no idea how anything behaves. The three terms describe different things, built for different questions. Here are the definitions, one comparison and when to use each.
What is the difference between a wireframe, a mockup and a prototype?
A wireframe shows structure, a mockup shows appearance, and a prototype shows behavior. Wireframes are simplified layouts of what goes where. Mockups are static, realistic images of the finished design. Prototypes are interactive versions people can click, tap or type into to experience a flow.
They're often made in sequence, each building on the last, but they aren't strict stages. A prototype can be built from wireframes, and a mockup can exist without ever becoming a prototype. The thing to remember is what each one can and can't answer. For the bigger picture of when and why to prototype, see our guide to product prototyping.
Wireframe vs mockup vs prototype: how do they compare side by side?
The three differ in fidelity, interactivity, cost to change and the question they answer. This table is the quickest way to tell them apart.
Wireframe | Mockup | Prototype | |
|---|---|---|---|
What it shows | Structure and content priority | Visual design: color, type, imagery | Flow and behavior |
Fidelity | Low: boxes, lines, simple text | High: looks like the final screen | Any, from rough to polished |
Interactive | No (or barely) | No | Yes |
Cost to change | Lowest | Medium | Medium to high |
Answers | Is the right content in the right place? | Does it look right and on brand? | Can people use it? |
Can't answer | How it will look or feel | Whether the flow works | Nothing on its own; depends on fidelity |
Typical tool | Figma, whiteboard, paper | Figma | Figma, Framer, ProtoPie or code |
Main audience | Team and stakeholders | Stakeholders and brand owners | Users in tests, investors, developers |
What is a wireframe?
A wireframe is a low-fidelity layout of a screen or page that shows what content and controls go where, without visual styling. It uses boxes, lines, placeholder images and simple text to make structure and priority decisions visible.
Wireframes are deliberately plain. Leaving out color and imagery keeps the discussion on what matters at that point: which information is most important, what order things appear in, and what the user can do on each screen. Because they're quick to redraw, they're the cheapest place to make big changes. The best wireframes use real words rather than lorem ipsum, since a headline's length and meaning shape the layout.
What is a mockup?
A mockup is a static, high-fidelity image of a screen that shows how the finished design will look, with real typography, color, imagery and components. It's a picture, not something you can use.
Mockups answer visual questions: is this on brand, is the hierarchy clear, does it look trustworthy? They're what stakeholders usually react to most strongly, which makes them good for aligning on direction and risky for judging usability. A beautiful mockup can hide a confusing flow, because nobody has to actually complete a task in it. Mockups should also be checked for basics like contrast and type size; our guide to accessible design basics covers what to look for.
What is a prototype?
A prototype is an interactive model of a product or flow that lets people click, tap or type through it to test how it works. It can be built at low fidelity from wireframes or at high fidelity from mockups; interactivity is what defines it.
Prototypes are the only one of the three that can be used in a usability test, because they let someone attempt a task. They range from a simple linked set of wireframes to a coded front end with real data. Where it's built depends on the question; our comparison of Figma prototype vs code prototype explains when code is the better choice, and the roundup of best prototyping tools ranks tools by job.
When should you use each one?
Use wireframes to decide structure, mockups to decide appearance and prototypes to test behavior. On most projects that means wireframes early, mockups once the structure is stable, and a prototype before committing to the build.
- Wireframe first when you're defining a new page, screen or flow and the content and order aren't settled.
- Go to mockups when stakeholders agree on structure and the open question is visual direction.
- Build a prototype when the question is whether people can complete a task, or when you need to show investors or developers how something behaves.
- Skip wireframes for small changes to an existing design system, where layout patterns are already decided.
- Skip to a code prototype when the risk is real data, timing or AI output.
For example, suppose a startup is designing a new signup flow
Hypothetical example: a SaaS startup needs a new signup and onboarding flow. The team sketches wireframes of four screens, writing the real headline and field labels, and agrees to cut one screen entirely.
The designer then produces mockups of the remaining three screens in the brand's style. The founder approves the look. Finally, the team links the mockups into a clickable prototype and asks five target users to sign up. Two of them miss the 'skip for now' option on the second screen, so the team changes the layout before any code is written. Each artifact answered a different question.
What should you get at handover?
At handover from a design project, you should receive the final mockups or design files, any prototypes, and enough documentation for developers to build the behavior correctly. Wireframes are usually kept as a record but aren't the build reference.
The important thing is that what developers receive describes behavior, not just appearance: states, interactions, responsive rules and content. Our website design deliverables checklist lists what you should own at the end of a project. If you're running a fast cycle that moves through all three artifacts in a short block of time, our guide to running a design sprint shows how to sequence them.
