Note: This article appeared in Intranet Professional, prior to its re-launch as Intranets (in 2004).

IP: What unique role does an information architect play in ensuring the end user has a positive experience on the intranet?

PM: Before I proceed, a disclaimer is in order. Many intranet design projects do not involve a specialized information architect (IA). In small to medium businesses, an intranet manager or graphic designer often handles this responsibility. Usually, only the largest organizations can afford to hire a specialist into this role. However, in every intranet project, someone must wear the IA hat, and it is very important they understand the fundamental concepts and methods.

In short, the information architect is responsible for designing the organization, labeling, navigation, and search systems to support business goals and user needs. Key deliverables may include blueprints, site maps, wireframes, metadata schema, controlled vocabularies, and functional requirements for search and navigation. The architect will draw upon a mix of tools for discovery and design, including contextual inquiry, usability testing, stakeholder interviews, content analysis, personas, scenarios, card sorting, free listing, and rapid prototyping.

The quality of the information architecture has a major impact on the user experience, influencing whether or not employees can complete tasks and find what they need quickly and effectively. The IA can also serve as a vital bridge between the software development, content management, and visual design teams by providing a solid foundation and common framework for intranet strategy and design.

I like to remind people that interface stands on the shoulders of infrastructure and that the structural design performed by information architects helps reconcile top-down and bottom-up efforts into a coherent whole.

IP: How do information architects know when they have successfully accomplished their function? What methodologies may be used to determine success?

PM: Since an intranet typically results from an interdisciplinary, cross-departmental team effort, it is very difficult for any single team member to claim success. A bad visual design can obscure good information architecture. A flaky server or insufficient bandwidth can render any site into a horrible user experience. In a successful intranet environment, the whole is greater than the sum of the parts.

But there are a variety of commonly used metrics for evaluating the information architecture. Most focus on findability. Some user tests measure "time to find" and "time on task." Some measure the number of clicks, the success rate of task completion, or the percentage of relevant documents retrieved. Often these are simply variations on traditional measures of recall and precision. These metrics can be useful. They can also be dangerous. Optimizing for fast findability may result in a site that is less useful, usable, desirable, and credible. The thirst for simple metrics that indicate success or failure must be held in check. Many elements feed into the intranet user experience. In turn, the intranet has countless visible and invisible effects on the organization.

It is often more useful to track against strategic business goals, even if it is impossible to isolate variables or define exact quantitative measures. Perhaps you are striving to increase employee productivity, decrease internal transaction costs, or encourage cross-functional knowledge sharing. The trick is to work backwards from these goals and ask how the information architect can help.

IP: What are the must-have skills and competencies for this role?

PM: Information architects must be natural-born organizers. It is amazing how many IAs organized and classified their book collections during childhood. In my case, I even created a check-out system and charged late fees to my brother and sister.

So, an IA must be skilled at recognizing patterns in com- plex information environments and envisioning possible ways of organizing and labeling to foster understanding and facilitate navigation.

An IA should be educated in the fundamentals of classification and user behavior, drawing upon both library science and human-computer interaction. This foundation knowledge must be supplemented by a broad education in a variety of areas, including software development, visual design, business management, cognitive psychology, and ethnography.

Last, but definitely not least, an IA must be an expert listener and an excellent communicator. Through a combination of active listening and subtle persuasion, the IA must define a strategy and plan for the intranet that meets business goals, employee needs, and the capabilities of the intranet development team.

IP: Which associations, standards bodies, professional literature, communities of practice, and continuing education programs do you recommend for anyone interested in the subject of information architecture?

PM: I'm biased. I'm a co-founder and director of the Asilomar Institute for Information Architecture [http://aifia.org/], an international nonprofit professional organization dedicated to advancing the practice of IA. So, naturally I believe everyone interested in IA should join our growing community.

However, we actively encourage our members to participate in other professional associations, such as ASIST, AIGA, ACM, and STC. Our goal is to serve as a bridge between communities, linking academia to business and connecting people across professional, disciplinary, cultural, and national boundaries.

The largest conference for information architects these days is the annual IA Summit sponsored by the American Society for Information Science and Technology. This year's event in Portland, Oregon, was a huge success [http://www.asistevents.org/IASummit2003/], and I encourage anyone who cares about IA to attend next year's summit.

Also, there are lots of books and online resources that provide a conceptual foundation and current awareness of important trends and issues. For example:

• Information Architecture for the World Wide Web by Louis Rosenfeld and Peter Morville (O'Reilly, 2002).
• Information Architecture: Blueprints for the Web by Christina Wodtke (New Riders, 2002).
• Bloug Web log [http://louisrosenfeld.com/]
• Boxes and Arrows magazine [http://www.boxesandar rows.com/]
• Information Architecture Resources directory [http://www.jjg.net/ia/]
• IA Slash Web log [http://www.iaslash.org]
• Semantics column [http://semanticstudios.com/publi cations/semantics/]

IP: If you could transfer key learnings from your own experience to someone just starting out, what would be the top three?

PM: First, involve real users. In my first years as an information architect, users remained an abstract concept. I worked directly with my clients. I knew how to organize Web sites. They knew their business and their goals. We all felt we were working on behalf of the user.

Thankfully, over time we realized the power of involving the user in the process. At first we felt a bit threatened by the idea. What if the user challenges our authority as experts? What if we never satisfy the user? Isn't this all too time-consuming and expensive? Maybe it is safer to pretend we know what users need.

But in reality, we found that user research and testing can make projects far more fun and interesting and can lead to a much more successful solution in the end. We also discovered ways to knit user tests into projects of all shapes and sizes. Time and budget should never be an excuse for not involving the user or customer in the design process. I wish I'd been taught this lesson earlier.

Second, partner with techies. On any significant intranet project, the software developers, programmers, coders, technology integrators, and system administrators have tremendous influence over the process and result.

Techies can turn your Web design experience into a living hell. Techies can make any intranet project fail. Or, they can contribute brilliant insights into design and process and make the end product far better than you ever imagined. Good information architects must be able to speak the language of software development and must find ways to earn respect from the techies they will depend on to transform ideas into implementation.

Third, trust your gut. At the end of the day, information architecture is as much art as science. We can gain insights by reading the latest research studies. We can learn a great deal by integrating user research into all phases of the design process. And we can strive to understand and apply emerging best practices.

But no matter how hard we try, it's impossible to remove the key elements of experience, expertise, creativity, and risk-taking from the design process. A good information architect is a master craftsman. Much of his or her knowledge is tacit. You know the right direction but cannot defend it clearly in the language of business logic. Experienced information architects must have the courage to trust their gut and the willingness to passionately advocate for their solutions.

I remember one case where we argued quite ferociously with a client over a set of design decisions. Eventually we gave up and did it the client's way. Several months later we conducted a follow-up interview with this client. She said that overall she was happy with the information architecture but that she wished we had made a stronger case for the ideas she had shot down. In hindsight, so do I.