A mockup is a static, high-fidelity visual representation of an interface that shows how a screen will look when finished, including layout, typography, color, imagery and real or realistic content. In UI design, it sits between the low-fidelity wireframe, which defines structure, and the interactive prototype, which simulates behavior.
Mockups answer the question what will this look like rather than how it works. They are used to align stakeholders on visual direction, to test the design system against real content and to give developers a precise visual reference for implementation.
What a mockup contains
A complete mockup contains every visual decision for a screen or state, rendered as it should appear to users. It is built from the same components and tokens that will be used in production, so it doubles as a check of the design system.
- Final layout and spacing, including grid, margins and breakpoints.
- Typography with actual typefaces, sizes, weights and line heights.
- Color and imagery: brand palette, icons, illustrations and photographs.
- Realistic content: real labels, plausible names, long and short text variants.
- Component states such as hover, focus, disabled, error, loading and empty.
Mockups remain static images or frames. Even when they are linked together for a walkthrough, they do not represent transitions, input behavior or timing, which belong to the prototype.
Most teams produce mockups in collaborative vector design tools that share a component library with the codebase. When a component changes in the library, every mockup that uses it updates as well, which keeps large sets of screens consistent without manual rework.
Mockup compared with wireframe and prototype
Wireframe, mockup and prototype differ mainly in fidelity and interactivity. Treating them as distinct artifacts helps teams ask the right questions at the right time.
| Artifact | Visual fidelity | Interactivity | Main question answered |
|---|---|---|---|
| Sketch | Very low | None | Is the idea worth exploring |
| Wireframe | Low, grayscale boxes | None or minimal | What goes where on the screen |
| Mockup | High, near final | None | What the screen will look like |
| Prototype | Low to high | Simulated | How the product behaves and flows |
| Production build | Final | Real | Does it work with real data and code |
The term is also used for device mockups, in which a finished screen is placed inside an image of a phone, laptop or billboard for presentations and marketing. These are presentation graphics, not design artifacts for decision-making, and the distinction should be clear in project communication.
Fidelity levels and when to use them
Fidelity is not a single setting but a mix of visual, content and component fidelity. Teams can raise one dimension while keeping others low, depending on what they need to learn.
| Dimension | Low setting | High setting | When high fidelity matters |
|---|---|---|---|
| Visual fidelity | Approximate colors and fonts | Exact tokens and assets | Brand reviews and handoff |
| Content fidelity | Placeholder text | Real copy and data | Testing text length and tone |
| Component fidelity | Ad hoc shapes | Design system components | Checking consistency and reuse |
| State coverage | Default state only | All key states and errors | Development estimates and QA |
| Breakpoint coverage | One screen width | Mobile, tablet and desktop | Responsive implementation |
Investing in high fidelity too early makes stakeholders comment on colors instead of structure. A practical sequence is to settle structure in wireframes first and move to mockups once the information architecture and main flows are stable.
Lower-fidelity mockups still have a place. A mid-fidelity mockup with real layout but simplified styling can help when a brand is still being defined, because it lets the team progress on structure while visual decisions remain open. The key is to tell reviewers which aspects are final and which are not.
Using mockups in the design workflow
Mockups serve different audiences at different stages, and their preparation should follow the purpose they serve.
| Purpose | Audience | Practical guidance |
|---|---|---|
| Visual direction approval | Stakeholders and brand owners | Show two or three directions on the same content |
| Design system validation | Design team | Build only from existing components and tokens |
| Developer handoff | Engineers | Annotate spacing, states and responsive behavior |
| Content review | Writers and editors | Use real copy, including the longest variants |
| Preference or first-impression testing | Users | Ask about clarity and trust, not about function |
For handoff, mockups are most useful when they are named, organized by flow and linked to components. Inspection tools can expose measurements and token names directly, which reduces the need for manual redlines.
Common mockup pitfalls
Mockups can create false confidence because they look finished. The most frequent problems are listed below.
- Ideal data only: short names, perfect photos and round numbers hide layout failures with real content.
- Missing states: errors, empty screens and loading conditions are left for developers to invent.
- Single breakpoint: designs that exist only at desktop width force guesswork on mobile.
- Detached components: one-off visual tweaks drift away from the design system.
- Mistaking approval for validation: liking a mockup does not prove that users can complete their tasks.
Usability questions must still be tested with a prototype or the working product, because static mockups cannot reveal problems with flow, feedback or timing.
In simple terms
A mockup is a realistic picture of a screen before anyone builds it. It shows the colors, text, pictures and buttons exactly as they are meant to look.
Think of an architect’s color rendering of a house. You can see how it will look, but you cannot open the doors yet. A mockup lets the team agree on the appearance early, when changes are still cheap.
A practical example
A product team is redesigning the account settings area of a banking app. After wireframes for five screens have been approved, a designer builds mockups for mobile and desktop using the company’s design system components.
The mockups use real field labels and test data, including a customer name of 38 characters and an address with three lines. This reveals that the profile header breaks at narrow widths, so the designer adds truncation rules and a two-line layout before development starts. Each screen also gets error, loading and empty states.
Engineers receive annotated frames with token names and breakpoints. During implementation, the team logs far fewer visual questions than in the previous release, and the remaining usability checks move on to an interactive prototype of the most complex flow.