O'Reilly -- News -- An Interview with Louis Rosenfeld and Peter Morville

Information architecture involves the design of organization, labeling, navigation, and searching systems to help people find and manage information more successfully.

Organization systems are the ways content can be grouped. Labeling systems are essentially what you call those content groups. Navigation systems, like navigation bars and site maps, help you move around and browse through the content. Searching systems help you formulate queries that can be matched with relevant documents.

For each of these systems, there is much more than meets the eye. If this wasn't the case, it would be a lot easier for users to find what they're looking for in web sites (and it'd be easier to maintain those sites, to boot).

Hill:

What are the major problems Web-site users encounter that information architecture addresses?

Morville:

On most large web sites and intranets today, users have tremendous problems finding the information they need to make decisions and answer questions. This is a huge source of frustration for users.

It is also a very expensive problem for web site producers. In a recent study of major e-commerce web sites, Creative Good, a Web consulting and research company, found that 39% of shopping attempts failed due to poor navigation. This suggests an estimated $6 billion loss in online retail sales during the 1999 holiday season.

Hill:

Why is it so hard to find information on the Web, and why aren't search engines more helpful?

Rosenfeld:

It's a simple case of the Web taking something that was already really hard and making it a lot harder. Information scientists were studying information system performance long before the Web was a sparkle in Tim Berners-Lee's eye. [Editor's note: Tim Berners-Lee invented the Hypertext Transfer Protocol, or HTTP.] They've known for years that users had a terrible time finding the information they need in CD-ROM databases, library catalogs, and other online systems.

Related Reading

Information Architecture for the World Wide Web
Designing Large-Scale Web Sites
By Louis�Rosenfeld, Peter�Morville

Table of Contents
Index
Sample Chapter
Author's Article

Read Online--Safari Search this book on Safari:

One reason for this confusion is that it's really hard to express our information needs in words, much less translate those words into a query language understood by a dumb piece of software (i.e., a search engine). Another reason is that it's really hard to index the ideas and concepts that are stored in text (i.e., the stuff we're looking for) in a way that this dumb software can understand (and therefore find). So when we do a search, we're asking something much dumber than we are to do something we find hard to do ourselves.

But at least these older online information systems were fairly narrow in scope, smaller in size, more homogeneous in content and format, and targeted more focused audiences. The Web, on the other hand, has a zillion times more content, covers every known subject under the sun, uses many more formats, and is used by every imaginable audience. This heterogeneity makes it much harder to index and harder to search. Because fewer assumptions can be made about Web users and the kind of content they need, a search engine has an even trickier time on the Web. So what's hard gets harder.

Hill:

Your professional backgrounds are in the field of information and library studies. How did you get started working with Web sites?

Morville:

In 1994, before the Web took the world by storm, we were teaching some of the first academic and commercial courses about the Internet. We both believed the Internet would become an important medium and that librarians had a great deal to offer this brave new world of networked information environments.

We helped early adopters understand and use state-of-the-art tools such as FTP, Gopher, Archie, Veronica, and WAIS. We also designed a number of early Gopher sites. In retrospect, the limitations of Gophers (purely hierarchical text-only solutions) were a blessing as well as a curse. They forced us (and everyone else) to focus on issues of grouping and labeling. Then Mosaic exploded onto the scene and everyone became distracted by graphic design and technology issues.

After some experimentation in the full-solution web-site design business, we realized we wanted to return to our roots and leverage our core competencies as librarians. However, we didn't have a name for this specialization and didn't know whether there was a market for these specialized services.

Hill:

Did the concept of information architecture originate in the field of information studies?

Morville:

It's hard to say where the concept of information architecture originated, since people have been doing information architecture in one form or another for centuries. The structure and organization of books, maps, libraries, museums, and cities are all artifacts, in one sense or another, of an information-architecture design process.

Rosenfeld:

People have been developing information architectures ever since a stylus was first applied to a clay tablet. All information systems have an architecture, planned or otherwise. Books, for example, have sequential, numbered pagination, move top-to-bottom and left-to-right, use title pages, tables of contents, and back-of-the-book indices. These are all architectural conventions that we take for granted. But their acceptance took decades after Gutenberg's revolution.

Web sites, on the other hand, generally have unplanned, accidental information architectures. The conventions aren't really there yet, which isn't surprising given how new the medium is. With all of these information systems, someone has been functioning as the information architect, consciously or otherwise. So information architecture is nothing new in practice.

Morville:

The recent explosion in the number and size of networked, digital information environments has created a need and opportunity for people who specialize in this field.

Hill:

Did the term information architecture exist when you started?

Rosenfeld:

It did. Richard Saul Wurman coined the term about thirty years ago, and others since then (including us) have come up with varying definitions of the term, some quite similar, some not.

Morville:

We first began using the metaphor of building architecture as a way to explain our focus back in 1994. In 1995, we began writing the "Web Architect" column for Web Review magazine. Then, in 1996, Richard Saul Wurman's book Information Architects caught our eye. At first, we were excited by the notion that information architecture was becoming mainstream. But when we read the book, we realized that his definition of information architecture didn't match ours. He focused on the presentation and layout of information on a two-dimensional page. We focused on the structure and organization of sites.

We brashly decided that in our world view, Wurman was really talking about the digital equivalent of interior design or information design, not true information architecture. Of course, not everyone would agree. A healthy and sometimes heated debate over the definition of information architecture continues to this day. These debates are a good illustration of the ambiguity of language and of the political and emotional implications of information architecture design.

Visit web.oreilly.com for a complete list of Web programming, design, and administration books from O'Reilly.

Hill:

How has the field developed since your book was published in 1998?

Rosenfeld:

If postings for "Information Architect" on Monsterboard are any indication, the field is booming. This isn't surprising: Thanks to cheap and easy-to-use information technologies like the Web, people can create information much faster than they can ever hope to organize it. It's probably safe to say that there will always be a greater demand for information architects than anyone can supply.

As far as what constitutes information architecture itself, we've learned quite a bit since we did the bulk of our writing back in late 1996 and early 1997. What we did back in those days, and what our book covers, is what we now call "top-down" information architecture. Top-down architecture is about creating basic top-level structure and navigation for organizing large bodies of content, such as entire sites.

The other area of information architecture, as you might imagine, is "bottom-up" information architecture. Bottom-up information architecture covers how you can organize content at a much finer level of granularity: not whole sites, but at the level of individual documents, or, going further, at the level of content "chunks" that mark-up languages like XML deal with.

Another way to look at this distinction is that top-down architecture is about determining the right questions to ask (e.g., What are the major categories that should drive a taxonomy?), while bottom-up architecture deals with how to organize the answers (e.g., how you structure and classify actual pieces of content). Of course, all information architectures combine both top-down and bottom-up approaches to some degree.

How you chunk, link, and classify "atoms" of information from the bottom-up perspective is something we've not seen many people write about in great detail. This is surprising, because so much of our consulting these days fits squarely into this area. What's also surprising is how few information architects in the field seem prepared to discuss this aspect of information architecture. Many of them seem stuck in a top-down perspective. This is why we've started putting together a new edition of our book, which will cover bottom-up information architecture extensively.

Hill:

Information architecture overlaps many disciplines.

Morville:

>Yes, we actively seek to integrate the concepts and methodologies of other disciplines into our approach to information architecture design. This is one of the most important and enjoyable aspects of our work. In some cases, there's an obvious connection. For example, we've been exploring ways to leverage usability engineering and research methods (e.g., user interviews, affinity modeling) that have developed within the discipline of human-computer interaction (a branch of computer science).

We must learn from users in order to design successful information architectures. There are also disciplines we can learn from where the connection isn't so obvious. For example, we've recently been integrating ethnographic observation methods from the field of anthropology. A few years ago, I wouldn't have guessed that anthropologists and information architects would be working together.

Rosenfeld:

Other fields that have a lot to offer include technical communications, data modeling, cognitive psychology, graphic design, and journalism.

Hill:

In another interview, you talked about the relevance of the librarian's work to the burgeoning problem of information overload. "In sum," you said, "it's not about libraries, it's about librarianship." Has your book had any influence on the fields of library studies and information science?

Rosenfeld:

We like to think that our success has helped gain new respect for librarianship outside the field and has helped open up new career paths for librarians. We know a number of library and information science programs have started to mint new information architects. They offer courses and tracks on information architecture. And, more than anything else, it's gratifying to know that we'll be collecting the standard 3% of all new information architects' salaries.

Hill:

What makes your book different from other books on information architecture?

Morville:

Our book is unique in two respects. First, it's really about information architecture rather than information design. We focus on the art and science of structuring and organizing web sites and intranets so people can find and manage information successfully. Second, it's a very practical guide that explains how to do this work. There are other excellent books on the market that describe general concepts and strategies related to information architecture and knowledge management, but ours is the only one that provides a step-by-step blueprint for getting the work done.

Hill:

Your book is subtitled Designing Large-Scale Web Sites. But the central ideas in your book--at least organization, navigation, labeling, if not searching--are helpful when developing small sites, too. Besides the obvious differences of scale and complexity, does the development of a small Web site call for a qualitatively different approach to information architecture?

Rosenfeld:

Our experience is as information architects for large, corporate sites, so we try to speak from experience; hence the choice of subtitle.

However, we've found that many people have benefited from our book because it provides readers with a lexicon they can use to discuss architectural issues. Although they've always known about these issues, they didn't have the right words to use to hold an effective discussion. The book also provides a basic framework and process they can use to make planning go more smoothly. This is valuable, regardless of the size of the site.

Site size does have an impact on ROI (Return on Investment) discussions. It's much easier to justify the information architecture process when you're working on a 50,000 document site with 10,000 users than it is with a brochure-ware site. However, it's our experience that small sites can become big ones without much warning, so planning the information architecture from the start is usually a good idea on any site.

Information Architecture in Practice

Hill:

Your book presents principles and concepts that developers can apply to particular sites; but, as you've said elsewhere, "We don't tell you how to design your site; there is no one right way to do it." Why is this so?

Rosenfeld:

Every information architecture is different, and should be. Why? Because a successful information architecture ties together users and content, all against the backdrop of what the sponsoring organization's goals and constraints are. And those things--users, content, and organizational context--all are highly variable in each situation. So there can be no "Correct Information Architecture." Nor is there a single obvious template to use and reuse. That's why we try to teach our readers how to fish.

Hill:

What do you find are the main obstacles to getting people to appreciate the value of information architecture?

Morville:

For most people, information architecture is invisible and intangible. When it's done well, nobody notices it at all. When it's done poorly, users become frustrated, but they often can't articulate what's wrong. As a friend of ours once said, information architecture is similar to chronic fatigue syndrome. We often don't know what's wrong or how to fix it, so we endure.

Hill:

What are the main obstacles to constructing a Web site with a solid architecture?

Rosenfeld:

The major obstacle is temptation: It's human nature to want to dive in and design, author, and code. These are fun and, more importantly, are tangible; so people don't bother with the un-sexy intangible stuff like planning a strategy, designing a coherent information architecture, and so on.

Of course, the fun fades fast once people must contend with an unusable, impossible-to-maintain, and completely screwed-up site. First-hand pain is the information architect's greatest friend. Countless explanations and warnings are no substitute for first-hand experience. That's why our best clients are on their third, fourth, or later generation sites. In such cases, we don't need to educate them about information architecture. No, at that point, we need to help them navigate the other major obstacle: organizational politics. [Editor's note: You'll find suggestions for overcoming political obstacles on pages 132-139 of Information Architecture.]

Hill:

You stress the importance of user-centered awareness for Web-site developers. Why is the lack of user-centered awareness so common among Web-site developers?

Morville:

The truth is that in many web site and intranet design projects today, people are in over their heads. They lack the management experience and the time-tested methodology needed to ensure an intelligent, informed decision making and design process. People set unrealistic schedules and the first thing squeezed out is the user of the site. In the short-term, it's faster to design based upon opinion than upon real user-generated data.

Hill:

You say people confuse Web site design with Web page design. Could you explain what you mean by this?

Rosenfeld:

We see page design as an example of information design. It's quite challenging, but ultimately two-dimensional. Site design is multi-dimensional, involving collections of pages that can be assembled and presented in an infinite number of ways. More variables and greater volume result in a higher level of complexity.

Hill:

You've said that most information architecture is essentially information retrieval, and that information retrieval doesn't work too well and won't improve very much. Are you suggesting that the most powerful information architecture tools are the more conceptual tools, such as user analysis and organizational, navigational, and labeling systems?

Rosenfeld:

Yes, sort of. We do believe that conceptual tools and approaches (such as manual indexing) to solving information retrieval problems are really important and really powerful. But we're not Luddites. Honest. Search engines, content management systems, and other technological approaches to information retrieval problems are also very important and very powerful.

We're just sick and tired of the ridiculous and dangerously misleading hype repeatedly spouted by vendors. Some vendors will have you believe that slapping a search engine up will instantaneously solve all your users' problems--and all your problems, as well. Readers, beware especially of products that offer tantalizingly simple-sounding solutions to complex problems. A good indicator of such silliness is the phrase "in a Box" (e.g., "Portal in a Box," "Librarian in a Box," "Financial Planner in a Box," "Air Traffic Controller in a Box").

Really, whether we're talking about technological or conceptual approaches, they're all just tools for addressing problems of information retrieval, each good at solving a small and limited problem. The big prize goes to those who figure out the best hybrid solution that combines the most appropriate set of technological and conceptual tools to help your particular community of users find their way to your unique content.

Hill:

Your business, Argus Associates, has been very successful. To what do you attribute your success?

Rosenfeld:

We've had a lot of patience. It's not easy to watch every other Internet entrepreneur on the planet become a billionaire overnight, especially when you've been at it for half a decade. But we've always known that our niche would explode after the Net had matured some, and that's exactly what's happening now. And the lag has given us time: We feel we've created a well-run company and culture that will scale smoothly in the face of heavy growth.

Patience, planning, and a carefully coordinated program of animal sacrifice, self-flagellation, and occasionally rubbing my bald uncle's cranium have really been the keys to Argus' success. At least that's what Nostradamus claimed would work.