Daniel Ritzenthaler

Wireframes — A Good Communication Tool, a Poor Design Tool

Wireframes have been a crucial part of almost 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 what it is that wireframes do. What wireframes are.

Let’s talk for a moment about what they’re not.

A Wireframe is Not a Design Tool

Where does design happen? Before a wireframe can be created, a group of people need to get together and talk things out. Later on, a wireframe might be created, by a single person working in isolation, 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 previously done design work.

A wireframe is good for gathering and consolidating the design thinking — the conversations and sketches — that have occurred. Wireframes are good at opening 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 provide this 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. Prototypes can be time consuming and costly. Wireframes serve as a bridge between raw ideas and costly prototypes. The space between idea and prototype can be an uncrossable chasm without a wireframe.

But watch out. It’s important to consider other reasons why there might be a chasm between your ideas and the commitment needed for a prototype. 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 on and 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.

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) Believable interfaces, and (2) Customers. Wireframes are too simple to be perceived as believable interfaces. And you’re unlikely at this stage of the project to be in direct contact with any customers, either. (You might need to remind your external stakeholders that they are rarely useful proxies for customers.) Even if you did have access to customers, presenting them with a wireframe is unlikely to provide you with meaningful 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 on the creation of wireframes might be worth examining more closely to see if you want to take them on. What about this project requires a wireframe? 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 distraction. 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?

No. You should do what you need to do to get the job done. It's 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 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 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.

Ignorance

The ideas in Ignorance by Stuart Firestein, surprisingly, reiterate s and clarify many principles of designing and building great web products. The ideas aligned well enough that I kept thinking I was reading a startup book. Now that I think of it, it’s one of the best startup books I’ve read in a long time.

Attention Spans, A Theory

Attention spans aren’t simply on or off. There are phases that you need to move through by earning your audience’s trust.