Product teams burn a surprising amount of time arguing about three words. Someone asks for "a quick mockup" and gets a clickable prototype two days later. Someone shares "wireframes" that turn out to be fully styled screens, and the review derails into a debate about the accent color. The vocabulary problem is really a decision problem: each artifact exists to settle a different question, and using the wrong one invites feedback on the wrong thing.
Here is the short version, then the useful detail.
| Wireframe | Mockup | Prototype | |
|---|---|---|---|
| Shows | Structure and flow | Visual design | Behavior |
| Fidelity | Low, deliberately plain | High, pixel-accurate | Varies, up to fully working |
| Interactive | No | No | Yes |
| Settles | What goes where | How it looks | How it works |
| Cost to change | Minutes | Hours | Hours to days |
What a wireframe decides
A wireframe is the grey-box sketch of a screen: rectangles for images, lines for text, labels for buttons. It answers three questions and nothing else. What is on this screen? Where does it sit? How does a person move to the next screen?
The plainness is a feature. When nothing is styled, reviewers critique the structure, which is the only thing that exists yet. Show the same layout with a nice font and the conversation drifts to the font. Our guide to wireframing covers this stage in depth, and how to wireframe walks through the practical steps.
Use a wireframe when the open question is layout, hierarchy, or flow. Skip ahead when those are already settled, for instance when you are redesigning the skin of a screen whose structure stays put.
What a mockup decides
A mockup takes an agreed structure and dresses it: real typography, real color, real imagery, real spacing. It is a static picture of the finished screen, accurate to the pixel and inert to the click.
Mockups settle visual questions. Does the brand come through? Is the hierarchy readable at a glance? Do the states (empty, loading, error) hold up visually? A mockup is also the classic handoff artifact, the picture an engineer builds from.
That handoff role is where mockups are losing ground. Teams with a mature design system rarely need to decide the visual language per screen, because the system already decided it. And when an agent can produce the working screen directly from a wireframe and a brief, a static picture of that screen is a detour. The mockup earns its keep mainly when the visual design itself is the open question: brand work, marketing pages, anything where look is the product.
What a prototype decides
A prototype answers the question neither picture can: what is it like to use this? At minimum that means clickable screens wired together so a person can walk the flow. At maximum it means a working piece of software with real logic and real data, which is the strongest evidence you can put in front of a user short of shipping.
Prototypes settle behavior. Does the flow make sense in motion? Where do people stall? Does the interaction feel right at real speed, with real content, on a real device? The prototyping pillar covers the forms this can take, from paper to production-grade.
The classic caveat about prototypes was cost: making things work took far longer than making things look right, so teams prototyped only the risky parts. That ratio has collapsed. On a canvas where an agent writes real code, a working prototype of a screen costs minutes, which is why the wireframe-to-prototype jump increasingly skips the middle artifact. An AI prototyping tool turns the grey boxes into the running version on the same surface, and the mockup stage quietly disappears.
When to skip one
A reasonable modern default for product work:
- Always think in wireframes. Even if the artifact lives for an hour, the structural pass is where the expensive mistakes get caught cheaply.
- Skip the mockup when a design system answers the visual questions. Keep it for brand-led work where the look is the decision.
- Prototype the parts that carry risk. Flows people must complete, interactions that could confuse, anything you would rather learn about before shipping. When working prototypes cost minutes, the honest answer to "should we prototype this?" is usually yes.
The three words describe a sequence of narrowing questions: what goes where, how it looks, how it works. Use whichever artifact matches the question in front of you, and do not let anyone review the font on a wireframe.