A mockup is the version of a design where the thing finally looks like itself. Static, high fidelity, nothing clickable. Colors, type, and spacing all sitting where they’ll sit on launch day.

Teams build one after the wireframe has settled the page structure. From there the same flat file gets passed around to clients, developers, and whoever owns marketing, so everybody is arguing about the same shade of blue instead of picturing their own.

The word is older than you’d guess. Merriam-Webster dates the first known use to 1920, when it meant a full-scale model built for testing or display. Shipbuilders and aircraft manufacturers were doing it in plywood long before anyone did it in pixels.

What Is a Mockup?

Take a finished-looking interface, strip out every bit of behavior, and what’s left is a mockup. Flat image, real design.

No hover states that actually hover. No screens linking to other screens. Just the visual treatment, arranged the way it’s meant to ship.

The job it does is narrow on purpose. It hands everyone a visual finish line with no interaction attached, which is what separates it from a napkin sketch or an early concept pass.

Designers switch into mockup mode once structure stops being the open question. Layout is approved. What’s left is appearance.

Things that get pinned down at this point, roughly in the order most people handle them:

  • Color palette and brand accents
  • Typography, including font weight and line height
  • Spacing, grid alignment, and visual hierarchy
  • Imagery, icons, and whatever decorative elements the brand insists on

It shows every part of the user interface the way a visitor will actually see it, down to button shadows and paragraph spacing.

Real projects cheat here constantly. Stock photography stands in, the logo is a placeholder, the headshots are strangers in a field. That’s fine. Get as close to real as the timeline allows and keep moving.

Mockup vs Wireframe vs Prototype

People use these three words interchangeably and then wonder why a review meeting goes sideways. Each one answers a different question at a different point.

A wireframe is about where things go. By the time you’re in a mockup that’s settled and the only open question is what it looks like. Prototypes show up later and deal with behavior, which is a separate problem entirely.

StageFidelityInteractivityTypical Use
WireframeLow, grayscaleNoneStructure, content placement, navigation flow
MockupHigh, staticNoneVisual sign-off, branding, layout approval
PrototypeHighSimulated clicks, transitionsUsability testing, stakeholder demos

Interactivity is the real dividing line. A wireframe has none because it isn’t trying to. A mockup has none because it hasn’t gotten there yet.

Where is web design headed next?

Discover the latest web design statistics: industry growth, design trends, technology adoption, and insights defining the future of the web.

Explore the Data →

Fidelity climbs in the same order, rough to camera-ready. Wireframes stay loose on purpose, mockups get within a pixel or two of final, and prototypes carry that same polish with working navigation layered on.

Jumping from wireframe straight to prototype usually backfires. You end up picking colors and type inside a tool built for testing interaction, which is slower than settling those calls in a flat file first.

Where a Mockup Fits in the Design Process

The mockup sits in the middle of the timeline. Structure has been approved, and nothing real has been built yet.

Research, wireframe, mockup, prototype, developer handoff. Skip one and something downstream tends to break, usually later than you’d like.

Design work doesn’t happen off to the side from the rest of the user experience process, either. Research findings and usability goals feed straight into what the mockup ends up looking like.

Wireframing Comes First

A mockup depends on an approved wireframe. Without one, designers are guessing at structure while also trying to pin down visuals, and that’s how projects drift.

  • Wireframe locks the layout and content hierarchy
  • Stakeholders sign off on structure before style enters the conversation
  • Navigation and user flow get tested in rough form first

Once that structure holds, the mockup phase goes quickly. Half the decisions are already behind you.

Prototyping and Handoff Come After

A finished mockup feeds two different things, and both come from the same static file.

Prototyping tools import it and layer in clickable states and screen links. Visuals stay put, behavior gets added on top.

On the build side, the mockup becomes the source of truth once it moves into frontend development. Developers pull exact colors, spacing values, and font sizes from the file instead of eyeballing them.

Handoff tools like Zeplin exist for exactly this gap, turning a static mockup into measurements and code snippets a developer can copy.

Why Design Teams Use Mockups

Mockups exist because visual mistakes are much cheaper to catch on a flat image than inside a shipped product.

The numbers behind that are old, and they’ve held up. Stecklein’s team at NASA put the cost of fixing an error caught at the design stage at 3 to 8 times what the same error would have cost at the requirements stage (NASA, Stecklein et al., 2004). Let it survive into integration and testing and the multiplier jumps to 21 to 78 times (NASA, Stecklein et al., 2004). Ullman’s figure is the one I find more persuasive, honestly: 75% of a product’s total cost gets committed during the concept and design stage (Ullman, cited in ICED17 proceedings, 2017).

That’s the whole business case, compressed. A mockup surfaces branding mismatches, cramped spacing, and type choices that fight each other while a fix still means dragging layers around rather than rewriting code.

There’s a softer reason too. Clients can’t approve what they can’t picture.

A wireframe asks them to imagine color and imagery. A mockup just shows them, which ends a surprising number of arguments before they start.

Who Relies on Mockups

Product and marketing teams use mockups to pressure-test branding before it goes live in twelve places at once.

For developers it’s a build reference, nothing more romantic than that. Spacing and color values get pulled straight from the file.

Clients are the interesting case. The mockup is usually the moment a project stops being abstract, and that’s often what unlocks final budget approval.

None of it works without a baseline of usability already baked in at the wireframe stage. A gorgeous mockup built on a confusing structure just becomes a gorgeous, confusing product.

Which is why user-centered design principles stay in the room even after the team has moved from structure to style.

Types of Mockups by Application

Not every mockup looks the same, because not every product ships the same way. Format follows what’s being built and who’s going to look at it.

UI Mockups

Low-fidelity versus high-fidelity UI mockup

These zoom in on individual screens, states, and components instead of a whole page at once.

Usually that means button states (default, hover, disabled), form fields and their validation styling, modals, dropdowns, navigation menus, plus the component variants and spacing rules that hold the whole set together.

Most of that structure sits on a grid system, which is what keeps alignment from falling apart once real content replaces the placeholder blocks.

Mobile UI mockups tend to lean on platform conventions, Apple’s Human Interface Guidelines or Google’s Material Design, so the interface reads as native instead of like a website in a phone frame.

Website and App Mockups

Website mockup built from a Canva template

These cover a full page or screen, showing how the components sit together rather than in isolation.

A homepage mockup, a landing page mockup, and a checkout flow mockup are all doing the same job at different points in the funnel.

App mockups usually get built for a handful of core screens instead of the whole product. Rendering every screen at high fidelity before the concept has been validated is a good way to throw work away.

Print and Packaging Mockups

Product and packaging mockups

Not everything a mockup shows lives on a screen. Packaging, business cards, and print collateral get mocked up too, usually wrapped around a 3D object render or laid out on a flat die-line template.

Print work has its own requirements. Bleed and safe zones have to be marked for the printer, color values need to be CMYK rather than RGB, and the client presentation almost always wants a 3D or photographic render rather than a flat file.

Getting print wrong is expensive in a way screen design isn’t. There’s no hotfix once a few thousand boxes come off the run in the wrong blue.

Mockup Output Formats and File Types

A finished mockup rarely ships as a single file. Different people down the chain need different versions of the same design.

PNG or JPG for quick sharing and client review. PDF when it’s going into a presentation deck or a print-ready packaging mockup. And the layered source file, whether that’s a PSD or a native Figma or Sketch file, for anyone who still has to edit it.

Who’s receiving it decides the format, basically.

A client gets the flat PNG or the PDF deck. A developer gets the actual source, so they can inspect spacing, grab hex codes, and export assets without asking anyone.

Losing that source file is a worse problem than it sounds. A flattened PNG can’t be edited, only redrawn, and it happens more often than it should on small projects that never set up a proper handoff.

Cloud-based tools mostly sidestep this. The working file lives on a server, so anyone with access opens the editable version instead of chasing exports through email.

Best Tools for Creating Mockups

Sketch app for creating mockups

Most teams settle on one main tool and keep a second one around for the formats it doesn’t handle, usually packaging or print.

ToolCategoryBest For
FigmaBrowser-based UI designTeams needing real-time collaboration
SketchmacOS-native design appApple-centric solo designers, small teams
Photoshop / IllustratorRaster and vector editingPrint and packaging mockups
Smartmockups / PlaceitMockup generatorsQuick device and merchandise mockups

Ramp’s October 2025 vendor data shows 94% of organizations that already use a design tool have Figma somewhere in the mix. That’s less a preference at this point and more a default.

Adobe XD used to be part of this conversation.

That ended in 2023, when Adobe pulled XD from standalone sale and moved it into maintenance mode while its planned acquisition of Figma was still under regulatory review. The deal collapsed in December 2023, and Adobe confirmed the following month that it had no further plans to invest in XD.

It still runs for existing users. Nobody starts new projects there.

Figma lives in a browser tab, which is most of why it won. Multiple people in the same file, no version numbers in filenames, no final\_v3\_REAL.fig sitting on somebody’s desktop. It does want a stable connection, and large files get sluggish in a way that’s irritating rather than fatal.

Sketch is Mac only and its collaboration story is thinner, but the native performance is real and the plugin library has a decade behind it. Loyalists will tell you nothing running in a browser tab comes close. For solo work on a Mac they’re not entirely wrong.

Beginners usually do fine just picking whatever their team already uses. You can design a website in Figma without opening anything else, since wireframing, mockup, and prototyping all live in the same file.

Cost is worth a thought. Figma’s free vs professional plan split covers most solo and small-team work, and the pressure to upgrade only really shows up once several people need to edit the same file at the same time.

How to Create a Mockup

Once the wireframe is locked, the order is fairly predictable. Most of the pain at this stage comes from skipping something in it.

  1. Start from the approved wireframe, using its structure and content hierarchy as the frame
  2. Apply the visual system, meaning brand colors, typography, grid spacing, and imagery
  3. Swap placeholder text for real or near-final content wherever you can get it
  4. Export in whatever format the next stage actually needs
  5. Run a design review with stakeholders before anything goes to prototyping

Step three trips up more teams than it should. Real content changes line counts, button widths, and card heights in ways filler text never will, and you find out during the review instead of before it.

Step four depends on who’s next in line. Sharing a client-ready file usually means learning how to export a Figma file to PDF, because that’s the format most stakeholders will actually open.

A developer working in Figma’s Dev Mode, which showed up at Config in June 2023, skips the export and pulls measurements from the file directly. The Dev Mode workflow exists partly because roughly a third of Figma’s weekly users are developers, not designers.

Skipping step five is tempting when a deadline is close. It’s also how a mockup that looked fine in isolation turns into three rounds of revision the first time someone with budget authority sees it.

Common Mockup Mistakes

Most mockup problems come from a small set of repeat offenders. None of them are hard to fix once you know what you’re looking at.

MistakeWhy It HurtsFix
Filler text everywhereHides real layout and spacing problemsSwap in near-final content before review
Skipping wireframe approvalStructure decisions get made mid-styleLock layout first, then move to visuals
Treating it as finalStakeholders never actually signed offGet explicit approval, not silence
Flat-image-only exportNo editable file for later changesKeep the source file, not just the export

Placeholder text is the most common one by a wide margin. Ad Hoc’s UX research team found that lorem ipsum trips up test participants and stakeholders alike, since neither group can give useful feedback on text they can’t read.

Skipping wireframe sign-off is the second. A mockup built on unapproved structure means someone requests a layout change after the colors and imagery are already locked, which destroys the exact work the mockup was supposed to protect.

Treating the mockup as final without an actual approval step does a quieter kind of damage. Nobody said yes. Nobody said no either, and a silent assumption is not a decision.

That gap shows up in the data. Differing assumptions are the most common challenge developers report when working with designers, cited by 52% of developers in Figma’s own State of the Designer report.

The fourth one is the file-export problem from earlier, playing out at its worst. The original designer leaves, nobody can find the working file, and a five-minute text edit becomes a rebuild from scratch.

Setting up developer handoff properly at the start avoids that whole scenario.

When a Mockup Does Not Apply

A mockup earns its place on most projects. Not all of them. Skipping it isn’t cutting corners when the situation genuinely doesn’t call for one.

Reasonable times to skip it:

  • The project is small enough that a wireframe alone gets sign-off
  • Interaction, not appearance, is the real open question
  • It’s an internal tool with no outside stakeholder to impress
  • The team is iterating faster than a static file can keep up with

Small projects rarely need the extra pass. A five-page brochure site with an established brand kit can go straight from wireframe to build, because there’s nothing risky left to visualize.

When interaction is the actual risk, a rough prototype beats a polished picture. Testing whether a checkout flow makes sense takes clickable screens, not perfect typography.

That’s usually the moment teams jump straight to a prototyping tool. Building clickable flows directly in Figma tests behavior without burning a day on a visual pass first.

Internal tools shift the math too. A dashboard for twelve people on the ops team doesn’t need the same visual sign-off as a public product. No brand risk, no outside stakeholder waiting to approve a color.

Client work sits at the opposite end. Prepping a Figma file for a client presentation is often the entire reason the mockup exists.

Agile cycles are where this gets genuinely tricky.

71% of surveyed software teams now run Agile as part of their development lifecycle, according to Digital.ai’s 17th State of Agile Report (2024). Sprints that short can outrun a static file before it’s even done.

Figma leaned into that directly. The company launched Figma Make in May 2025, letting designers go from a written prompt to a working prototype and skip the static image step altogether.

That doesn’t make mockups optional for most product work. It means the static, high-fidelity step addresses one specific kind of risk, visual and brand risk mostly, and forcing it into every project wastes the time it was meant to save.

FAQ on What Is A Mockup

What else is a mockup called?

Designers sometimes call it a comp, short for composite, a term borrowed from print and graphic design. Product teams say high-fidelity design or visual design file just as often. None of those names change what the deliverable does.

How much does a mockup cost or how long does it take?

Cost and turnaround scale with scope, not a fixed rate. A landing page mockup is a matter of hours. A full multi-screen app runs into days, with pricing tied to complexity and how many revision rounds are in the contract.

Can AI tools generate mockups automatically?

Yes. Tools like Uizard turn a written prompt or a hand-drawn sketch into an editable, multi-screen mockup in seconds. Output quality varies a lot, and most teams treat what comes back as a starting point rather than something they’d send a client.

What Comes After a Mockup Gets Approved?

An approved mockup moves into prototyping, where the same static file picks up clickable states, working transitions, and a testable navigation flow. Still no production code.

Starting that work before the file is fully locked has a real cost. Every click state and transition gets rebuilt each time a color, a spacing value, or a layout decision shifts upstream.

The boundary is already moving, though. AI-assisted tools like Figma Make are compressing the gap between a flat design file and a working prototype, which is worth rechecking as of September 2026.

For most people the next step is making a Figma file interactive, where the design starts responding to clicks instead of just sitting there.

Bogdan Sandu
Latest posts by Bogdan Sandu (see all)