Main Themes from the 2003 IA Summit

Main Themes from the 2003 IA Summit

Got something to say?

Share your comments on this topic with other web professionals

In: Columns > IAnything Goes

By Jeff Lash

Published on April 17, 2003

At the 2003 annual Information Architecture Summit, information architects and related practitioners and educators from around the world converged on Portland, Oregon, for over two days of knowledge sharing and discussion. Rather than a full report on all of the sessions (which is available at Boxes and Arrows; see resources below), here is a discussion of several important themes and issues that were raised. Many of these points were not explicitly expressed by presenters but came up in after-hours discussions and conversations. This is not intended to be an exhaustive list of all topics of conversation, merely a peek into some important topics of discussion for those who did not attend.

Design for maintainability

Stuart Brand, whose book How Buildings Learn: What Happens After They’re Built is a common listing on Web-related reading lists, delivered the keynote, which focused on maintainability and sustainability. Though Brand’s experience is mainly with physical architecture, his works show many analogies for Web sites and computer systems.

Information architecture is usually focused on getting a system to development or launch, but Web sites, like buildings, need to be maintained, and will change over time. The design of a successful information architecture must allow for more than just scalability, it must also assume that change is inevitable and anticipate future changes before launch. Planning and forecasting can help develop scenarios, features, and designs that will ensure that a site can be maintained and will hold up over time.

It is all too common to “design for the deliverable,” meaning to produce something that is attractive and beneficial for design but rather useless after launch. Information architecture needs to design for continual design by not focusing on the deliverable or launched site as the end of the line. Deliverables can be used to document the design and functionality of a system, so that they may be used for maintenance and expansion. Deliverables should be a means to the end during initial design, but can be invaluable as blueprints for future enhancements.

In the early days of the Web, a site was built and not touched until it came to redesign a year or two later, but now, more sites are designed and maintained by internal groups, with a staff dedicated to upkeep and expansion. Deliverables and documentation created pre-launch, whether in-house or by an outside firm, should be able to assist in future updates or changes.

At the same time—with budget cutbacks, changes in strategy, and reallocation of resources—planned updates for many sites are not happening. Rushed deadlines cause developers to say “we’ll fix it after launch,” yet never get the chance to do just that. Those responsible for information architecture need to plan for updating, but also plan for never updating. Scenario planning should take into account all possibilities, including no budget for maintenance, delegation being passed on to those with different technical skill sets, and updates being performed by an entirely different set of people than those who built the original system. Hopefully the site or application will be updated, but it should be designed appropriately so that it may live on if it is not.


One of the most controversial sessions was a panel discussion on navigation and wayfinding in digital spaces. When a site is being built, inevitably there is substantial discussion about the navigation systems.

  • Should we use tabs?
  • What about fly-out menus?
  • What’s better – having the navigation on the left or the right?
  • How many levels of navigation is the best?

Navigation is a means to an end. It is a journey, and people do not come for the journey, they come for the destination. They want to buy a book, sign up for a newsletter, find a research paper, or view their account balance. Navigation should be as seamless and unobtrusive as possible, but it should ideally go away. There currently are not any effective ways of eliminating the need for navigation, but a longer-term goal should be to develop usable ways to find content without relying on the crutch of navigation.


A number of presentations focused on the importance of metrics and quantitative data. Site logs and search logs were commonly mentioned as vast sources of data that most designers, developers, and information architects do not take appropriate advantage of. Log files can be invaluable in determining usability and information architecture problems on a Web site.

Metrics are not just vital after a site is launched, but must be determined during the development process. It is impossible to say that a project is a success (or failure) if there are no metrics on which to judge it. Bryan Eisenberg, who presented this topic at the IA Summit, also discussed it in his recent Digital Web Magazine article, Dear Marketer: Have you ever looked into the wrong end of a telescope?

In a nutshell, if the client does not know what their metrics are, help them determine appropriate criteria and decide on goals. If these goals are met, it proves the value of information architecture and user-centered design. For a more in-depth look at this process, read the February 2003 IAnything Goes column, A User-Centered Approach to Selling Information Architecture.

Metrics need to tie in to goals, and goals should be created from the top down. Figure out why, what, and how — in that order.

  • Why: Why are we working on this project? What is the goal? How will we know if we accomplished that goal?
  • What: What can be done to accomplish that goal?
  • How: How can we accomplish what we are trying to do? How will the interface be designed? How will the underlying technology be set up?

Determining goals, setting appropriate metrics, and using all available data as a basis should be an up-front requirement of every project.

The Future of Information Architecture

The future of information architecture is deeper, not wider. That is, information architecture will need to focus on the same problems, but come up with better solutions, rather than attacking new areas. There is not a whole lot “new” in information architecture. The small problems have been solved. The scope is not expanding; instead, attention needs to be focused on the big, deep problems.

The task of reducing navigation and incorporating semantic processing into wayfinding systems is certainly a worthy goal. More immediate, however, is the need for improved searching systems, solutions to content management issues, and portability of information architectures across sites and domains.

To explore these problems deeper, other fields need to be acknowledged. Software design, architecture, information science, and graphic communication are obvious targets, but so are art history, music, sociology, economics, poetry, and retail management. Many questions have been answered before, or can be answered more easily by drawing from other disciplines. In this sense, the conference theme of “Making Connections” permeated the presentations and discussions at the conference and will keep information architects busy for some time to come.


Got something to say?

Share your comments  with other professionals (0 comments)

Related Topics: Community, Information Architecture

Jeff Lash is a User Experience Designer in the Health Sciences division of Elsevier. He is a co-founder and Advisory Board member of the Asilomar Institute for Information Architecture (AIfIA) and has also written articles and tutorials for Boxes and Arrows and WebWord. His personal website is