Wireframes are simply facilitators for discussion

The title of this article should really be: IA documentation is simply a facilitator for discussions. And the key point is this: in a web project we’re all (as a team) trying to develop a set of complex shared understandings about what this product will be and how it will work. As long as the IA documentation helps us do this in the most effective way, that is all that matters.

I was just reading a couple of blogs by Cennydd Bowles and Lee McIvor on the fact that IAs and UEs need to be multidisciplinary in their skills set - which I certainly agree with. They were also discussing the variety of ways we can document our IA or UX planning - with interactive prototypes, or hand-drawn sketches, for example.

We’re all trying to develop a set of shared understandings about what this product will be and how it will work

In my old job I was repeatedly asked for ‘wireframes, wireframes, wireframes’ - I almost felt like a wireframe monkey. Whereas for me IA is about coming up with some ideas for a web or digital project, and then communicating and refining them as effectively as possible within the team.

Sometimes IA documentation will take the form of bullet points, hand-drawn sketches, paragraphs of text, high-res visuals, or conventional wireframes. I have even used small squares of paper and blu-tack in my time to brainstorm ideas.

I have no problem with people creating interactive demos, and will probably move that way in the future, but I can work incredibly fast in Visio and often find flat diagrams with annotations communicate ideas really well. Whatever’s best in terms of efficiency of time and effectiveness of communication is best I guess.

Use your IA documentation as a facilitator for discussion rather than some kind of autocratic dictat handed down from an ivory tower

I also think it’s incredibly important to work with the team throughout the process - and use your IA documentation as a facilitator for discussion rather than some kind of autocratic dictat handed down from an ivory tower or set-in-stone proposal. Technology and art direction are vital to the success of a web project, and deeply affect the ultimate user experience. Therefore they must be taken into account at the planning stage.

At the end of the day some people in the team know more about certain areas of the project than you - that’s what they’re there for. Taking their views into account and reflecting them in the product is important - just keep the user front-and-centre.

So the key thing is to build as much of a shared understanding as possible, through whatever means necessary. Where projects go wrong in my experience is where a certain amount has been ‘assumed’ or there is a breakdown in understanding. ‘But I thought it was going to work like this’ - ‘no it was always going to work like it does’ can be minimised through detailed planning and many iterations of documentation.