of The American Society for Information Science

Vol. 26, No. 6

August/Septmeber 2000

Go to
 Bulletin Index

bookstore2Go to the ASIS Bookstore

  Copies

Information Architecture Practice: An Interview with Lou Rosenfeld, Argus Associates, Inc.

ASISB: 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 information 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 for 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 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).

ASISB: What professional and academic experience did you bring to your current position, and what are the most critical things you have had to learn on the job?

LR: I have a master's degree in information and library studies and did a couple years' of doctoral work in this field. And if you hang around a place like the University of Michigan as long as I did, you can't help getting exposed to other fields like, for example, computer-human interaction. My previous positions were either as a librarian or in developing information systems; I got to learn about two of the Big Three that way. Being a reference librarian puts you smack dab in the face of users' information needs. Building information systems of course gets you up to your ears in content. And the bureaucracy of a large university is a great way to learn how to deal with the third of the Big Three, business context.

The most critical thing I've had to learn on the job was when to shut up and listen. Put more gently, know what you know and know what you don't. Good information architecture design is by definition an interdisciplinary task, and no one person can know everything, or even enough. And information architecture is just one piece of good information system design; an architect must be able to work with people who have expertise in visual design, programming, authoring, marketing, etc. Too many consultants feel the need to pretend to be experts in all these areas, which is just plain silly.

ASISB: If you do your information architecture work as part of a team, what additional essential skills does your team provide?

LR: At Argus, we've built our IA practice on a foundation of librarianship and information science. But while this makes us unique, it's not enough, as mentioned above. So we've begun to augment our teams with specialists from other disciplines related to IA, such as usability engineering, thesaurus and controlled vocabulary development, data modeling and technology assessment. Our teams, made up mostly of LIS people, can draw on these specialists as internal consultants for any project.

ASISB: What are your criteria for determining whether a project has been successful?

LR: Criterion number one is whether a client has even implemented our proposed architectural changes. This is really a gauge of how well we assess the business context for our work: if we've done our homework, we'll provide a solution that can actually be implemented given a client's particular time and budget constraints, politics and culture. But even then our work may not get implemented for purely political reasons that are beyond our control and have nothing to do with the nature of our recommendations. That's sometimes the hardest part of being an external consultant.

We're working hard with our clients to determine metrics for measuring the success of our work. But this is tricky: even if you can isolate a particular improvement in user behavior, it's difficult to attribute it to a particular architectural change; there are many other non-architectural factors that may have had something to do with the improvement. Ultimately we place a lot of value in the more anecdotal feedback our clients get and the fact that those clients turn around and recommend Argus or bring us back for new projects.

ASISB:  What are the four or five information sources, electronic or print, that have been most useful to you in developing your skills and professional approach and in keeping up with current developments?

LR: As a general "keeping-up" tool, I favor the digest service provided by Tomalak's Realm (http://tr.pair.com). There's nothing better; they review and digest from the best sources, and distill it all in one daily e-mail.

For general IA-related material, I like Jesse James Garrett's and Info.Design's sites (www.jjg.net/ia  and www.infodn.com/iares-ia.shtml, respectively), as well as our own Argus Center for Information Architecture (www.argus-acia.com), although I'll admit that I'm biased.

For passionate knee-jerk musings on IA and other topics, Peter Merholz's weblog (www.peterme.com) is a blast. For usability-related materials, I follow Argonaut Keith Instone's Usable Web site (www.usableweb.com). For knowledge management related material, I occasionally go to Brint (www.brint.com), though its architecture gives me a headache.

"Print"? What's that?

ASISB: Looking back to the ASIS Summit, please give us your own definition of Information Architecture in 30 words or less.

LR: Argus' current party line is "The art and science of structuring and organizing information environments to help people achieve their goals."

This definition represents a couple major shifts in our thinking: we used to see IA as helping people find information, but considering that users may have other goals (e.g., being entertained by a game site) we've broadened our definition. We also have backed away from mentioning specific architectural "systems" (e.g., organization, navigation, labeling and searching systems) because we continually find more to architecture than those systems cover.

Our broader definition seems in line with the sentiment expressed at the ASIS Summit, although I'm personally concerned by this loss of specificity. At some point you need to draw lines.

Glossary of Terms
from the IA Practice Interviews

Experience Designer/Modeler: Someone who systematically studies what people think, how they behave and why they use products and services in order to understand how the experience of a website is organized for its users and to translate that understanding into website architecture.

Portal: "A site for a particular audience, providing a path to all-encompassing content and services through one access point. A portal can be a vortal (vertical portal; narrow area of interest) or a hortal (horizontal portal; brad area of interest)." - Kat Hagedorn in The Information Architecture Glossary, Ann Arbor, MI: Argus Center for Information Architecture (Argus Associates), March 2000.  p. [4].

RDF: The Resource Description Framework, sponsored by the World Wide Web Consortium (W3C), is an infrastructure that enables the encoding, exchange and reuse of structured metadata. RDF is an application of XML. For further information see the W3C website at http://www.w3.org/RDF/ or "An Introduction to the Resource Description Framework" by Eric Miller in the October/November 1998 issue of the Bulletin of the American Society for Information Science at http://www.asis.org/Bulletin/Oct-98/index.html.

XML: Extensible Markup Language. A subset of the Standard Generalized Markup Language (SGML) that is designed to make it easy to interchange structured documents over the Internet. It is sponsored by W3C. For further information see the W3C website at http://www.w3.org/XML/ or "An Introduction to the Extensible Markup Language (XML)" by Martin Bryan in the October/November issue of the Bulletin of the American Society for Information Science at http://www.asis.org/Bulletin/Oct-98/index.html.

XSL: Extensible Stylesheet Language. A W3C initiative, XSL "is a language for expressing stylesheets. It consists of two parts: (1) a language for transforming XML documents and (2) an XML vocabulary for specifying formatting semantics."

For further information, please see http://www.w3.org/Style/XSL.

Wireframe: In design, a wireframe is a wire model that shows the contours of a three-dimensional object or, alternatively, a 3-D graphic showing that view; hence, in information architecture, a graphic showing the stores and links of a website at a very high level.  For an example of hand-drawn wireframes, see Gordon, Figure 2.

Lou Rosenfeld is president of Argus Associates, Inc. He can be reached by mail at 221 North Main Street, Suite 200, Ann Arbor, MI 49104; or by e-mail at lou@argus-inc.com


ASIS Home Search ASISSend us a Comment

How to Order

@ 2000, American Society for Information Science