Why good websites start as grey boxes

Let’s face it – wireframes look dull. No beautiful photography. No carefully selected typefaces. No animation. No juicy colours. Nothing more than grey boxes arranged on a white page.

And that’s the point. When all the visual decoration is removed, when there are no images to hate or love and no headlines to critique you’re left with something much more fundamental: decisions to make.

• What should somebody see first?
• What do they need to understand next?
• Which information matters most?
• What can wait?
• Where should they be able to go?
• What questions will they have along the way?
• What do they need to know before we ask them to take action?

A wireframe is where much of the real strategy behind a website gets worked out.

What comes before anatomy?

It isn’t aardvark – it is thinking. In our earlier article, Anatomy of a Homepage, we looked at the thinking behind the homepage we created for Panacea, a software company with a broad offer, multiple products and several potential audiences. The finished homepage we discussed has a deliberate sequence:

• It establishes what Panacea stands for.
• It introduces the wider platform before presenting individual modules.
• It provides evidence.
• It deals with practical questions around procurement.

Only after all this scene setting and contextualising does it ask the visitor to get in touch.

Like an establishing shot in a movie or a character introduction in a novel, none of this happened by accident. Long before colours, imagery and animation entered the conversation these decisions were being made in wireframes. If Anatomy of a Homepage showed the strategy contained in the finished page, let’s rewind a little and look at where that strategy comes from.

A website can’t give everything top billing

One of the most useful things about wireframing is that it forces prioritisation. At the beginning of a website project, there is rarely a shortage of things people want to communicate:

• The leadership team has strategic messages.
• Marketing has campaigns and propositions.
• Sales wants leads.
• Recruitment wants vacancies to be prominent.
• Individual departments have services they don’t want buried.
• Users have tasks they simply want to complete.

And of course, all of these are priorities.

A wireframe is the place where those competing demands have to become a hierarchy. Not because some parts of the organisation are more important than others, but because a visitor can’t absorb everything simultaneously. Someone arriving on a page needs a route through the information. That’s why one of the questions we continually ask during wireframing is deceptively simple:

• What does the visitor need to know at this point?

Not everything they might eventually need to know. Not everything the organisation would like to tell them. What do they need now, so that the next piece of information makes sense?

Order changes meaning

This is particularly important on a homepage. Take Panacea. Its software is modular, so we could have started by presenting all the individual products. But without context, that would have asked new visitors to understand the detail before they understood the overall proposition. We’d be asking them to see the trees, not the forest.

Instead, the homepage first establishes the bigger picture and then breaks it down into recognisable entry points. Later, evidence and testimonials appear before the main call to action. Again, that’s a strategic decision.

“Contact us” isn’t necessarily a convincing proposition five seconds after somebody lands on a website. The visitor may first need to understand what you do, recognise something relevant to them and see evidence that you can deliver it. The individual ingredients matter – but so does the order in which you serve them. I’m sure you can insert your own cooking metaphor here.

A wireframe lets us test that sequence while it is still cheap and easy to change. Moving a grey box takes seconds. Reconsidering the information architecture after pages have been designed, written and built is considerably more painful.

The wireframe asks awkward questions

Good wireframing isn’t about deciding whether an image sits on the left or the right – it’s about uncovering questions that need answers, without getting sidetracked by design or content.

• Do these two services actually make sense as separate things to a customer?
• Does the terminology used internally mean anything outside the organisation?
• If there are six potential audience groups, do they genuinely need six routes through the site?
• Is this page trying to answer too many different questions?
• Have we provided enough evidence to support this claim?
• Why is this call to action here?
• What happens if somebody isn’t ready to enquire?

These aren’t design questions in the narrow sense. They’re questions about the organisation, its audiences and the way the two connect. Sometimes a wireframe reveals that the problem we thought we were solving isn’t the real problem at all.

Good wireframes are built around people, not departments

This is also why website structure shouldn’t simply mirror organisational structure. Your users don’t necessarily know – or care – which team provides a particular service. They aren’t arriving with your organisational chart in their heads. Instead, they arrive with needs:

• “I need to understand whether this product will work for us.”
• “I need to find the right course.”
• “I need to know whether you can help with my problem.”
• “I need evidence before I recommend this company to my boss.”

The wireframing process is an opportunity to organise information around those needs rather than around internal ownership. That may sound obvious. In practice, it can mean making some quite difficult choices but that’s exactly why those choices belong here, before visual design gives an idea an air of permanence.

What should you look for in a wireframe?

If you’re planning a website redesign, don’t judge a wireframe by whether it looks sufficiently like a website. Instead, interrogate it.

• Try taking the logo away and ask whether a new visitor could tell what the organisation does.
• Look at the first few sections of an important page. Is there a clear progression, or simply a collection of content blocks?
• Ask what question each section answers.
• Look for moments where the site asks something of the user – contact us, book, buy, register, download – and ask whether you’ve given them enough reason to do it.
• Consider different visitors. Can each recognise where they should go without having to understand your internal language first?

And whenever someone suggests adding another block, button or message, ask the most useful wireframing question of all:

• What problem does this solve for the user?

If you can’t think of a good answer it probably doesn’t need to be there.

Grey boxes, expensive decisions

A wireframe is deliberately unfinished. That’s what makes it useful. It creates a space where assumptions can be challenged, priorities changed and journeys reorganised without anyone worrying about whether they’ve ruined a beautiful design.

By the time visual design begins, the website should already have a strong underlying logic. We should know what each page is trying to achieve. We should understand the questions it needs to answer. We should have decided which information deserves prominence and which can sit further into the journey. We should have a good idea of where we want the visitor to go next and why they might want to go there. The colours, typography, imagery and interaction that follow are hugely important. They’ll create personality, communicate the brand and make the experience engaging but they’re not there to rescue the structure. That’s why good websites often begin with something surprisingly unimpressive to look at.

A collection of grey boxes – and a great many decisions.