Wireframes: A Good Communication Tool, a Poor Design Tool
Wireframes have been a crucial part of just about every project I’ve worked on. I’ve spent countless hours explaining to clients the central importance of wireframes as a tool for good design.
I’ve come to realize that I was wrong.
Not about the value of wireframes. But about exactly what it is that wireframes do. What exactly wireframes are.
Let’s talk for a moment about what they’re not.
Wireframes are not a design tool
Where does design happen? Before a wireframe can be created, a group of people needs to get together and talk things out. Later on, a wireframe might be created, usually by a single person working in isolation, sometimes long after the initial conversation has occurred. The sketches have been sketched, the ideas have been brainstormed. A wireframe is there to formalize and make concrete what’s been decided as a group. The design work was done verbally, in notepads, and on whiteboards. The wireframe is the document that captures that design work.
A wireframe is good for gathering and consolidating the design thinking — the conversations and sketches — that has already occurred. Wireframes are good at opening up avenues of communication and spurring useful feedback. They can help you obtain someone's approval, or move a project on to its next phase. Emails, contracts, and specifications also provide this kind of value. I like to call it “paperwork.”
A bridge between idea and prototype
Sketches and conversations can be difficult if not impossible to convey to the people who weren’t around for them. Mock-ups and prototypes can be too time consuming and costly to throw away if they're not good enough. Wireframes serve as a bridge between raw ideas and costly prototypes. The space between idea and prototype can, in fact, be an uncrossable chasm without a wireframe.
But watch out. It’s important to consider other reasons why there might be such a chasm between your ideas and the commitment needed for a prototypes. You might be dealing with a lack of trust, a deficit of courage among leaders, decision makers who won’t talk to you, resources that are too limited to allow for mistakes, and so on. These issues won’t disappear on their own, no matter how good your wireframe is. They need to be identified for what they are and tackled on their own terms, with tools that are specific to each problem.
Wireframes are not a panacea.
So what are they?
A poor design tool
Let’s be honest: wireframes are a lousy design tool. To get the most accurate understanding of how a customer will interact with an interface you need two things: (1) Believably real interfaces, and (2) Customers. Wireframes are usually too simple to be percieved as believable interfaces. And you’re unlikely at this stage of the project to be in direct contact with any real customers, either. (You might need to remind your external stakeholders that they are rarely useful proxies for actual customers.) Even if you did have access to real customers, presenting them with a wireframe is unlikely to provide you with any real insight or valuable feedback. If you’re using wireframes as a research and feedback mechanism, everything you learn should be treated with extreme caution and skepticism.
A mediocre diagnostic tool
Projects that depend too heavily on the creation of wireframes might be worth examining more closely to see if you really want to take them on. What about this project really requires wireframing? Usually, you’ll find that it’s the people involved that require the communication and consensus implied by a wireframe, not the project itself.
That’s fine; it’s okay to define a project early on by its need for extra communication, continual consensus, and iterative collaboration. But be sure that these are the deliverables you focus on, not the wireframe itself. The wireframe is a red herring. It’s the reason for the wireframe that’s important.
A good communication tool
In short, wireframes are a great communication tool. They do a spectacular job of communicating the ideas of the group at various stages of the design process and help facilitate the conversations and feedback that are required to move the project to its next phase.
What they don’t do is help designers design. That work gets done elsewhere, using different tools. Then the design work that’s been done gets pulled together into a temporary piece of paperwork called a wireframe, and another phase of the process begins.
Should we stop using wireframes?
Of course not. You should do whatever you need to do to get the job done. It's just important to know that wireframes may not be the design tool you thought they were. It’s important to know the kinds of things that wireframes are often a stand-in for. What they’re sometimes used to obscure, or paper over. To know that an excessive reliance on them can sometimes signal a lack of team dynamics, resources, or support. To use them as a tool that can help move your project along, but at the same time realize that design is getting done precisely when you are not creating a wireframe. If you want to be doing design work, spend less time on paperwork and more time thinking, talking, and drawing.
