I promised a few people at PubCon in Orlando that I would begin a series of threads about the basics of Information Architecture (IA). I'm not going to go crazy here, but I hope to cover a few basic ideas that can help anyone with even a smallish site.
Information Architecture is definitely related to navigation, but it is not equivalent to navigation. IA is a very young discipline that draws on Library Science and even Architecture itself, for some of its methods and vocabulary.
When the first companies began creating their web presence in the mid 90's, there was one very common flaw. They organized their online information according to their own internal org chart.
That's very handy for the departments within the company -- for instance, there's no confusion about who "owns" what content. But it proved quite baffling to the average user who only wanted to accomplish certain tasks, not learn the way the company was set up!
That's one guiding principle of IA -- it's the organization of information according to the USERS' purposes. So a company might organize their INTRAnet according to the org chart, but definitely not their public website.
WHAT CAN I DO HERE
In marketing, we often talk about pointing out benefits over features. Our prospect is always focused in what a product or service means to them.
We should follow a parallel principle in IA. The questions a visitor asks are "What can this website do for me?" and "What can I accomplish here?" -- not usually "What is your company all about?"
So as the final result of your IA work, you want to communicate what kinds of things the user can do. Secondarily, you also want it to be a perfect no-brainer to discover WHERE in the site that can be done.
Users will poke around a bit looking for the right spot if they know for a fact that they can do a particular task on this site. But you will lose them very fast if they can't even tell if their purpose is possible here.
PILES OF CONTENT
The first step I take when organizing a new site is what I think of as "piling up content". Unless this website is a re-vision of an exisitng site, then it's usually not realistic to collect only written documents and already prepared applications.
But it is essential to create a master list that contains a very detailed and granular accounting for what your user will see on the website at launch. Even if you have a big pile of content ready to go, you still need to expand that list to what types of things will be added in the foreseeable future.
For all but the smallest projects, I use a physical stack of index cards to create this content pile. One card, one item. Ideally, each card represents a single page in the end product of a site, although some articles or function will naturally require a set of pages.
SORTING THE CONTENT
First I create a table (in Word or Excel) using a master list wiht one item for each index card, or "content bit" -- and several extra columns following it. This is for record keeping, not the sort itself.
Now comes the first card sort. Take the index cards and see how you think a user would group them, like with like. Don't just make this a purely academic exercise - make it a game of role playing.
Draw up a short sketch of a particular visitor who falls within the site's target demographic. Make him or her real -- a name, age, job, hobbies, etc. Then try to get into their head before you do your first sort.
BALLS, BAGS and BOXES
Usually there are many ways to sort your content bits. As a simple example, suppose your site is about "balls, bags and boxes" and you have a choice of red, blue, green for each, and also "luxury" and "every day" versions. Of course this is simplsitic, but you can immediately see three differnt ways of stacking up the index cards.
In the real world you will often notice all kinds of ambivalence between your bits of content, and all kinds of frustrating overlap. When you've completed one sort, give each pile a number and enter that number in your table next to the title of the card.
Then look for another way to sort the cards -- drawing up a different user sketch and getting into that person's head.
TOO MANY CHOICES = NO CHOICE AT ALL
When you offer too many apprently equal choices to a user, they often make no choice at all. For this reason, aim for card sorts that generate no more than seven piles. Five is the ideal, and in my experience using five main divisions also creates the stickiest website.
So definitely make seven your limit, and try to create some five pile sorts.
Why seven? Over many, many years phsychological tests show that seven is the "break" spot for memory. People can easily and accurately repeat lists of words or numbers when there are seven or fewer. The minute you hit eight, the error rate spikes. The human mind tends towqard groups of seven -- don't know why exactly, but it's definitely true.
In very rare cases, seven doesn't seem to work. Then I look for the smallest piles and ask myself if these content types are really equivalent to the other piles -- do they all exist on the same level of importance?
Usually you can find a group that is easily broken off in a kind of auxilliary category - something that will not generate a main menu item but instead can be in a kind of supportive area. It might be certan specialized tasks, or rarely requested but essential support -- all kinds of things are possible. But don't go for any more than seven main categories.
CREATE MULTIPLE SORTS
If you've got a collaborator or two, ask them to do a sort for you. You'd be amazed how differently two people will sort out the same information. So do several sorts, using several people when possible. Record each set of results in your table, each one in a new column.
When you've recorded several ways of organizing the content in your Word or Excel table, then you can easily sort and resort the table to group your content according to each approach you created.
Part Two: LABELS FOR THE PILES [webmasterworld.com]
[edited by: tedster at 10:07 pm (utc) on April 23, 2004]