Information architecture practice: An interview with Lou Rosenfeld Argus Associates, Inc.

Bulletin of the American Society for Information Science, Aug/Sep 2000

AISB: Can you describe in some detail what you (or your firm) do for your employer or your clients? If you have a specialization, how would you characterize it?

LR: Argus Associates specializes exclusively in information architecture consulting and design. For about six years we've consulted for an interesting variety of Fortune 500 and dot com companies that are experiencing some sort of information pain: pain from wasting millions on developing a site where users still can't find the information they need. Or pain from pouring so much content onto their intranets that content managers are overwhelmed. Frankly, there's so much pain out there that I think we should start calling ourselves information therapists rather than information architects.

ASISB: Please describe a specific IA challenge that you have solved.

LR: One of our Fortune 100 clients operates an intranet that provides facilities-related information to all of its 150,000 employees. Temperature too hot in your cube? Need to get your office packed up and moved to another part of the building? Want to know the procedure for signing a new lease? Wondering when they'll be done re-paving your building's parking lot? This is the site that answers your questions.

Or at least, it should have answered your questions. The problem was that users couldn't find much, or much of anything useful, on the site. This was due to a classic "organic" information architecture where content was created and organized in different, non-standard and mostly unplanned ways by dozens of building managers, project leaders (e.g., the folks responsible for getting that parking lot paved) and employees of this facilities division. As you'd expect in such a decentralized scenario, the content was highly inconsistent in format, coverage, currency and accuracy. Users, especially the tens of thousands of regular employees who wanted to get simple facts about their offices and buildings, couldn't find what they needed from the site. And, as no policy for weeding was in place, it had become a messy content management challenge as well.

The problem was, therefore, as much about content management as about intormation architecture; not surprisingly, they often go hand-in-hand. To make a long story short, we concentrated on learning about users' information needs so that we could establish what subset of the client's content would actually help answer those needs. Based on that knowledge, we established some major content object types, such as facility descriptions, ongoing project descriptions, tasks that tenants would wish to complete and so on. We developed a standardized and highly granular content model for these documents, including rules for automatically linking these documents, metadata attributes and controlled vocabularies to facilitate both browsing and searching. We then worked with the client's technical team to develop a database model to support the architecture. And perhaps most importantly we developed criteria and scheduling far regular feeding of the site: it's now clear when to add, modify, delete and index these types of contents and whose responsibilities these are.

The result is an architecture that doesn't cover the entire collection of content, but is highly evolved for providing access to the really useful subset of the site's content, the stuff that users really care about most. We know from anecdotal and increasingly from quantitative evidence that the new architecture has made a positive difference.

ASISB: Could you discuss your methodology? What tools, techniques and software do you use?

LR,: Our methodology is really pretty simple. In fact, half the battle of information architecture is having a methodology in the first place. Good information architectures are planned architectures and subscribing to some sort of methodology is what ensures that time and budget concerns don't squeeze the planning activity out.

Our methodology has three phases: 1 ) Strategy and Recommendations; 2) Conceptual Design; and 3) Implementation. The first phase begins with extensive research (including user it and stakeholder interviews and content inventory and analysis). It concludes with an architectural strategy consisting of a "50,000 foot view" of the proposed architecture, related policies and procedures for maintenance and the project plan for getting it developed.

If we specified that, for example, the proposed architecture will require a topical taxonomy for user navigation, we'll go ahead and develop that taxonomy (and other required architectural components) during the conceptual design phase. During the implementation phase, we get out of the way and let our client teams build what we've planned (ideally, this is a "painting by numbers" process). We stick around for quality control and knowledge transfer; for example, we often train our clients to maintain and apply controlled vocabularies used for manual indexing.

All three phases share a common thread: we iteratively learn about and address the unique aspects of users, content and business context. These are the Big Three: ignore one and your architecture will be garbage. We also strive for interdisciplinary collaboration all the way through; we want the other members of the development team both to understand what we've come with (so they can implement it) and to contribute their own perspectives to our work (we only know what we know and welcome others' knowledge).