Wireframe vs. mockup vs. site map: how to explain it to clients

Most people assume the wireframe vs. mockup thing is just designer vocabulary — but if that were true, your client wouldn’t be sitting there staring at a screen of gray rectangles, wondering why the website they just paid for looks like a 1998 IRS form. Here’s what you actually need to know about wireframes vs. mockups, plus what to say so your client doesn’t spiral before you’ve even started ✨

What’s the difference between a wireframe vs. mockup?

A wireframe is the structure. A mockup is the design.

A wireframe answers where does everything go — logo up here, nav across the top, services in a three-column grid, contact form at the bottom. A mockup answers what does it look like — their brand colors, their fonts, the headshots they spent four months and a photographer’s deposit on.

And the order matters for a reason that has nothing to do with design theory and everything to do with money: it’s a hell of a lot cheaper to move a wall on a blueprint than after the drywall’s up, you know?

What’s another word for wireframe?

Okay, this is the part where I tell you the industry can’t agree on its own vocabulary and you just have to make peace with it.

Figma, Miro, and every UX blog on page one will tell you wireframe means the low-fidelity skeleton and mockup means the high-fidelity visual. Plenty of studios use them backwards. Some say comp. Some say mock. Some say “design concept” 🙃

For me, the skeleton is a site map and the high-fidelity version is a wireframe.

What matters is that your client knows which one they’re looking at, and what you need from them at that stage.

Pick your vocabulary! Use the same words every single time! Define them the first time your client sees the deliverables!

(Reading the rest of this through the standard definitions? Go for it. Just swap your own labels in as you go 🏃‍♀️)

Is a wireframe a prototype?

No. A prototype is a wireframe or a mockup you can click. (Yes, that’s a third word. I didn’t make the rules 🤷🏼‍♀️)

Same content, but the buttons work, the menu opens, and you can move through it like a real site. Pretty useful for testing flows on complex apps and huge, custom-coded websites. . . Usually overkill for a five-page website for a small biz.

If a client asks for “a prototype,” ask what they want to do with it. Nine times out of ten they mean “I want to see it before you build it” — which is a mockup (or in my case, a wireframe!)

Are wireframes a waste of time?

People Google this constantly, so I’m guessing it’s turned up in your search history too. And it’s a valid question!

You’re looking at a page of gray boxes thinking I could have just designed this by now. (You could have BUT that’s not the point™️)

But no, they’re not a waste of time and here’s why.

When you skip structure and go straight to full-color design, you’re asking your client to judge layout and aesthetics at the same time. Then they say “I don’t love it,” and you have no idea what the f*ck they mean. 

The section order? 

The color? 

The photo? 

The fact that their headshot is on the left? 🫠

Separating the stages separates the feedback. A client who says “I don’t love it” about a gray box is telling you something specific and useful: the page structure isn’t working. That’s a much quicker fix to rename a grey box than to re-design or move a whole section on a website.

How to explain wireframes and mockups to clients

Here’s roughly what I say so that people understand what they’re looking at:

For the structure stage

“Think of this like the skeleton for your website. It shows where everything goes — all the pages on your site and the sections inside those pages — but it doesn’t show what it’ll look like yet. This is how we make sure the flow of the website works before we spend time on designing it.”

For the design stage

“This is a preview of the finished website. It shows exactly what your site will look like — your brand colors, your fonts, your images, all of it! This is where you approve the design before we build it.”

How to present the wireframe stage without scaring anyone

Set expectations before they open the file. “This is going to look basic on purpose.” A client who’s expecting boxes connected by lines will react differently than one who goes in not sure what they’re about to look at.

Walk them through it section by section. Don’t send a link and hope 🙏 Record a Loom (or my screen recording platform of choice, Komodo Decks) video walking them through it, explain your reasoning! “Here’s your hero section, here’s where we talk about what sets you apart in your industry, here’s the final call to action section that will send them to your contact page.”

Point their feedback where you want it. Ask specific questions that don’t have anything to do with design: “Does this structure make sense? Is anything missing that you want to include?”

There’s a lot more to this one — scripts for the awkward moments, what to do when a client wants to talk about the design before you get there, how to handle the one that ghosts for six days and then starts a separate email thread for disorganized feedback at 11:42pm. That’s its own post, and it’s coming: how to present wireframes to clients.

So, basically…

Your client doesn’t need to know the difference between site map, wireframe, or mockup. They need to know which stage they’re in, what they’re looking at, and what you’re asking them for. Nail that and the boxes with lines stop being scary 🫶

Here’s how I can help with yours:

>> Want the whole thing off your plate? Design and development together — or, as I affectionately call it, the whole damn thing.

>> Love playing in Figma but would rather set yourself on fire than bring it into Showit? Hand off just the dev.

>> Not sure outsourcing changes your numbers? Run them here — it’ll show you how outsourcing can not only help you scale your biz BUT ALSO show you how it will give you back the greatest gift there is: time!