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.
|Dan Brown has been practicing information architecture and user experience design since 1994. Through his work, he has improved enterprise communications for Fortune 500 clients, including US Airways, Fannie Mae, First USA, British Telecom, Special Olympics, AOL, and the World Bank. Dan has taught classes at Duke, Georgetown, and American Universities and has written articles for the CHI Bulletin and Interactive Television Today.
I’ve been working in IA / Interaction design for more than 10 years and the strangest thing is that the more experienced I get, the more I’m convinced any idiot can do this work. This depressed me for quite some time; why am I doing this work and how long before they find out I’m not that good? But now I discovered that most of the choices we make that are blatantly obvious to us (e.g. to not create one pulldown with all the dates going back to last year, but to create a day, month and year pulldown to work together, smart eh?) are really not that obvious to others. They really need experts like us who work with their common sense all day (and all weekend, and all night) to point out the obvious. so now I’m not that depressed anymore, and would be even happy if someone would reinvent Visio to make it userfiendly! 😉
(sorry for spellingmistakes, I’m Dutch… )
Actually we named it for a deliverable that applies to any aspect of structural (planning) design. Not just IA, which I think “Taxonomy Today” would be… boxes and arrows come into play in IA, interaction design and even strategic visualizations (good article on that in this month’s HBR, btw.”Charting Your Company’s Future ” http://www.hbr.com)
But that’s just semantics. I look forward to seeing what you gots to say about the pictures we draw….
I liked this quotation:
“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.”
I liked it, but I don’t really believe it. Though it gave me warm fuzzies, on reflection my dark mood returned. Having been both a tech writer and user experience doodah for 11 years or so, I’ve seen companies and clients create ever-complex systems while they reduce (yes, reduce) their staffs in documentation, user assistance, and product/project design. Sadly, I envision IA following so many other disciplines into exile in the Land of Broken Toys…or Dreams…or User Experiences.
Still, I very much enjoyed your take on the situation. Let’s light a positive voice like yours rather than railing against the darkness, like mine.
Chin up, Joe! Yes, things can look grim — it is only a *glimmer* of hope after all — but keep in mind the landscape is changing. Although user experience disciplines, like the ones you mention, have been around for years it is only more recently the the diluge of information is hitting users. While it was easy to sweep those disciplines under the bottom line, so to speak, the glimmer of hope suggests that with more complex information needs, users will become pickier…
Today, I spoke with some people from a large network appliance company who said they are using “knowledge managers” (I would call them enterprise information architects) to help coordinate the production and dissemination of information digitally. If that’s not hope, I don’t know what is!
I hate to pull a small part of a quotation out of context and run with it, but “Good information architects do not have to be good designers…”? That half sentence reeks of incongruity so badly that it was difficult to pay attention to the rest of your article. What are IAs doing, if not designing?
Knowing you, Dan, I think your point is probably that one needn’t be extremely skillful at GRAPHIC DESIGN in order to practice information architecture well. If so, fine, agreed. But I’ll again assert that IA is a design profession inasmuch as it is concerned with the conceiving, envisioning, and planning of a desired goal, with a particular set of constraints as considerations. To think of IA as separate and distinct from design is, in my opinion, a dangerous mistake that sacrifices much useful history, knowledge, and experience from which practioners of IA might be informed and improved.
John, indeed you are correct. By “designer” in that context, I was referring to the specific field of graphic design. I should also have been clearer in my second paragraph: the process of documenting information architecture is creative, as is information architecture itself.
Great, well written article Dan.
I also feel that we should think of IA and UX as fields that will grow and evolve rather than die out.
I posted some thoughts on this to my site a while back. Here an excerpt:
“IA projects in the future will continue to get more complex, and integrating multiple sites, content, and workflow-intensive applications will require an experienced information architect with real training.
“In the end, big, critical and risk-intensive projects will involve usability professionals and information architects with significant training and experience. Less experienced practitioners — usually trying to play many roles — will take care of the smaller, simpler efforts. We shouldn’t worry about this.”
My whole post: Practicing Usability in the future
Thanks for the positive viewpoint — I’m looking forward to the next installment!
Comments are closed.