A wireframe is a plain layout of a page, drawn before any colours or photos are chosen. It lets you agree what goes where while changes are still cheap.
A website wireframe is a simple, mostly black-and-white layout of a page. It shows what content appears, in what order, and where the links, buttons and forms sit. It leaves out colours, fonts and photos. A mockup adds the visual design, and a prototype adds clickable behaviour. Small sites on a ready-made theme can often start from a page list and a sketch instead.
What is a website wireframe?
A website wireframe is a simple layout drawing of one page. It shows which blocks appear on the page, in what order, and where the links, buttons and forms sit. It uses boxes, lines and labels in place of final colours, fonts and photos, so the only thing under discussion is structure.
Think of the floor plan of a house before any paint is chosen. A floor plan shows where the rooms are, how big they are and where the doors go. Nobody judges the wallpaper at that stage. A wireframe works the same way: it settles the order of a page and what a visitor does next before anyone spends time on how it looks.
A wireframe can be a sketch on paper, a drawing on a whiteboard or a file made in design software. The format matters far less than the questions it answers. What is this page for? What does a visitor need to see first? What should they do next?
Most sites need one wireframe for each type of page and not one for every page. A home page, a service page, an article page and a contact page are four types. Twenty service pages built on the same layout share a single wireframe.
What a wireframe shows and what it leaves out
A wireframe records decisions about content and layout. The table lists what normally appears on one and what normally does not.
| Usually shown | Usually left out |
|---|---|
| Page sections in order, such as header, introduction, services, proof and footer | Final colours and brand style |
| The main navigation and where it sits | Final fonts and type sizes |
| Headings, and roughly how much text each block needs | Final photos and illustrations |
| Buttons, links and form fields, with labels | Animation and sound |
| Notes on behaviour, such as what a menu does on a small screen | Finished wording, which is often placeholder text at this stage |
Because the visual layer is missing, feedback stays on structure. A comment such as "the contact form should come before the long text" is useful at this stage. A comment such as "I do not like the blue" is not, because there is no blue yet.
Wireframe vs mockup vs prototype
The difference between a wireframe and a mockup is how much of the final look is present. A wireframe has none of it. A mockup is a static picture of the finished page, with real colours, fonts and images. A prototype is a version you can click through to see how links, menus and forms behave. Design teams call this fidelity: how closely the draft matches the finished site.
| Stage | What it is | What it settles |
|---|---|---|
| Sketch | A rough drawing by hand | Early ideas, tried quickly alone or in a meeting |
| Wireframe | Structure in boxes and labels | Content order, the purpose of each page and the next step for the visitor |
| Mockup | A static picture with the final styling | Look, brand fit and readability |
| Prototype | A clickable version, with varying detail | How the pages work, before anyone builds them |
People use these words loosely. Some designers call a plain wireframe a low-fidelity mockup, and a wireframe with real text and careful spacing may be called high-fidelity. When someone sends you a file, ask what it is meant to settle and what is still open. The answer matters more than the label.
Why a wireframe is worth making
A wireframe is worth making because changing a box on a drawing costs far less than changing a page that has been designed or built. It is the cheapest point in a website project at which to find a wrong idea.
It also forces choices that are easy to put off. Each page needs one main purpose and one next step for the visitor. Once those are drawn, a page with five competing buttons is obvious. Missing pieces show up too: a service page with nowhere to ask for a quote, or a product page with no space for delivery information.
A wireframe gives everyone the same thing to look at. The owner, the designer and the developer can point at the same box instead of describing a page in words. For the developer it is also a clearer instruction than a long email, so the build follows an agreed page and not someone's reading of a description.
Do you need wireframes for a small website?
Not always. A small site built on a ready-made theme often does not need formal wireframes. The theme already sets much of the layout, so the useful work is a list of pages, an outline of what goes on each, and a rough sketch of the home page. That takes an hour with a pen and not a design project.
Formal wireframes pay off in these situations:
- The site has a custom design and the layout is not decided by a theme.
- It has several page types, such as services, articles, a gallery and a booking page.
- It is an online store, where product, category, basket and checkout pages each need thought.
- More than one person has to approve the result, and you want to avoid late disagreement.
- It is a redesign of a site that already brings in visitors, and useful pages must not be lost.
If you are choosing between a theme-based site and one built from scratch, the guide to WordPress against a custom website sets out the trade-offs. With a theme, the wireframe shows where your content sits inside it and what you plan to change. With a custom build, the wireframe is the starting point for the whole design.
How to read a wireframe
Read a wireframe from top to bottom as a visitor would, and ignore anything that looks unfinished. A grey rectangle with a cross through it is a picture that will be chosen later. Horizontal lines stand in for text. A rectangle with a label is a button. Numbers or notes beside a block explain what it does.
The words in a wireframe are often placeholders. A heading reading "Headline goes here" tells you that a headline exists and roughly how long it can be. It does not tell you what it will say. Judge the position and size of each block, not the wording.
Then ask two things of each page. Could a stranger tell within a few seconds what the page is for, and is the main action easy to find? After that, look for blocks that a visitor would not miss if they were gone. A page full of those is usually carrying content that someone added to avoid an argument.
What to check before design starts
Treat the wireframe review as a gate. Once visual design begins, structure changes get more expensive, so check these points while the layout is still plain.
- Each page has one main purpose and one clear next step, and the navigation matches your list of pages.
- Content you do not have yet is marked. A layout that looks tidy with three lines of text may break with thirty, and an empty testimonials block is worse than none.
- Forms ask only for what you need, and the wireframe shows what the visitor sees after sending one.
- A small-screen layout exists. Many visitors use a phone, so the order of blocks on a narrow screen should be drawn and not left to chance.
- Features that need security attention are flagged: logins, payments, file uploads and third-party widgets. The website security checklist lists what each one adds to the work.
- Features that slow a page are flagged: autoplaying video, large sliders, many fonts and stacks of embedded widgets. The guide to checking and improving website speed explains how to measure the effect once the page is built.
- If the structure changes, old addresses are listed next to the new ones. A page that moves needs a redirect, and the choice between a permanent and a temporary one is covered in the guide to 301 and 302 redirects.
How a wireframe is made
The process is short, and most of it is thinking and not drawing.
- List the pages the site needs and write down what each one is for.
- For each page type, list the content it must carry, in order of importance.
- Sketch the blocks on paper or a whiteboard until the order feels right.
- Redraw the sketch tidily, with labels, in whatever tool the team uses.
- Review it with the person who decides, for both desktop and phone layouts.
- Revise, and record what was agreed so that later stages can refer back to it.
A designer or a UX designer usually produces wireframes, and on a small project the developer may do it. No special software is needed to start. If you are briefing someone, your own sketch and page list, prepared before the first meeting, shorten the process more than any tool does.
Common wireframe mistakes
Most problems come from treating the wireframe as something it is not.
- Judging colours, fonts and photos. None are decided yet, so comments on them are noise and the useful comments get lost.
- Letting every idea in. A wireframe makes it easy to add one more section, and a page with ten sections has no single purpose.
- Skipping the phone layout, then finding that a wide table or a long form does not fit.
- Filling blocks with dummy text that is shorter than the real text will be, so the layout looks tidier than it will turn out.
- Approving the layout without the content. Layout and words depend on each other, and a block built for two lines does not suit a paragraph.
- Not recording what was agreed. Weeks later nobody remembers why a section was dropped.
Questions to ask a designer or developer
If someone is making wireframes for you, these questions show how they work.
- Will you wireframe each page type, and will I see phone layouts as well as desktop?
- Who supplies the text and images that go into the blocks, and when are they needed?
- What is settled when I approve the wireframes, and what can still change at the design stage?
- How are changes handled once visual design has started?
- Will the developer see the wireframes before the build, and who checks the finished pages against them?
A team that cannot answer these may not use wireframes in any real way. If you want a team to build the site, the website development service page describes the work Liftup does, which gives you a reference point for your own questions.
Questions and answers
What is a website wireframe?
A website wireframe is a simple layout of a page that shows what content appears, in what order, and where the links, buttons and forms go. It has no final colours, fonts or photos. Its job is to settle structure before visual design begins.
What is the difference between a wireframe and a mockup?
A wireframe shows structure only, in plain boxes and labels. A mockup is a static picture of the page with real colours, fonts and images. People use the terms loosely, so ask what a file is meant to settle before you comment on it.
Do I need wireframes for a small site?
Not always. A small site on a ready-made theme can often start from a page list, a content outline and a sketch of the home page. Wireframes earn their place on custom designs, online stores, sites with several page types and projects where several people must approve the result.
Can I make a wireframe myself?
Yes. Paper, a whiteboard or a simple drawing tool is enough. List the pages, rank the content on each by importance and sketch the blocks in order. A rough sketch with clear notes helps a designer more than a polished file with no explanation.
Should a wireframe use real text?
Use real headings and rough real text where you can. Dummy text hides problems because real wording is usually longer or shorter than the filler. If the copy is not written yet, mark each block with the approximate length it needs.
What happens after the wireframes are approved?
Visual design applies colours, fonts and images to the agreed layout, and the result is usually shown as mockups. The build follows. Changes to structure after that point take more time than changes made at the wireframe stage.
Who makes the wireframes?
A designer or UX designer usually makes them, and on small projects the developer may. Ask who owns this step, because it sits between planning and visual design and can be skipped by mistake.