For those not familiar with the field, how would you define information
Information architecture involves the design of organization, labeling,
navigation, and searching systems to help people find and manage information
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
What are the major problems Web-site users encounter that information
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.
- Why is it so hard to find information on the Web, and why aren't search
engines more helpful?
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.
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.
Your professional backgrounds are in the field of information and library
studies. How did you get started working with Web sites?
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
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.
Did the concept of information architecture originate in the field of
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.
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.
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.
Did the term information architecture exist when you started?
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.
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
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
How has the field developed since your book was published in 1998?
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.
Information architecture overlaps many disciplines.
>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.
Other fields that have a lot to offer include technical communications,
data modeling, cognitive psychology, graphic design, and journalism.
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
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
What makes your book different from other books on information
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.
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
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
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?
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.
What do you find are the main obstacles to getting people to appreciate
the value of information architecture?
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.
What are the main obstacles to constructing a Web site with a solid
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
You stress the importance of user-centered awareness for Web-site
developers. Why is the lack of user-centered awareness so common among
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.
You say people confuse Web site design with Web page design.
Could you explain what you mean by this?
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.
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?
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.
Your business, Argus Associates, has been very successful. To what do you
attribute your success?
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.