Author Archive

I have a love hate relationship with wireframes. In the last 10 years they’ve been a part of every web project I’ve worked on. There have been times when I can’t imagine how we would have solved a particular problem without them. Yet there are also times when I’ve been completely exasperated at the amount of time and energy they’ve consumed, seemingly to very little reward.

This frustration has forced me to change the way that I approach wireframes. And as my approach has changed, I’ve been able to extract more and more value from black key lines and grey boxes…

From functional to visual

10 years ago the first wireframes I used were about as functional as you can get – a long list of page elements: static text, dynamic text, input text, radio button and so on. They were universally awful. About the only concession to help people understand how the page worked was to group common functionality into individual tables.

The wireframes were functional rather than visual as they were used to describe how the page should be built. Certainly, when you consider the screen from a developer’s perspective a list of different functional elements is probably quite logical.

However, from a user experience point of view this was a killer. Functional wireframes are incredibly difficult to read – the method of presentation gets in the way of being able to translate the information into a real screen, especially at the review stage.

Looking at this image it seems obvious that wireframes should be visual, however, IA was in it’s infancy ten years ago. Everything was new.

Wireframes also took a long time to produce. Changes to one wireframe often meant updating countless others. Change to the global nav? Certainly. Just one moment whilst I update 120 wireframes with that one.

Understandably, this hampered attempts to create wireframes that more closely represented real life screens. To help get around this, when they did become visual, they also become modular.

The modular approach to wireframes also reflects the reality of building sites. Functionality and snippets of code are built once and then reused over and over again. So why not create wireframes in the same way?

Visual wireframes also started to break down a belief that information architecture can be considered in isolation to information design. The information is the interface. How can the two possibly be separated? Join them together and you start creating wireframes that can be read and understood by everyone on the team, including the client.

Of course, this can raise the problem of clients expecting the final screens to be identical to the visual wireframes. “In the wireframes the submit button is on the right of the drop down, but in the designs it’s below. Why?” This requires careful client management, but it can be largely avoided if the wireframes concentrate on getting the ideas and thinking across, rather than just laying out a page.

Once wireframes are created using information design as a technique rather than just a visual conceit, they can be used to explain how a site will be experienced by the end user. In the example above the different colours represent different areas of content, targeted at different types of users. The client and the team can then get inside the screen and understand how it works and what the priorities are. It’s a very different world from 1999 – a list of functional elements that only be read by the one person – the author of the original wireframe.

As wireframes have evolved, the methods behind creating them have changed too.

Fail fast

Several years ago I can remember working on projects where the wireframes felt as if there were merely a documentation or cataloguing tool. The object was to create as many wireframes as possible, of every screen in the entire site, in big, monolithic and hugely detailed chunks. Rather than exploring different approaches to the information and structure of the site, the emphasis became entirely focused on using all of the time available to build a collection of wireframes, regardless of whether they were the right wireframes.

At Made by Many we practice a very iterative and rapid approach to wireframes. We create the smallest number of wireframes to explore a concept before stopping and reviewing. Does the idea hold up? If so, add on another layer of information and see whether it still stands. If it doesn’t, change direction and explore another route.

As we start off by only doing enough to prove the idea (and no more), the cost of change is so small that you can very easily change direction without having lost time or money. Ideas are allowed to grow or fail fast.

Explore interactions, don’t just specify software

For many years the primary role of wireframes was to specify software. We now use wireframes to investigate and explore how people will interact with a site. Using a ‘just enough’ approach, we often create a series of simple interactive prototypes to try out a variety of approaches to solving a problem. These prototypes can be made in HTML or they can be as simple as a series of Keynote slide for someone to click through.

This is a very different approach to wireframing. Rather than simply documenting where a link goes, the goal is to model and start experiencing what moving around a site feels like as quickly as possible. The prototype can then be tested and the results used to iteratively improve the end solution.

Of course, sites still need to be specified, but wireframes aren’t always the right tool for doing this.

Nobody likes reading wireframes

No matter how much love and attention is poured into a wireframe, they’re cast aside as soon the screens have been designed. Nobody likes reading wireframes, especially when there’s a picture available.

I’ve yet to meet a developer who would choose to build a screen from a wireframe over a Photoshop document, regardless of how many helpful and important details the wireframes may contain. Realizing this is human nature, we now annotating our PSDs rather than wireframes. Why hold the information in a document that’s no one wants to read?

The best before date keeps getting shorter

For a long time wireframes were seen as one a project’s major deliverables. The client was paying for them as part of an agency’s ‘set piece’ best practice. Because of this they were constantly updated throughout the life span of a project, regardless of whether they actually needed to be. I’ve seen perverse instances where a set of wireframes have been updated after the site has been designed, merely to ensure that the wireframes match the finished site. Why update a document that’s never going to be used again?

As more projects are developed using agile methodologies, where the working software is the spec rather than a set of documents, the useful working life of a wireframe is getting shorter and shorter.

The right approach

In a previous life at a big ‘old style’ new media agency, there often seemed to be a one tool fits all approach to projects. This applied to information architecture too – there was a set way of creating and delivering wireframes, regardless of the individual needs of the client.

In contrast, we’re now lucky to have a wide range of tools and techniques that allow us to approach a problem from the best angle. A sketch, a grey wireframe or a full on keynote prototype. These tools allow us to develop a solution in iterations, slowly adding on more detail as the solution becomes closer to a design that can be built.

Whilst there’s a natural progression from sketch to a detailed wireframe, it’s important to never feel constrained by the life cycle of a project. A sketch can be done at any time (and by anyone), regardless of where you are in the process.

Wireframes aren’t the keystone

In the same way that the guild of stonemasons kept the secret of building arches to themselves, wireframes shouldn’t be the preserve of a select group of information architects. As wireframes have become more visual (and more useful) the number of people able to contribute to their development has increased. This isn’t just a list of designers and developers, it’s also clients and business analysts who are becoming more and more involved with the process.

We often involve all of these people in collaborative sessions around a whiteboard to gradually ‘build’ the interface of a site. It’s a different way of working that involves people in a very different way to help create a better service. It’s also a way of working that’s slowly demystifying information architecture, changing the way that we interact with it and, ultimately, who creates it.

The designer as information architect

As wireframes have developed the role and skill set of information architects have developed too. The most effective wireframes are now created by people who can see how a site fits together as a series of connected interactions. Who see the information as the interface, and understand that these two can’t be separated but yet can be affected by time and place.

The more that I appreciate these skills, the more that I believe that wireframes can (and should) be created by designers.

The best sites are those where there’s a seamless divide between the look, the content and the experience. Being able to model an interaction and understand how someone moves through a site are crucial skills in this trilogy. It’s time designers stepped up to the plate and claimed wireframes as their own.

54 Comments