Boxes And Arrows : The Design Behind the Design

Opening Pandora's Box: Special Deliverable #1

by Dan Brown on 2002/06/03 | [8 Comments]

Boxes. Arrows. Of all the things to identify with information architecture, this magazine chose to take its title from two shapes; shapes that are fundamental artifacts in our documentation. You could just as easily be reading

The best part of my job as an information architect is preparing deliverables. While fraught with frustrations —endless details, typos, inconsistencies —the process of documenting a system’s functionality or information structure is creative. It is creative in that we are at once designing the system and designing the documentation to represent that system.

The parallel processes of creation and documentation feed off each other. Through the documentation, we come to a better understanding of our own conception of the system. As we develop a clearer vision of the system through the documentation, we find ways to improve the system.

Good information architects do not have to be good designers, but they must be able to explain their ideas well. If your organization is anything like mine, information architecture is the first foray into the design process, the first time the client sees a solution to the problem. Requirements, objectives and even user models simply state the problem, providing a context for the solution. It is the information architect that puts a stake in the ground: the finished product will look like this!

Our deliverables, therefore, become high profile. Clients, who until this point perceived requirements gathering as merely regurgitation of what they told you, are eager to sink their teeth into something fresh. Developers are eager to start thinking about the system architecture and technical engine. Designers are some combination of eager and suspicious, depending on your organization.

All the hoopla around our deliverables can be concerning, if not downright scary. Thus, this particular box —that of Pandora —is opened. What flies out might be frightening:

Scary thought #1: Information architecture is defined by its deliverables.
There are days when I wonder if I will be making site maps, or documenting taxonomies, or arguing over wireframes for the rest of my life. There are days when I wonder if all I’m good for is making pretty diagrams. I worry that if you take away the site maps and wireframes, that there isn’t much to an information architect. Which brings us to scary thought number two.

Scary thought #2: 20% of a deliverable provides 80% of its value.
Are there particular parts of your document that get the most attention? The 80-20 rule might well apply to deliverables, where 80% of your effort goes into producing something that’s only 20% valuable. Have you ever had the experience where clients or team members virtually ignore your documentation, especially after you’ve worked really hard on it? Or maybe you’ve had clients ask you, “I paid you how much for this?” No doubt every information architect has wondered whether there is value to his or her work, especially if the bulk of the work is captured in physical deliverables.

Scary thought #3: Information architecture is a lonely occupation.
Many information architects are alone in their organizations. All but addicted to SIGIA-L for a little companionship, they mostly toil without an ally, a mentor or a collaborator. People from other disciplines provide occasional useful banter, but these information architects are starved for shoptalk. Information architecture can feel a bit like baking someone else’s cookies, churning out the same shapes every day without an opportunity to branch out.

Despite these and the other demons haunting the practice of information architecture, this particular box holds hope.

Glimmer of hope: Information systems will quickly grow more complex, and continue on that trend.

As audiences face increasingly difficult information landscapes, our outputs will become more valued, our role will become clearer and our community will grow. A world rich with information demands concise documentation. Without it, the value of the information itself diminishes. With companies spending more money on information and knowledge, they will expect the systems built around them to be useful and efficient. The role of the information architect becomes abundantly clear in this type of environment.

But for now, we are on the forefront, perhaps the pre-Golden Age of Information Architecture. And we have a lot of work ahead of us. Through this column, Boxes and Arrows will seek to elaborate on the preparation of deliverables, a crucial component in the maturation of our field. As we explore, we will no doubt encounter more scary thoughts, as well as more glimmers of hope.

In the next installment of Special Deliverables, Dan Brown reviews the concepts of Coherence, Context, and Relevance and why they matter in IA documentation.