Wireframe

A wireframe is a plain drawing of a web page showing what goes on it and in what order, made before anybody chooses a colour or a typeface. Boxes stand in for images, lines stand in for text, and everything is grey. It is the stage where an agency asks you to agree the shape of a page while changing it is still nearly free.

In short

• A plain layout drawing showing what goes where on a page.
• The absence of colour and images is deliberate.
• Review the order and what is missing, not the appearance.
• Changes here take minutes. The same changes after the build take days.

What it is for

Every website project has a moment where changing your mind is cheap and a later moment where it is expensive, and the distance between them is short. Moving a section in a wireframe is a matter of dragging a box. Moving the same section once the page has been designed means redoing the design. Moving it after the site is built means development, testing, and a conversation about who pays for it.

Wireframing exists to pull the arguments forward into the cheap part. If the booking form should be higher up the page, that is a two-minute discussion now and a two-day one in six weeks.

The greyness is doing work in that conversation. Show somebody a finished-looking design and they respond to the photograph and the colour. Show them a grey box labelled photograph and they notice that the opening hours are nowhere on the page.

The three stages, and the words for them

These get used interchangeably in conversation, which causes confusion about what is actually being approved.

• Wireframe. Structure. What is on the page and in what order. Grey.
• Mockup. Appearance. The wireframe with real colours, type, photographs and spacing applied. Looks like the finished thing and does nothing. Designers also use the word for a logo shown on a shopfront or a van, which is a different sense of it, described under graphic design.
• Prototype. Behaviour. Something clickable, used to check that the journey from one page to the next makes sense before it is built.

Not every project needs all three. A small site on an established template may reasonably skip straight to a mockup, because the layout was decided by the template. A shop with a checkout to design will want all three, since the cost of discovering a problem in the finished checkout is considerable.

How to review one without wasting the meeting

This is the part where clients most often feel they are being asked to judge something they have no vocabulary for, so it is worth having the questions ready.

• Is the thing you most want understood at the top? Not your company history. The thing somebody came to find out.
• Is it obvious what you want them to do? There should be one clear action, and you should be able to point at it. What that action needs to look like is on the call to action entry.
• Is anything a customer always asks about missing? Opening hours, service areas, whether you deliver, how long it takes.
• Does the order match how somebody decides? People need to know what it is before they care who you are.
• Is there too much? A wireframe with eleven sections is a page nobody will reach the bottom of.

Comments about fonts, colours and specific photographs are not useful yet, and a designer will usually say so politely and then design what they were going to design anyway. Save them for the mockup, where they are exactly the right comments.

The placeholder text problem

Wireframes are usually filled with meaningless Latin, and it is worth knowing why that is both normal and a risk. Early on it is a convenience. The layout is being judged, and real text would distract from that. Later it becomes a way of hiding that nobody has written anything. A page approved around neat placeholder blocks assumes the real headings will be that short and the real paragraphs that tidy, and they usually are not. What arrives instead is a heading that runs onto three lines and a section that was designed for forty words and needs a hundred and fifty.

The safeguard is small. Ask for the real headings and the real first paragraph of each section before the wireframe is signed off. If those do not exist yet, the site is not ready to be designed, and finding that out now is a favour.

Start narrow

Most people who look at your site will be holding a phone, which makes the narrow layout the one that matters and the one usually drawn second.

Drawn in a single column, every decision about order becomes unavoidable, because there is no second column to hide anything in. Everything is above or below something else, and you have to say which. That constraint is what makes a mobile wireframe useful even for people who mainly picture their site on a monitor.

Widening a design that works in one column is ordinary work. Narrowing one built around three columns of equal importance means deciding, late and under pressure, which two of them get pushed below the fold. How that adaptation happens at all is covered under responsive design.

The thing to remember

A wireframe is the cheapest disagreement you will ever have about your website. Every objection raised at this stage costs a conversation. The same objection raised after launch costs a rebuild, and by then most people have decided it is easier to live with it.

So take the meeting seriously even though the drawing looks unfinished. It looks unfinished because that is the point of it.

Words you will hear

• Fidelity. How finished it looks. Low fidelity is a sketch, high fidelity is close to a mockup.
• Hero. The top section of a page, the first thing visible.
• Above the fold. What is on screen before scrolling.
• Grid. The underlying column structure everything aligns to.
• Annotation. Notes on the wireframe explaining what something does, which is where the useful detail usually hides.
• Lorem ipsum. The placeholder Latin.
• Sign-off. The point at which you agree the structure and later changes become chargeable. Worth being clear about when it happens.