Defining information architecture
What is information architecture, and how does it exist beyond an “IA guy”?
This seemingly simple question was posed to me in June by Charles Hamilton, chair of the World Wide Web Artists’ Consortium (WWWAC ) Development SIG. Hamilton was putting together a panel on IA and had invited me to participate.
The invitation was deceptively simple: “We will be looking at ‘nuts-and-bolts’ aspects of particular business cases,” read the email, “where information architecture plays a crucial role in complex online products.” That certainly covered my employer’s Web site, but I didn’t fancy myself an information architect.
Hamilton took another view. While my office does not have a designated information architect on staff, information architecture itself takes place in numerous ways across a variety of departments. While I spend my time thinking about usability, design, and markup, the decisions I make directly influence the information architecture of the sites I create, and vice versa.
I always assumed that IA dealt, on its simplest level, with the organizational flow of data. But as a subject, I define IA as encompassing so much more. Information architecture is a new term for an obvious and necessary aspect of Web site development. Its importance lies not only in stressing the need for good IA but in getting the members of a staff to realize the role IA plays in each of their jobs.
Where the Roles Are
Behind the scenes, developers–programmers, database administrators, and technical staff-have an obvious need for IA. With parameters set by the information architect’s deliverables, development can flow more easily than ill-defined tasks. Developers also do plenty of IA of their own, making determinations in database structure and retrieval methods that affect the final presentation and utility of data.
For designers, IA dictates what goes where. Sometimes a designer will be handed a set of requirements to follow; other times, the designer will have to clarify flow and format. All the decisions that are made-from the placement of links and text to the progression from page to page-encompass IA to some degree.
A solid editorial team needs information architecture to know how to arrange information for later retrieval by the site visitor. Both content-rich and commerce-based sites benefit from the definition of solid structural basics that define how items are written and filed. Those same basics, determined in conjunction with the development staff, places each piece of copy in a context richer than its basic existence. As an example, this individual column falls within the regular column Wide Open, as well as within the Columns area of Digital Web. These distinctions also spill into design. By knowing which items go on which pages, and where on those pages items should go, editors can write pieces that make sense relative to their destinations.
What I find interesting is that a sales staff can benefit by knowledge of IA as well. A salesperson with knowledge of a site’s hierarchy can pitch ad campaigns based on complementary areas of the site; marketing staff can find ways to simplify processes and promote useful systems. By understanding how a site is assembled, the sales team, which is responsible for championing the benefits of the site, can find new and unique ways to promote it.
The night of the WWWAC panel, I started the evening by telling the audience that I was not an IA, and that my site did not employ one. Rather, the entire team, even without defining itself as such, must work as site architects as well as focusing on their own specialties. Working as a department we achieve many important and interesting IA goals.
Rob Larson, the information architect for New York Times Digital, also sat on the panel. His mission was far more focused: He had to make sense of vast amounts of data, dissecting and organizing information into forms that could be accessed by the Times’ audience. The complex system used by Times Digital was a result of his hands-on work.
The key in addressing such complexities lies not just in hiring an IA, or using the buzzwords and jargon associated with the field, but also in getting a team to understand the importance of structure.
When a sales team asks how to implement a new sponsorship concept, they need to understand the intended flow of traffic from and to the sponsored areas. When the editorial director wants to add a new text component, the editor can assist in conceptualizing its realm in the main database, and defining its relationships to the literal page on which it will be read. Designers have the need to take page-by-page process into account when creating their wireframes, and developers should think beyond their task lists to visualize the system as a complete, smoothly operating whole.
Remember that IA, for all its worthiness, still has the feel of a new-economy buzzword. Grab hold of its basic tenets and make those into concepts that feel sensible and worthwhile to people other than the actual staff IA. Just as he or she must think about technology and design, so should everyone pay attention to the tenets of information architecture.