A wireframe in web design is a plain black and white layout that shows what goes on a page and in what order, before anyone picks colour, type or photography.
It’s the blueprint stage of a website. Its job is to settle structure while structure is still cheap to change.
Most people who search what is a wireframe in web design have just been sent one and aren’t sure what they’re looking at. Grey boxes, placeholder text, no logo. It looks unfinished because it is meant to.
This guide is written for the person reviewing that file, not the person drawing it. What it shows, what it should contain, where it sits in the project, and how to give feedback that actually improves it.
free audit
H2
Lorem ipsum dolor sit amet consectetur. Orci nec in mauris porttitor sapien enim. Est in auctor eget tincidunt ipsum hendrerit facilisis.
What is a Wireframe in Web Design
Four deliverables get confused with each other constantly, and not every agency explains the difference before sending one over.
| Deliverable | The question it answers | What it looks like |
|---|---|---|
| Sitemap | Which pages exist, and how they nest | A diagram or indented list of pages |
| Wireframe | What goes on a page, and in what order | Grey boxes with labels, no styling |
| Mockup | What the page will actually look like | Full colour, real brand, close to final |
| Prototype | How the page behaves when you click it | A clickable version of the mockup |
A wireframe sits between the sitemap and the mockup. If you want the fuller breakdown of how those three differ, we’ve covered sitemaps, wireframes and mockups side by side.
The missing colour is a deliberate choice, not an oversight. Nielsen Norman Group makes the point that designers are far more willing to change a rough layout than a polished one.
The same is true of clients. Once a page looks beautiful, everyone in the room starts defending it, including the people who should be questioning it.
What are wireframes used for?
Wireframes exist to make structural arguments cheap. Every decision below costs minutes at this stage and costs real money after a site is built:
- What earns space above the fold, and what doesn’t
- The order of sections, based on what a buyer needs to know and when
- Where calls to action, forms and phone numbers sit on the page
- Which content you need to write or supply, and roughly how much
- How the page stacks on mobile, not just on a desktop screen
- A clear spec for the developer, so the build isn’t guesswork
Moving a testimonial block above the pricing section takes about thirty seconds in a wireframe. After the site is coded, the same move touches desktop layout, mobile layout, the CMS template and QA. That gap is the whole argument for wireframing.
The three fidelity levels, and which one you’ll see
Fidelity just means how finished something looks. Ask your agency which level they’re sending, because it changes what feedback is useful.
- Low fidelity. Hand sketches or rough boxes. Used in workshops to argue about big structural choices quickly. Rarely sent to clients.
- Mid fidelity. The standard client deliverable. Accurate proportions, real section labels, greyscale, often some real headlines. This is almost certainly what you’ll be reviewing.
- High fidelity. Detailed greyscale layouts with real copy, correct spacing and sometimes basic clickable links. Used on complex pages such as checkouts, booking flows or SaaS onboarding.
None of these include your brand colours or final imagery. That’s the mockup’s job, and it comes next.
What should a website wireframe include?
A wireframe you can actually sign off on includes all of the following:
- The page name, and which template it represents
- Header and navigation structure, including what’s in the main menu
- A defined hero area: headline slot, supporting line, primary call to action
- Content blocks in priority order, each labelled by its purpose, such as proof, objection handling or pricing
- Every form, with the exact fields being asked for and what happens after submit
- Footer content and links
- A mobile view, or written notes on how blocks reorder on a small screen
- Annotations explaining why each section is there
- Realistic placeholder content rather than filler text where possible
That last one matters more than it sounds. NN/g warns against using unrealistic content like Lorem Ipsum in wireframes, because fake text hides the real problem: a headline that needs nine words in the design and takes twenty-two in real life.
If the wireframe you received has no annotations, ask for them. Without an explanation of intent, you’re being asked to approve a layout without being told what it’s for.
How do wireframes help the web design process?
They force disagreement to happen early, while it’s still useful.
A typical project runs discovery, then a sitemap, then wireframes, then visual design, then build. The wireframe is the last checkpoint before things get expensive.
Our own CONVERT framework puts this handoff between step three, where we define the user journey for each key page, and step four, where you approve the full design. Nothing gets designed until the structure is agreed.
For the full sequence, see how a web design project runs from strategy to launch .
There’s a second benefit that nobody mentions in the proposal. A good wireframe tells you exactly what content you owe the project and by when.
Most website delays are content delays. Those usually start because nobody knew what was needed until the design was already built.
How to review a wireframe without derailing the project
Here’s something the design industry doesn’t advertise.
Nielsen Norman Group surveyed 86 UX professionals about the deliverables they produce. It found that static wireframes were the most frequently produced deliverable of all, with 71% making them often.
Yet wireframes did not rank in the top four most effective deliverables for any audience, clients included.
Read that again. The industry’s most-produced deliverable is also one of its worst at explaining itself. The study is from 2015 with a modest sample, so treat it as a signal rather than a hard law.
But if a wireframe has ever landed in your inbox and left you blank, you’re not slow. You were handed a document that was mostly built for the designer.
So the review is on you to run properly. Start by separating the two kinds of feedback.
| Hold this until the design stage | Raise this now |
|---|---|
| “I don’t like the grey” | “Our strongest proof point is buried below the fold” |
| “Can that button be blue?” | “This form asks for five things. Two would convert better” |
| Font and typography preferences | “Every prospect asks about turnaround time and it isn’t on this page” |
| Photo and illustration choices | “Pricing needs to come before the process section” |
| “It looks plain” | “There’s no obvious next step for someone ready to buy” |
The left column is real feedback, just early. Save it. The right column is the only kind that’s expensive to give late.
Then ask these five questions in the review call:
- What is this page’s single job?
- Why is each section here, and why in that position?
- Where does a visitor who is ready to buy actually convert?
- What changes on mobile?
- What content do you need from me, and when?
A designer who can answer all five has thought about your buyer. One who can’t has decorated a layout.
Red flags worth naming out loud
Push back if you see any of these:
- No mobile view and no note on how sections reorder
- Filler text everywhere with no content plan attached
- Every page using an identical layout, which usually means no page has been thought about individually
- Calls to action dropped in at random with no stated logic
- A flat image you can’t comment on, sent with no walkthrough
- No wireframe stage at all, jumping straight to a colour mockup
That last one is worth pausing on. Skipping wireframes is common on template-led projects, because the theme already decided the layout and there’s nothing left to arrange.
That’s a real trade-off, not automatically wrong. We’ve laid out both sides in our comparison of template and custom website builds. Just make sure it was a decision someone made on purpose, rather than a corner quietly cut.
FAQ
Does a small business website really need wireframes?
Yes, though the scope scales down. A five-page site might need wireframes for three unique templates rather than five separate pages, since a service page and a location page often share one structure. What you shouldn’t skip is the homepage and the main conversion page.
Is wireframing included in a web design quote, or billed separately?
It varies, which is why you should ask directly before signing. Most full-service agencies include it in the project fee as part of the design phase. Some cheaper quotes exclude it entirely, which is often why they’re cheaper. Ask for the deliverable list in writing.
Who should be in the room for wireframe approval?
Whoever owns the revenue, plus whoever speaks to customers daily. Sales teams and front-desk staff catch missing information faster than executives do, because they field the same three questions every week and will notice instantly when a page doesn’t answer them.
How many rounds of wireframe revisions are normal?
Two to three for most business websites. One round to react, one to confirm the changes landed. If you’re past four rounds, the problem is usually unresolved strategy rather than layout, and it’s worth going back to what the page is supposed to achieve.
Can I ask for wireframes if my agency didn’t offer them?
Yes, and a reasonable agency will say yes. Frame it as wanting to agree the structure before design starts rather than as a complaint. If they refuse outright, ask what they’ll show you instead before build begins, and how changes get handled after that point.
Do wireframes cover mobile as well as desktop?
They should. Most traffic to service business websites arrives on a phone, and mobile stacking often changes which content a visitor sees first. If you only get desktop wireframes, request the mobile view before you approve anything.
Do I still own the wireframes if I don’t continue with the agency?
That depends entirely on your contract, so check it before the project starts. Ownership of work in progress, including wireframes and design files, should be written down rather than assumed.
Conclusion
Whatever you approve at the wireframe stage is what gets built. That’s the part worth holding on to.
The grey boxes are not a rough draft you can tidy up later. They are the argument about what your website is for and where a ready buyer is supposed to act.
Colour and photography change how that argument feels. They don’t change the argument.
So treat the review as a real meeting rather than a rubber stamp. Bring the person who speaks to your customers every day, because they will spot a missing answer faster than anyone in the business.
Then ask why each section sits where it does, not just whether you like the look of it.
If the answers to those questions are thin, you’ve learned something useful about your agency at the cheapest possible moment to learn it.
