What exactly is information architecture? Is it the same thing as information design? Is it the same thing as design, period? Some job postings for information architecture seem to imply that an information architect can be anything from a database architect to an all-purpose visual designer to a senior technical writer.
The information architect lays a lot of the groundwork for how content is organized on a site, regardless of where that content resides (flat files, multimedia, database fields). And with complex Web sites and portals, an information architect can keep things from turning into a nightmare.
In this article, I'll answer some of the questions posed in this introduction, perhaps clear up some confusion, and provide some Resources for further reading.
The best way to think about the difference between an information architect and a designer is to think about the difference between a building's architect and an interior designer.
The architect primarily cares about structure, flow, and such fundamentals as placement of plumbing and electrical systems. If the architect doesn't do his job, then the building might collapse or fail to meet the needs of the people using or living in the building. For example, there may not be enough bedrooms.
Interior designers, on the other hand, care about color, placement, and style of furnishings; textures; surfaces; and sensory appeal. They may be trying to provide a certain look to rooms, such as Mediterranean or Spanish, or making sure that colors and styles are themed throughout the structure.
This is not to say that either job is easier or harder; they're just different. Obviously, there will always be a little overlap (for example, the architect does care about visual appeal, and the designer does care about flow and access), but in general the two disciplines complement each other. You'd never ask an interior designer to architect a house, and you probably wouldn't go with an architect's opinion of a color scheme for the walls of your living space.
Shifting gears to Web development, the parallels hold. The information architect generally doesn't have much training in identity design, colors, layout, and certain forms of visual communication -- this is the expertise of the designer. However, the information architect is usually someone with a background in categorization, XML, content creation and organization, interaction design, and navigation design. Their expertise is in information structures, and the rest of this article will be devoted to when, where, and how this expertise is applied.
When and where information architects work
The best time to use an information architect is at the very beginning of the development effort. Just as you wouldn't call a real architect to a building site just as the roof is being placed on rickety walls, it's generally a good idea to call in an expert before running into trouble with a Web site.
However, regardless of when you involve an information architect, he will generally want to understand the following parameters of the project:
- User goals and needs
- Business/organizational goals
- Technical constraints
- Content constraints
- Project constraints
Understanding user goals and needs is not a surprise to any usability professionals reading this article. However, some of the other concerns may be new to the Jakob Nielsen set. An information architect's main concern is to build information structures that are easy to comprehend and use. To do this, he must align the goals of the business with the goals of the users, and at the same time work within the constraints posed by the project (deadlines, resources, budget, etc.), technical issues (choice of development language, database, etc.), and content production (staffing, depth of in-house/freelance talent, etc.).
For example, the choice of one language over another might affect the way state is handled on a content portal, which may affect the basic interaction between users and content. Specifically, it may mean that content must be dumped out as one long page instead of broken up into smaller pages. A good example of a content constraint might be a small staff of writers who have little or no domain expertise of the subject matter covered on the site. This constraint might fly in the face of the primary business goal, to create a site with editorial depth of coverage on the subject. In this case, the business might want to think about staffing up on writers or increasing the budget for freelancers.
Although both of these issues, on the face of it, don't seem to have much to do with how content is organized and deployed on a site, they both can deeply affect the user's basic interaction with content.
A Web site's content is not a static object: it can change not only in structure and delivery, but from day to day as well. Being mindful of content strategy and alignment with business goals is the key to successful information architecture.
How information architects work
Information architecture engagements usually proceed in two steps: first, by using a top-down methodology, followed by a bottom-up approach.
A top-down information architecture assessment is usually performed first. As its name implies, this approach helps the information architect understand the big picture and work down toward the details of delivery, page flow, and content structure.
For example, understanding user and organizational goals is one thing, but they need to be translated into some kind of overall picture of the site's content structure. If the site being built is a portal for snow equipment sales and content, then the information architect will need to know how buyers and users of such equipment think about this kind of information. In other words, he must understand the user's conceptual space. For example, snowboards and snow skis would be different categories of products and content. And skiing might contain several subcategories, such as cross-country skiing and downhill skiing. The way that the site is structured from the top down can help make the content more navigable.
A bottom-up assessment follows. This helps the information architect understand the underlying small pieces that make everything work, namely metadata and all the things that involve metadata: what it should do, where it should be stored, how to deploy it, and how the different metadata interact.
As can be imagined, metadata is the linchpin of a lot of site activity, from search engines and personalization to content organization. So what is metadata? Metadata is, literally, "data about data." For example, when we speak, the words that come out of our mouth can be viewed as data. The tone of our voice, our body language, even the personality or attitude of the listener can all be considered metadata. Metadata then enriches our understanding of the data.
To continue the snow equipment site example, let's say that the site owners want anyone who reads an article about downhill skiing to see related products from the site's online store in a sidebar. One way to create this effect is to create a taxonomy of metadata: a kind of hierarchy of terms and concepts that can be assigned to both content and products. For example, a partial taxonomy for the site might look like this:
Snowboards
Skis
Downhill skiing
Cross-country skiing
Slalom skiing
Snowshoes
Etc.
|
If a centralized taxonomy is created and used, then there won't be any guesswork involved with making links between content and products. If all content and products are assigned their proper places in the taxonomy, then users reading an article tagged as downhill skiing will see products in the sidebar tagged as downhill skiing.
Furthermore, if a year down the road the site owners decide they want to implement personalization, then the same taxonomy can be used. Users can be asked to create logins and choose what types of content and products they use or want to emphasize from the taxonomy list. Because the same taxonomy is being used for personalization, products, and content, there won't be any mishaps. Users who want to see the latest content and products related to snowboarding as a personalization preference will get all items tagged as such.
How they get their information
An information architect must gather a lot of information within a limited amount of time using methods like these:
- Prioritized wish lists can be elicited via e-mail, in person one-by-one, or in group sessions. Prioritized wish lists are effective because they allow participants to brainstorm without obstacles or constraints. The prioritization part allows some kind of management filtering of goals and desires. A synthesized list that everyone can see also gives everyone an idea of the scope involved, and this makes ownership of the process a group thing.
- Whiteboard/chalkboard sessions with a small group can allow everyone to explore different areas of thought. They can be used for straight brainstorming, follow-on work from the wish list exercise, or for diagramming page components and page flows. If it's true that a picture is worth a thousand words, actually watching the picture being drawn (literally and figuratively) is worth several hundred thousand.
- A competitive analysis of 3-5 other similar sites, and the delivery of analysis results in a report and presentation can be very useful. Not only can it help dig up additional requirements and "wouldn't it be nice to haves," it can also establish benchmarks for the organization. For example, if a competitor's Web site has 500 pieces of content on it, then management may want to exceed that number by the end of next quarter. From the user's point of view, including well-known features on your site -- what they've come to expect on other sites -- would be a good thing. And, of course, avoiding bad design and architecture choices made elsewhere will enhance the site the team is trying to build.
-
Audience and task analyses are classic methods for figuring out who the audience is and what they want to accomplish. Audience analysis can range from researching demographics and psychographics to ethnographic studies of actual users. The end result of this work is usually a set of use cases that define users (also known as actors) and their tasks. For example:
Bill is a software development manager at a Fortune 100 corporation. He has 30 employees in his department, and needs latest breaking information on programming languages. He's not particularly interested in the technical aspects, only the impact of technology choices on business practices, and particularly on go-to-market effectiveness.
- Focus groups with users can be a good way to elicit comments and get reactions about prototypes or designs. If you go this route, be sure to use an experienced moderator, someone who can elicit good information without "leading the witnesses." Also be sure to at least monitor -- if not record -- the focus group testing. Monitoring and recording is usually done out of sight of the focus group attendees, for good reason. Anyone who is being observed will always change their behavior and responses.
- Finally, one-on-one testing can help the information architect drill down into specific cases. A well-constructed (and timed) scavenger hunt for information, for example, is a good test of how intuitively a site is organized.
Another interesting method is a card sort exercise (see Resources later in this article), which basically asks participants to put like concepts (one each on individual cards) together. The result is something like a crude organizational schema. Taken together, a group of these results can form the basis of a prototype information architecture for a site.
It's critical that bias not be introduced during one-on-one testing. The information architect should not argue with participants regarding their actions. Neither should they correct participants or offer assistance. In fact, the information architect should follow a script. However, participants should be allowed to talk out loud while they perform the test, as this information can provide a nice behind-the-scenes peek at how they navigate their own conceptual space.
Obviously, there's more to the job of information architect than eliciting information. The information architect must also analyze this information, synthesize it, maybe throw a lot of it out, or focus only on certain pieces of it. And then make a lot of good guesses -- by no means is this field of work ruled by strict scientific guidelines. Jesse James Garret, a prominent information architect, says that the key to his success is making good guesses.
Information architecture is a process, not an end result. Many sites will launch with preliminary information architectures, structures and organizations that are "good enough" for now. Even if a perfect site organization were devised, it wouldn't last six months, because in that time something will change (user needs, business goals, etc.) to make it conceptually flimsy.
The best tool that an information architect brings to the task is an open mind. He is not dealing with an easy-to-nail-down list of machine parts. Instead, the task domain involves something much more shifty -- conceptual spaces -- and that means grappling with psychology, the nature of communication, and language (particularly semantics and pragmatics). Furthermore, because so much of the work has a heavy content orientation, the vagaries of finding, creating, polishing, producing, and maintaining content are also a factor.
Because the information architect owns the previously mentioned domain, it is up to him to provide insight, to be a thought leader. Decisions and recommendations not only impact technical development, but also online business practices. If users can't find the content they need, or if they find a site confusing, they won't return. This could hurt revenues and the company's prestige in the marketplace.
Many software applications promise to do much (if not all) of the work that information architects do -- that is, understand content and how it is categorized, published, and managed. Most of these tools are frankly very primitive, and don't live up to their potential (or marketing collateral). This is mostly because of the nature of the work: human languages (and conceptual spaces) are hard to negotiate, and even harder to tie down into repeatable systems and processes.
There's not room enough to discuss each type of tool/software, but hopefully the following list will provide some guidance:
Content management tools try to make the job of managing content easier. They basically allow teams of content creators to publish and manage content (either in flat files, database tables, or both). However, most of these tools have a pretty shallow view of what the lifecycle looks like for any given piece of content (this may be because the designers of such systems have hardly bothered to ask content professionals what their jobs are like).
Most content management systems allow you to create a piece of content and shuffle it around in a workflow. Depending on the system, workflows are either hard or easy to create and bend to the will of actual departmental workflows. Even the best content management systems don't take into account other issues close to the heart of content creation, such as research, drafting, sourcing materials, etc., or take on post-publication management of content very gracefully.
However, given the number of content management vendors, competition might eventually create a tool worth deploying. So far, in my experience, custom applications built specifically for a certain group of people based on open source technologies beat out the shrink-wrapped software every time.
Similarly, automatic categorization tools purport to alleviate the pain of categorizing (assigning metadata to) large volumes of content, such as file repositories, database tables, and even email archives. Some of these tools can't easily handle multimedia files, images, and even complex documents like Visio flowcharts. And they still don't grasp meaning -- they don't understand the difference between the verb duck and the noun duck, nor will they separately classify documents speaking of Java the island, Java the coffee, and Java the programming language.
The best automated categorization tools allow human operators to step in and make judgment calls. A custom tool I helped design offered up lists of potential categories that could be applied to a piece of content based on the human operator's input. It was up to the human operator to choose the appropriate ones from the list, and if no appropriate categories were offered, to choose from the complete list.
Another approach has been to create tools that create and manage thesauri. A thesaurus is an information retrieval tool that pretty much emulates the handy desk reference that writers use. For each term available in a list of terms, the thesaurus can make evident parent-child relationships (hierarchical issues), and point to synonyms (alternate terms) and related terms (concepts that are close in meaning to the term). A well-built thesaurus can alleviate a lot of frustration when it comes to information retrieval.
For example, if you are building an e-commerce site that specializes in selling clothing, then a thesaurus can keep users from ripping out their hair every time they search for "blazers" when in your system you call them "jackets." With a thesaurus, you can establish "blazer" as a synonym of "jacket" and display the appropriate items in the search results. Similarly, when they are viewing a particular jacket, a sidebar might show appropriate pants to go with the jacket thanks to the built-in related terms feature in the thesaurus.
Many thesaurus tools succeed because they are a marriage of the best of both worlds. A human operator is allowed to do what he does best: leverage a powerful brain and tacit knowledge about a subject domain. The computer is also limited to what it does best: bring vast computational resources to crunch through lots of work, and fast.
Learn
- Jesse James Garrett's list of resources on information architecture is an excellent place to start.
- Jesse James Garrett's essay on the state of information architecture is thoughtful and provocative. A must-read for anyone contemplating a career move.
- Kat Hagedorn's "Information Architecture Glossary" is a pretty good list of important terms in the field, defined and cross-referenced.
- Steve Toub's "Evaluating Information Architecture" white paper lists some possible consequences of not having an effective site organization. It also covers some approaches to structuring content.
- Keith Instone runs a very good Web site called Usable Web. It is chock full of all kinds of usability and information architecture topics, plus links to resources on the Web.
- The Argus Center for Information Architecture was a well-known site until it was shut down a year ago. However, it still contains many useful white papers and a glossary of terms.
- Benjamin Fry's Web site contains interesting articles on the subject of data visualization. As a graduate student at MIT, his thesis on organic information design is a must-read for anyone considering heavy-lifting work in this field.
- Louis Rosenfeld's and Peter Morville's book, Information Architecture for the World Wide Web, is already a classic in the field.
- Read "The user experience," by Dick Berry, to get a good idea of why user models are important (developerWorks, October 2000).
- developerWorks Web development zone: See more articles from developerWorks on LAMP and other Web development technologies.
- Technology bookstore: Browse for books on these and other technical topics.
- developerWorks technical events and webcasts: Stay current with jam-packed technical sessions that shorten your learning curve, and improve the quality and results of your most difficult software projects.
Get products and technologies
- IBM trial software: Build your next development project with these tools, available for download directly from developerWorks.
- developerWorks Web Development Downloads and products area: Find more free downloads.
Discuss
- developerWorks blogs: Check out the blogs and get involved in the developerWorks community!
Thomas Myer has been a writer, multimedia developer, Web developer, and information architect. He's written and designed for interactive projects for such companies as Cisco Systems and Vignette, and is currently an independent consultant and writer. You can contact him at tom@myerman.com.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
