The relevance of wireframes

I know we’ve been through the mill with this one. Andy Rutledge really caused a stir with his article on the relevance of wireframing late last year, but I’m not going to pick apart any of Andy’s arguments. I simply want to talk about why I think wireframes are relevant, who should be responsible for producing them and why they can go wrong.

Why I believe wireframes are important

Wireframing is an essential stage in my workflow because it’s the last time I can consider content hierarchy without necessarily thinking about design. Having read the brief over and over, then noting each element to be present on each page in simple ordered lists (in order of importance), I begin placing the elements on pages, represented only by grey boxes and text. There is nothing visually emotive enough to cloud my thoughts, so I’m forced simply to think about the content and it’s hierarchy.

The purpose of design is to communicate. Here the content is the message to be communicated. Wireframing allows us to to be subjective about the vehicle for delivery of this message, and simply focus on the order of delivery.

Who should do the wireframes?

I’ve worked with wireframes done by other designers, creative directors, technical directors, even account directors, but never a dedicated information architect. I can only draw on my own experience, but I’d say if you don’t have an information architect on board, the designer should be wireframing.

If the technical or creative director has spent more time early on with the client, discussing the aims, purpose and relevance of the site, it can be hard to argue that a designer who has only just been briefed should be taking on such a strategic task. I really believe that everyone in a team (and this should be the whole company, especially if you’re a small-medium sized agency) should sit down at the beginning of every new project and be briefed on who the client is, what they wish to achieve and how we’re going to help them do it. I don’t care that you’ve got a deadline in the next hour — that’s bullshit. You can spare 10 or 15 minutes. If you are a small-medium sized agency, chances are that everyone will touch the project at some point. Give each person some context when dealing with it; the increased familiarity will only serve to increase ownership of the project and result in better work by everyone.

Designers make instinctive decisions when designing, and I know I make instinctive decisions when wireframing. Although you must be impartial enough to avoid making choices which will have an overt influence on the design, don’t ignore what you believe will be a good functional solution to a problem just out of principle. If I feel I’m consciously slipping into ‘design mode’ during wireframing, I stop and review what I’ve done as if I were going to be handing over the wireframes to a different designer. Whilst this is indeed sometimes the case, I nevertheless find it a useful exercise for myself. When you’re not consciously aware of this slip, things can go very wrong.

The pitfalls of wireframing

Wireframes fail when done without enough separation between defined hierarchy and presentation ‘style’, when the agreed rules are not followed, or when the handover to the designer is made poorly.

When I talk about presentation style, I mean the visual components. If the client is to see the wireframes (and this may not always be the case), you need to clearly define what wireframes are and what they’re not, along with what the visual components you’ve used actually represent. Balsamiq says “Look, I’m not a design!” by using Comic Sans. I employ only one weight of Helvetica and use boxes in a very limited number of shades. There is no right way or wrong way, just make sure the client understands your way.

I’ve seen it many times, I’ve fallen victim to it myself and it’s still the number one argument I come across when debating the relevance of wireframes: they can influence the design too much. Sometimes even with good IA → design handover, preventing the designer from taking too much of a cue from the wireframes can be difficult. Too closely following the wireframes can lead to a design which, at best, feels very functionally-driven, and at worst, is overly modular and compartmentalised, lacking any organic feel and natural rhythm. Preventing this outcome comes down to an understanding of each others roles and remits. An information architect should be aware of when they are likely to be influencing the design too much, just as the designer should know when not to take elements of the wireframes too literally and to use the creative mind they have. It also comes down to the personal relationships between the IA and design teams, part of the dynamic which exists throughout the company.

The rules

I have a few simple rules which I follow when wireframing:

Be strict with time. Set a sensible time limit within which to complete the wireframes. Don't give yourself time enough to begin over-analysing things, you'll only begin thinking about design.
Use no more than three shades. Whether wireframing on paper or on the computer, different shades of grey help to define the relative important of elements on the page. I usually opt for #ccc, #999 and #666 (set on a white background) and set all links with an underline.
Embrace your instincts. This is a huge advantage designers have over other possible candidates for wireframing. Whilst it's important to remain impartial about the design, don't ignore what you believe will be a good functional solution to a problem. Interpret patterns in the display of information and suggest suitable methods of display.
Use a grid. Although grids are specifically a graphic aid, I use one throughout wireframing to avoid having to think about things like the width of gutters and margins. If you're at all like me (obsessive compulsive), employing a grid during wireframing will help keep the pace of production up.
Get them in the browser. With the vast array of resources and tools now available, there is no excuse for not being able to export wireframes to a browser and let the client click through them. In my experience, allowing the client to 'walk' the paths through the site is invaluable when moving forward into the design stage.