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.
