In short
A wireframe is a low-fidelity layout showing structure and content placement in boxes and lines, used to agree what goes where. A mockup is a static, high-fidelity design showing exactly how a screen will look, used to agree visual design. A prototype is an interactive simulation, from clickable mockups to working code, used to test how the product behaves before it is built. They answer different questions, cost increasingly more, and a well-run project moves through them in order, skipping stages only when the question they answer is already settled.
The three, defined
Wireframe. Grey boxes, lines and placeholder text on a page-shaped canvas. It shows what content and controls exist, how they are grouped, and their rough priority and position. No colour, no typography, no imagery. It is deliberately ugly so that the conversation stays on structure.
Mockup. The wireframe dressed: real typography, colour, spacing, imagery, and copy, rendered as a static image of the finished screen. It shows how the thing will look and is what most people mean by "the design". It does not move.
Prototype. A simulation of the product that can be used: screens linked so that tapping a button goes somewhere, states that change, sometimes real data and logic. Fidelity ranges from a paper sketch you can point at to clickable mockups in a design tool to a coded version that is nearly the product.
What each one answers
| Question answered | Fidelity | Typical time per screen | Cost of a change | |
|---|---|---|---|---|
| Wireframe | What goes on this screen, and where? | Low | Minutes to an hour | Trivial |
| Mockup | What will it look like? | High | Hours to a day | Moderate |
| Prototype | How will it behave, and does it work for users? | Low to very high | Hours to weeks | Moderate to high |
The sequence exists because each stage settles something the next depends on. Arguing about a button's colour before agreeing that the button exists is expensive; discovering that a flow does not work after every screen has been polished is more so.
Wireframes in practice
Use them at the start, once the information architecture and the content are roughly known. Sketch on paper or in a tool such as Figma, Balsamiq or Whimsical. Show them to stakeholders with the explicit framing that appearance is not yet being decided. Iterate quickly; a wireframe that took ten minutes should be thrown away without regret.
The failure mode is fidelity creep: a wireframe with real colours and a logo gets reviewed as a design, and the structural conversation is lost.
Mockups in practice
Use them once structure is agreed and a visual direction, perhaps from a mood board, has been chosen. Produce the key screens first, at real sizes, for phone and desktop, with real copy rather than placeholder text, because copy changes layout. Design the states that matter: empty, loading, error, filled.
The failure mode is mockups mistaken for the product. A static image cannot show what happens when the text is longer, the list is empty, or the connection is slow, and the handoff that assumes it can produces a build that surprises everyone.
Prototypes in practice
Use them to answer behavioural questions: does the flow make sense, can people complete the task, does the interaction feel right. Low-fidelity clickable wireframes are enough for testing navigation and flow with users. High-fidelity clickable mockups suit stakeholder demos and testing of detailed interactions. Coded prototypes suit anything where the real behaviour, data or performance is the question, and they are the right tool for validating an idea before committing to a full build.
The failure mode is a prototype that becomes the product by accident: shortcuts taken to simulate behaviour ship to real users. Decide up front whether the prototype will be thrown away, and if it will, make it cheaply.
The sequence in a typical project
- Brief and content outline.
- Wireframes of the main screens; agree structure.
- Visual direction; mockups of the key screens; agree appearance.
- Clickable prototype of the main flows; test with a few users; revise.
- Remaining screens and states as mockups; handoff to build.
A small marketing site may compress this to a wireframe conversation and mockups. A product with complex flows may spend most of its design time in prototypes and produce mockups only for the screens that need visual attention. The stages are a toolkit, not a ritual.
When to skip a stage
Skip wireframes when the structure is already established, such as a redesign that keeps the existing information architecture, or a template-based site. Skip mockups when a design system already defines how every component looks and the prototype can be built directly from it. Skip prototypes when the flow is trivial and the risk of building it wrong is low. Do not skip the stage whose question is still open, which is the usual reason for skipping and the usual source of the rework that follows.
What to ask for
Ask a designer for wireframes when you want to discuss what a page contains. Ask for mockups when you want to see how it will look. Ask for a prototype when you want to try it. If you are not sure which question you are asking, say so; a good designer will tell you which artefact answers it, and book a call if you would like that conversation with us.
Common questions
What comes first, wireframe or mockup?
The wireframe. It settles what each screen contains and where things sit, using plain boxes so appearance does not distract. The mockup then applies typography, colour, imagery and real copy to the agreed structure. Reversing the order means arguing about visual details on a layout that may still change.
Is a prototype the same as an MVP?
No. A prototype simulates the product to test flow, behaviour or an idea, and is usually thrown away. An MVP is a real, working product with the smallest set of features that lets actual users get value and lets the team learn from them. A prototype may precede an MVP; it should not be shipped as one.
What is a low-fidelity prototype?
A rough, interactive version of a product built from sketches or wireframes linked together, so that a user can move through the flow without any visual polish. It is fast to make and good for testing navigation and task completion early, when changes are cheap. High-fidelity prototypes add real visuals and detailed interactions.
What tools are used for wireframes, mockups and prototypes?
Figma covers all three and is the most common choice; Balsamiq and Whimsical specialise in quick wireframes; Sketch and Adobe XD produce mockups and clickable prototypes; Framer and coded prototypes in HTML or a framework suit high-fidelity behaviour. Paper and a marker remain the fastest wireframing tool.
How long does it take to create a mockup?
A few hours to a day per key screen for a considered, responsive design with real copy and the important states, once a visual direction exists. Wireframes take minutes to an hour per screen; prototypes range from an hour for clickable wireframes to weeks for coded versions with real data.
