2.1. The Role of the Information Architect
Now that you know right from wrong from the web consumer's
perspective, you're in a much better position to develop a web
site. But besides needing a sophisticated knowledge of what works for
consumers of the Web, what's actually involved in creating a
web site?
Obviously, you need HTML pages. Maybe you'll grab a good HTML
book or a decent HTML editing package. Maybe a high school kid can do
the trick for peanuts. What about the copy for those pages? It needs
to come from somewhere -- perhaps existing brochures and
documentation; perhaps it needs to be written from scratch.
You'll also need some graphic design expertise to make sure
that the pages are laid out with effective use of text, white space,
and attractive images. Of course you'll need a server that is
connected to the Internet; this you can lease, or you can buy one of
your own. If you do, just be sure to hire someone sufficiently
technically astute to administer that server. Perhaps that person
should also write the CGI, Perl, ActiveX, Java, and other scripts
that make the site interactive. What's missing? Maybe a project
manager to make sure all these folks work together to develop the
site without running behind schedule and over budget.
So now you're all set to design your web site, right?
Well, not quite. What's missing from this picture is a
definition of what the site will actually be, and how it
will work.
This may sound obvious, but for most web sites, it's true:
design and production storm ahead without any unifying principle to
guide the site's development. A web site essentially can be
anything you want it to be and could cost millions of dollars, take
years to complete, and cost thousands of lives to develop. To avoid
such overkill, it will need to be defined somehow: it will need a
definition.
That's the main job of the information architect, who:
Clarifies the mission
and
vision for the site, balancing the needs of its
sponsoring organization and the needs of its audiences.
Determines what content
and functionality
the site will contain.
Specifies how users will find
information in the site by defining its organization,
navigation, labeling, and searching
systems.
Maps
out how the site will accommodate change and
growth over time.
Although these sound obvious, information architecture is really
about what's not
obvious. Users don't notice the
information architecture of a site unless it isn't working.
When they do notice good architectural features within a site, they
instead attribute these successes to something
else, like high-quality graphic design or a
well-configured search engine. Why? When you read or hear about web
site design, the language commonly used pertains to pages, graphic
elements, technical features, and writing style. However, no terms
adequately describe the relationships among the intangible elements
that constitute a web site's architecture. The elements of
information architecture -- navigation systems, labeling systems,
organization systems, indexing, searching methods,
metaphors -- are the glue that holds together a web site and
allows it to evolve smoothly. To a novice, this terminology is not
very clear. These elements are extremely difficult to measure, and
therefore even harder to compare. You really have to spend time using
a site and get a feel for it before you can confidently talk about a
site's information architecture.
Yet, we know these things are important. How? Well, consider your
responses to the Boot Camp exercise in Chapter 1, "What Makes a Web Site Work". How many of the
likes and dislikes are not related to technical
issues, copy editing, or graphic design? Remaining issues are
probably tied to information architecture. Although perhaps
indirectly, a poorly planned information architecture will adversely
affect those other areas.
Well-planned information architectures greatly benefit both consumers
and producers. Accessing a site for the first time, consumers can
quickly understand it effortlessly. They can quickly find the
information they need, thereby reducing the time (and costs) wasted
on both finding information and not finding
information. Producers of web sites and intranets benefit because
they know where and how to place new content without disrupting the
existing content and site structure. Perhaps most importantly,
producers can use an information architecture to greatly minimize the
politics that come to the fore during the development of a web site.
2.1.1. The Consumer's Perspective
Consumers, or
users as we more commonly refer to them, want to find information
quickly and easily. Contrary to what you might conclude from
observing the architectures of many large, corporate web sites, users
do not like to get lost in chaotic hypertextual webs. Poor
information architectures make busy users confused, frustrated, and
angry.
Because different users have varying needs, it's important to
support multiple modes of finding information. Some users know
exactly what they're looking for. They know what it's
called (or labeled), and they know it exists. They just want to find
it and leave, as quickly and painlessly as possible. This is called
known-item searching.
Other users do not know what they're looking for. They come to
the site with a vague idea of the information they need. They may not
know the right labels to describe what they want or even whether it
exists. As they casually explore your site, they may learn about
products or services that they'd never even considered.
Iteratively, through serendipity and associative learning, they may
leave your site with knowledge (or products) that they hadn't
known they needed.
These modes of finding information are not mutually exclusive. In a
well-designed system, many users will switch between known-item
searching and casual browsing as they explore the site. If you care
about the consumer, make sure your architecture supports both modes.
While attractive graphics and reliable technologies are essential to
user satisfaction, they are not enough.
2.1.2. The Producer's Perspective
Since few organizations are completely
altruistic, they usually want to know the return on their investment
for information architecture design. In other words, what's in
it for them? First, a disclaimer. Buying information architecture
services is not like investing in a mutual fund. You can't
calculate hard and fast numbers to show the exact benefit of your
investment over time.
Nonetheless, you can demonstrate the value to
the organization through less scientific means. Depending upon the
goals and nature of your site, you may even be able to defend your
investment with some not-so-hard numbers.
Consideration of value to the producer takes us back to the consumer.
If you're producing an external web site, this involves actual
and prospective customers, investors, employees, and business
partners, not to mention the media and senior executives within your
organization. Do you really want to frustrate any of these people?
What is the value of quickly and easily helping them find the
information they need?
If you're producing an intranet, the employees of your
organization are the consumers. What is the cost of their time spent
to find the information they need? What is the cost when employees
don't find the information they need?
Finally, we need to consider the actual costs of designing and
implementing the architecture. A well-designed, diplomatic
architecture can prevent costly political battles that can stop a
project in its tracks. The cost of time spent by high-level
executives arguing over which department's information belongs
on the main page can skyrocket if you're not careful. A
well-designed scaleable architecture can prevent doing it all over a
year later. Far too many architectures are crushed under the weight
of their own content. Redesign of the information architecture
impacts all other aspects of the web site, from graphical navigation
bars to the content itself, and it can be a very costly
adventure.
Let's illustrate with a real-life example.
Recently, we met with
about ten members of a large client's web site development
team. Because we were in the early stages of the planning process, we
had just reviewed the client's likes and dislikes, and were
determining their web design philosophy. Now we were ready to begin
defining what their site would be.
In discussing the site's likely users, around seven or eight
audiences were suggested. Five or six major goals of the site were
determined. Finally, we talked about the main areas of content and
functionality that the site would include. This wish list included
thirty or forty items. We now had a lot of useful lists and ideas,
but was the web site ready to be designed yet?
At this point, many site designers would happily dive in head first.
Their work would be a site headed by a main page that included thirty
or forty items and links, tried to please seven or eight different
audiences, and ultimately failed at achieving its five or six goals.
This is what happens when the big picture of a site is ignored.
Consider what happens to a site with a single designer who sees only
the trees, not the forest. Now add an order of magnitude: large
organizations, rife with complex goals and messy politics, often have
sites designed by ten individuals with their own vision of the site,
their own deadlines and goals to meet, and their own politics to
play. Is it any wonder that these sites often work so poorly, even
when huge investments of time and money are made in them?
Succinctly, information architecture is about understanding and
conveying the big picture of a web site.
Back to our client's committee of ten tree-people. They were
still struggling over what the site would ultimately be. Which goals
are the most important? Should the site be informational,
entertaining, or educational? Should there be one main page for all
audiences, or one for each audience? Should we design an architecture
that organizes the site's information by topic, by function, or
in some other way? Who within their organization should own and
maintain the information in the site? What kind of navigation and
wording would make the most sense?
Our last meeting ended in frustration, as the committee members
argued but never resolved these points. They were especially unhappy,
as they'd thought that designing a web site was supposed to be
fun, without the haggling over audience definitions, dredging up of
organizational politics, and dealing with other unpleasantries that
had come up in the discussion. Some even expressed concern that we
shouldn't even bother wading into this swamp and instead should
start doing something, like gathering together
the site's content, pushing forward on the graphic design, and
so on.
Having exposed so much frustration, we were obviously on the right
track. Why?
Because these thorny and confounding issues of information
architecture must be resolved during the design process,
before the site is built. If we were to avoid
answering these questions and the site's development was to
proceed, these issues wouldn't go away. Instead, the
burden would be on the site's users to understand
how to use and find information in a confusing, poorly-designed web
site. Of course, we know that a frustrated user will click and leave
with a bad memory of the site, likely to never return. Without a
clear information architecture, the site's maintainers
wouldn't know where to locate the new information that the site
would eventually include; they'd likely begin to quarrel over
whose content was more important and deserved visibility on the main
page, and so on.
