Skip to page content or Skip to Accesskey List.


Main Page Content

Information Architecture For Everyone

Rated 3.68 (Ratings: 6)

Want more?


D. Keith Robinson

Member info

User since: 29 Oct 2002

Articles written: 3

Many Hats, One Head?

If you're like me, the terms Web Designer and Web Developer hardly describe the actual

day-to-day work you do. I'm currently employed at a large hospital with the title of Lead

Web Developer. Do I lead? Umm-hmm. Do I do "Web" work? Yep. Am I a

developer? Sometimes. Does the title Lead Web Developer describe my job? Not


I work on a very small team. There are only five of us. The organization is fairly large,

but it is nothing to the amount of information it produces, archives and links to. Trust

me, it's a lot. The five of us, brave souls all, are the sole conduit getting that information

out via web technologies, whether it's to an internal audience via our intranet or external

via front facing Web site. Not only are we responsible for the dissemination of

information, we provide services and applications as well. It's a lot of work, but quite

enjoyable most of the time.

Does this sound familiar? Well if it does, and you're working as a Web Developer or

Designer, I'm sure you, like myself, have needed to wear many different hats in order to

get your job done. I'd bet some of you have been writers, marketers, editors, DBAs,

usability engineers, project managers. The list goes on, right? Well, one thing I'm sure

anyone who has to deal with a large organization or large amount of information has had

to delve into is information architecture. And, I'm sure that some of you didn't even

know you were doing it at the time.

The purpose of this article is to help you define information architecture so that you can

recognize when it is you are wearing an IA hat, as well as provide you some tips, basics

and resources to help you build the most well-architected sites possible. So let's get


What is Information Architecture and why should I care?

There are many different ideas as to what information architecture is and what an information architect does. I've come up with my own definition for the

purposes of this article. Here goes: Information Architecture is the process of creating

as structure for a body of information or content. In our case, this structure is specific to

the production of a web site. It is the foundation upon which a sites user interface is laid

upon, and the mold that a site's content is laid in.

To go with a more traditional metaphor, it is the blueprint from which a web site is built,

or at least it starts there. If you were building your own home, before you started pouring

concrete and buying 2x4s you would have an "architect" layout the plans for your house.

It is much the same with IA � you need a good plan, a good blueprint, before you start to

build your images and work up your CSS.

Don't get me wrong; user interface and content design go hand in hand with IA. The

goals of the site, and the expectations of the user need to be in the mind of whoever is

working on the IA from the start, as wall as keeping the IA in mind until the end.

If you take the time to structure the content and information of your site, before you jump

into design or development, you will have a much easier time when it comes to working

on your user interface and navigation. Your readers and users will also benefit from a

good, well thought out IA. They will be able to find things easier on a site that is

structured to fit their needs, they will spend less time looking and more time reading and

using your site.

Nice. What now?

Now that you have a bit of an understanding of what information architecture is and how

putting some time into getting your IA right can help you out, lets get into some specifics.

Quite a bit of IA is just common sense. It fairly obvious that if we are grouping items by

color, for instance, and orange would go in the "orange" group. Some IAs will be

almost that simple, and everything will seem to fall into place. If you are dealing with a

large amount of information, or information that might lend itself to ambiguity, that is

when you need to really work on how you structure that information.

The first thing you want to do is take time to understand your users, and the goals of your

site or project. It might sound like a no brainer - but I assure you that it's overlooked

fairly often and can mean disaster for your project if not done right. It's vital

that everyone on the team understands the goals of the project. This means the

organization's goals, but more importantly this means the goals of your users. Don't just

ask yourself how people are going to view, access, read and use your site. Ask them.

Do some research, ask questions and interview users � get to know your audience(s). If

you are doing a redesign make sure you get information on how people are currently

using your site, what do they like, dislike and expect. Find out what isn't working.

There are many ways to connect with your users and you should do whatever it takes to

do so. Do use cases and task analysis; conduct a usability test or survey. Here is an

to help you get started.

Once you have your research done and your information gathered, start on a plan for your

project, try to keep your users in mind at all times. Try to envision how your team is

going to meet their goals and when in doubt, go back and ask the users for more


Next, do a content inventory. You need to sit down and go through all the content you

have available to you for your site. You might have some content already in Web form,

for instance if you are doing a redesign, or it might be Word documents or even paper.

The point here is to gather it all together so you can begin to sort it out for your site.

Get to know your content, read it, work with it, and love it. Knowing your content

intimately will greatly help your job. Make sure you interact with the content owners if

possible, I realize this can be like herding cats, but the more you work with them the

easier this will be. Try to concentrate on getting content that is closest to Web form,

ideally you would have content specific for your site, but that isn't often the case.

Next take all that yummy content you've gathered and start to organize it. Break it up

into groups, combine redundancies, and throw out any repeated and useless content. If

you have something that doesn't seem to be "Web" enough, think about ways that can be

re-worked or eliminated. I can't stress enough how having good "Web" content will help

the success of your site, not only with it's organization, but in many other ways as well.

There are many ways you can improve the content on your site, a good place to start is

getting your content owners to concentrate on writing for the Web. If you want to learn

more about good Web writing, or want to direct others in your organization to some

resources, there is quite a bit of good stuff out there. You can start here.

If you are using links to other sites as content, see where you might either link within

your own site or create content within your organization to replace those links. It will

make your site more useful to your users, give your site more credibility, and well it'll be

easier to maintain.

Once your content is gathered, you will then need to decide how to organize your

content, this can vary greatly depending on the type of content you are working with.

This can be very tricky, as semantics and politics will mostly likely rear their ugly heads

here. A good thing to remember is that you are just sorting and grouping the content

right now, not labeling it and not applying a user interface. Those things are for later.

Right now you just need to organize, organize, organize.

There are two main components to organizing your content. Scheme and structure.

The scheme defines the grouping of your content; here you decide what fits together.

There are many ways to group your content, and you will need to find what works best

for your site. You could group your content alphabetically for instance, or by your target

audiences. The more exact your organization, the easier it will be. Chances are you will

use a combination of organization schemes. The key here is to keep these different

schemes separate when moving to design as to avoid user confusion.

The structure of your content defines how items and groups relate to each other. As with

your content scheme, this can be done quite a few different ways. You can go with a top-

down approach, in which you will group your content in a way that users will use a drill

down method to get to deep content, or, you can go with a more inter-relational approach

using links to tie like content together. Again, chances are you will use a combination of

these structures for your site.

The main thing here is to keep your overall site organization in mind as you group your

content. Relate that to your goals and try to keep in mind how people will use the site.

You don't need to worry about getting this perfect, if you understand your users and do a

good content inventory your site will become better organized just by the process of

doing these exercises and getting to know your site better. Not to mention, it's the Web,

you can always improve it later.

No you can begin defining that content and adding labels and Meta data to it. This can be

tricky, do your best not to let semantics get in the way here. If there is ever a debate

about what to call something, as the people who will be using the site, go with what

works best for them.

There are many different theories on how best to label sections within an information

architecture, and you might find yourself in some heated discussions with other team

members, content owners, marketing, etc. For instance, for a contact section, do you use

"Contact Info", "Contact Us" or simply "Contact?"

While these labels are very important, don't spend too much time on specifics, and try to

keep your users in mind. Whatever you end up doing, make sure you keep it consistent,

don't go calling things by more than one label. It's the information and the content that is

most important; the labels will take care of themselves in many cases. We can't avoid

the fact that people will call things by many different names, and that's not even bringing

up the language issue.

These issues can be worked around with good Meta data and controlled vocabularies. Good Meta data will not

only help your users find items on your site, but can help search engines as well. But that

is a bit beyond the scope of this article. The main thing is to keep the labels simple as

possible and make things easy for your users. Once again, if you find out later a label

isn't working, it's the Web; you can change it.

Is that all?

Well, not by a long shot, but at the same time we're not talking rocket science here.

Information architecture is really just that. An architecture for information. It's

structuring your information in such a way that makes it easy to use for humans and

computers. Just by understanding that simple fact and making an effort to learn about

information architecture will help to improve your sites in many ways.

So you want to know more? Here are some good resources to get you started:

D. Keith Robinson lives in Seattle Washington. To read more of his thoughts, visit asterisk*, to view his photography go to Almost Wordless and to get him to do some work for you hit up DKR Productions.

The access keys for this page are: ALT (Control on a Mac) plus: is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.