Before Facebook was open to the public; before smartphones had punctured the market; before the iPhone existed, I was stood in front of a CIO with a wireframe projected behind me. It was the first they had seen. Wireframes were useful then, because the world at the time didn’t understand interfaces — or reduced them to an afterthought. And there I was, armed with a cheap piece of analysis, showing how I could improve an application’s task performance using little more than black lines. They’ve been a shiny tool in my design arsenal for over a decade, but its sheen has worn off. Here I too want to convince you why this has happened.
When I started out thinking about experience design, wireframes were often a faster substitute for heavy handed design processes. Software then was more about organising information (pompously called the information architecture) into a user-centred reality. This is rarely the case now. We are in a continually connected, application driven world of push notifications, social everything with internet enabled refrigerators. And yet… wireframes in many of the companies I advise so often adopt the same role they always have done. Despite the adoption of iterative, reactive, and learning methodologies (I’m avoiding saying agile but it is what I mean), wireframes still often sit at the very beginning of processes. Appearing before a conversation has happened on strategy, the KPIs and the goals of a feature/product.
1. Wireframes are created too early in the process.
This eagerness adds an unnecessary burden to future innovation. It cements product ideas into a design before they’re developed. This an approach that is at conflict with a philosophy of rapid prototyping. Many clever teams will correctly use wireframes as a disposable document, but this is not their most common use. They come as their own phase of work, along with the taxing overhead of management sign-offs and obligatory review meetings. This is not something that should be encouraged.
Thinking in phases creates another interesting behaviour. Wireframes are often created before a team are assembled, and by almost anyone in business now. My issue isn’t that one of skill, although that can be a factor. It is that those completing the work aren’t involved in the ongoing process of building the product. This renders these artefacts somewhere between interesting, and useless. The zealousness to start with wireframes creates an boundary between those who created or signed-off the wireframe, and those tasked with implementing the ideas it contains. This boundary is antithetical to good teamwork.
2. Wireframes tend to be lobbed over the fence.
Those that vehemently calling for wireframes tend to be the least collaborative. These documents have snuck in to replace the specifications we were so attached to in a pre-agile world. Recently an associate told me that an interface doesn’t resemble wireframes created six months previously. Think about the implications of this: a document lived longer within their memory than did the cumulative, incremental, decisions a highly skilled team had taken in front of them.
The best time to take a design decision is the latest time possible. This is a basic principle of strategy and, in software, Agile. Wireframes, specifications, and even very deep product backlogs prevent delaying decisions to the correct, responsible moment. A moment when when you have maximum information to that that decision. Guaranteeing an idea upfront contradicts the Agile Manifesto’s most difficult value of “Customer collaboration over contract negotiation”. I hold that this is the most important one to impart to those I work with. I prefer feedback and reflection over guesswork about decisions I only need to take months in the future.
Anything that frustrates a team’s ability to collaborate or collectively take responsibility for a product should be removed from the tool-kit. Anything that persists long after its usefulness should be treated with suspicion. Wireframe’s longevity is difficult to understand. This comes from another misconception. The belief that wireframes can completely describe an application.
3. Wireframes instil a false sense of completeness.
This perception surprises me. And its hard to get people to break it. You have the wires… no further input required! Just let the designers colour it in, and let the software people type stuff into the code! Wireframes often look done, but they cannot reflect every state of the system or the users behaviour. Most engineers and designers know this, and know wireframes are open to interpretation — but clients, and their managers do not. There are sensible arguments that can help break this misconception. For example, wireframes cannot show dynamic on-page interactions. Still, I discourage this line of debate as it tends to be met with a view that more wireframing is required. “Just add the missing stuff to hit 100%, total, utter, final, completeness. Then we can move on!” Welcome to the UX designer’s requirements death spiral.
Something more subtle is happening here. A lot of work happens in business that isn’t required. Wireframes’ accessibility means people just jump into their favourite tool and start drawing boxes. The output looks technical enough to convince those around them that good work has very much indeed happened. So everyone is happy and goes home knowing they earned their salaries.
Software is littered with this type of behaviour and these types of artefacts. Architecture diagrams, wireframes, product backlogs and roadmaps are all created and printed and reprinted and versioned and emailed and debated. Our only goal must be building something that creates measurable results. None of these tools do that. They are only a necessary evil.
It is not the scope of this article to discuss the deep existential reassurance being busy gives people. But the fallacy of busy-ness over productivity should be challenged by any leader. It is an epidemic in business, and a preference for lengthy documentation over doing, like any nonessential work for that matter, erodes value.
4. Wireframes are a sunk cost.
Creating detailed, annotated wireframes costs money. Its a costly, upfront investment that isn’t evaluated in terms of the return it provides to a project, product or organisation. I am surprised when people think that asking for this evaluation is somehow controversial. That skipping the wireframe stage, like any other tool or process step, is somehow negligent.
Organisations tend to design themselves around tooling. The rise of the wireframe-creating-department and the Wireframe Director is an obvious extension of how companies organise by function. Once created, a department’s director will eventually sanction that their division’s input is required on all items produced by the organisation. Therefore suggesting that wireframes may be unnecessary isn’t a very sensible cost-benefit debate, but an attack at the manager’s or division’s raison d’être. That may sound dramatic, but at its heart, the surprise I’m met with is a result of this counterproductive element of organisational design.
Prototype, don’t wireframe.
I love wireframes as a thinking tool, as something I can use to draw an idea out of my head and throw away when its no longer useful. I love badly drawn sketches on a pad of large (A3) paper, sticking on interactions with glue and tape. The size has an advantage too. They’re too unwieldy to feel correct, or to be passed around in a PDF to a committee of bill payers. You can help people to play with the design too. ‘Here, you take the pen and draw what you mean’.
But for me, wireframing isn’t right, and I believe its bad for businesses. It’s long outlived its usefulness. There are better ways to build products that don’t involve drawing boxes on paper. There are more collaborative ways of working in a team than defining a role whose purpose is drawing boxes on paper. There are more interactive ways of representing an idea. And that these ways lend themselves to being done throughout the lifecycle of the project.
But, I hear your voice cry, wireframes can do this too. People are just misusing them. You are not wrong. They can, and people are. Too often tools become burdened with inappropriate use.
There’s a way out though. I could teach businesses the virtues of collaboration in a design process and that a wireframe is not a contract of work. We could have discussions on the tolerance of what they represent and think through where an organisational design might not be conducive to good product design. We could point to the research that shows sign-offs are an anathema to good collaboration. And probably much more.
This is a lot of work. You can do it if you want. I’m taking the easy path: throwing the tool out of my toolkit.