If you need to create or redesign your website, and you get proposals from different vendor partners, you may see a line item for “wireframes” — but that line item may not get much explanation (if any), and if you don’t know what wireframes are, that line item may be baffling. All you know is that this is something that costs money in the project. So what are you getting?
What a Wireframe Is
A wireframe is meant to be a blueprint for your website or mobile application — which means it’s just as crucial and just as un-exciting as that sounds. The analogy to building a house comes up over and over again for a reason — just as you wouldn’t build a house without a blueprint, you wouldn’t want to build a website or a mobile application without one either.
A wireframe will show you, in the plainest terms possible, how your website is meant to work:
- How are the pieces of the page laying out in relation to each other?
- What’s the hierarchy of elements on the page?
- How will those pieces interact?
A wireframe is really the first point in the project where everyone will start to see the functions and usability of your new website coming to life — and with so little committed, it’s very easy to make big revisions at this point if you need to do so.
And make no mistake, revisions will happen. You will either discover that you’ve all missed some crucial functionality that needs to be thought through, or now that you’re seeing all your requirements come to life, you realize it isn’t what you really wanted after all. That’s to be expected, and that’s why we build wireframe revisions into our project process — it’s very easy to change directions at this stage.
If you don’t have any major revisions or you’ve reached the final revisions of your wireframe? Well now you have a visual map or template for moving forward. A visual representation of a page is worth 1000 words of narrative that tries to explain what the page should be doing.
What a Wireframe Isn’t
Part of the frustration that people can have with wireframes when they’re seeing them for the first time is that they are not visually exciting — but that’s quite deliberate. There are usually no compelling visual elements to look at — no colors, no fonts, no graphics. In other words, nothing that could distract you from focusing on how the website is supposed to work. So whereas there will be blocks and placeholders for images and videos, you won’t see any of those actual elements on a wireframe — you’ll just know that there’s a place for them.
How Many Wireframes Does It Take…
So, you’re convinced: wireframes are a good idea. But how many do you need? Well, that depends. Often it depends on the sheer size of the site or application, but really it depends on how many distinctly different functions or interactions you need to accommodate. If the goal of the wireframes is to provide a blueprint for how the site should be built, then you’ll probably need a wireframe for each of those unique instances.
In a simple example, let’s say that you have a site that’s just blog postings. You’d probably want wireframes for the following:
- The home page: what do you want to feature? Is it mostly text? Mostly images? Where will the navigation be and how will it work?
- A blog listing page: is it listed by category? By year? Is it just the title, or is there teaser content?
- A detail page: where do images or videos go in relation to the text?
These are all quite different functionally, and you’ll want to see how these layouts relate to each other. But let’s say you wanted a blog listing page by category — you probably don’t need a separate wireframe for that (unless you want to be particularly thorough), because it’s going to be so similar to the main blog listing page you already have a wireframe for.
It’s likely that as part of the earlier stages of the project you’ll be working together to figure out exactly how many wireframes make sense for your particular circumstance.
When Does a Wireframe Happen?
When in the project cycle does a wireframe come into play? Like the perfect porridge, it needs to happen at just the right time:
- You’ve already completed the Discovery phase (stakeholder meetings, benchmark analysis, content analysis, feature requirements, sitemap — we’ll talk about all of these at a later time);
- You know — at least roughly — how many different functions you’ll need (see above);
- But you definitely haven’t started on any of the visual design work.
And why is that? Well, you need to have enough information to fully understand how you want your website or application to work, but you don’t want to have gone too far down the road so that making any significant revisions becomes painful and costly. If you’ve started on the graphic design (or heaven forbid, actual development), you’re probably going to be throwing away a lot more work and money than you would have if you changed course during the wireframe stage.
Who Is Part of the Wireframe Process?
So finally, who needs to be part of this fun? Well, everyone, really. From the client side, all your major stakeholders need to be involved in reviewing the wireframes, since you’re the ones finalizing how you want your website to function. The designers and developers need to be involved as well, since they need to understand the direction of the final site, and they can verify that what’s being laid out at a high level can be done as expected (and within budget).
For Example:
At their most basic, wireframes mitigate your project risk and guarantee that your entire project team is ready to build the website of your dreams as efficiently as possible.
Kelly Tetterton is a Partner at Clarity, where she oversees the entire web experience practice. In this article, she explains what a wireframe is, the when and who of how it relates to a website project, and why you should always include this as part of your approach.