It begins with the brief. The brief defines the project objectives, informed by business goals, tactics, requirements and restrictions. It should broadly outline the content required to achieve these objectives, be it information about the products your client sells; company background information; latest news. Whatever. Brainstorm with your client, conduct user research and study competing sites to guide discussion as to what content is required. If it’s a redesign, you might have rich analytics data to accompany all of their existing content. The brief is signed off before any IA or design work begins.

IA (Information Architecture, if you’re not into the whole brevity thing) isn’t simply about site structure. IA covers user research: user needs, aims, behaviour and knowledge. It allows you to look at content you have, content you need, how to plan for it and how to group it. It should explore and define required content in detail. Format, length, intended audience and relevance to any specific tasks. Is it structured content, like a product page, or unstructured content, like a once-occurring ‘About us’ page? IA is not just a sitemap.

Once you’ve communicated the IA to your client, content authoring can begin. Fail to communicate the IA properly and you can kiss your deadline goodbye. The client must understand what they’re expected to produce. I can’t stress this enough: make sure your client grasps fully the breadth, detail and purpose of the content they are expected to produce.

Your IA work should’ve given you enough of an idea about the content to begin designing the framework for it. With the IA signed off, your design work and your client’s content authoring begin — in tandem.

Don’t leave your client out in the cold. They need reassurance that the content they’re authoring is good, just as you need to know it’ll work harmoniously with the design. Communicate constantly. Writeboards or Google Docs are handy for this kind of collaboration. Provide feedback and incorporate the latest content into your designs. There should be a continual conversation between the developing design and the developing content.

As your client edits and refines, so you design and build. More time spent editing and refining means a better end result. No last minute content dump into the CMS. No long, drawn-out ‘content population’ process, delaying launch. No need to look on in terror as your templates implode with all the extra content they didn’t tell you about. Donna Spencer says it best:

“Content shouldn’t be treated as an afterthought, or something to be “poured” into the website. Content is the website“

I’m only scratching the surface of a workflow here. If you’re really interested in producing better web content, I’d highly recommend Kristina Halvorson’s ‘Content Strategy for the Web‘ and Donna Spencer’s ‘A Practical Guide to Information Architecture‘.

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.