Richard BF

I’m reposting the following (slightly edited) internal blog entry from a few years back. We’ve recently been doing quite a lot of information architecture work, and I felt perhaps the outside world would find it useful as well. While our models have developed a lot since then, the basic concepts are still the same. Recently adapting them to the blogging world has also been interesting.

[…] Most people seem to define Information Architecture as something to do with “arranging information into useful categories”. But this is still very vague when you start considering what “useful” and “category” mean. Few seem to have an answer on this.

Information architecture is actually a generic term used to describe anything even remotely relevant to the “arrangement of information into a structure”. Some groups have shanghaied the term for their own use, but I still prefer this generic definition.

Now let’s get a little more specific, in particular web based information architectures. There’s slightly more information out there on this, and there are several popular books now available on it. In the web space, there are several types of information architecture, all layered over a single web site.

The first major layer is at the browser level, where we have the visual architecture, or the site map.

Under that, we have the user perceived information architecture. The web, by its nature, implies a notion of location within a site (thus unfortunately validating the “web page as location” metaphor), and so this implies a user perception of where information is located. This may map directly to the site map, but through the use of user interface and graphic design, this may not be the case, intended or otherwise.

Supporting this is what most people see as the information architecture. Again, this may map directly to the other layers, but does not need to. The smaller the site, the more direct the mapping.

Finally, we have several layers of the technical implementation of the architecture. This may be database tables or static files in directories. Like the other layers, it may map directly, or it may not.

This layering of information architectures is intertwined with several other layers of abstraction when delaminating a web site, these being the site objectives, the user requirements, the actual information content, functional specifications and a range of other influential data.

So how do we design information architectures which conform to this layering model?

Here’s a fairly rough step by step guide to designing web site information architectures. Good luck finding it on the web, because from what I can tell, nobody’s actually fully documented it. Several have come close, but they tend to focus on their main areas of expertise instead of building the full picture.

1. Catalogue the current content, so you know what’s available. If you don’t yet have any content, then plan what this content will consist of.
2. Define your typical web usage patterns. These are like mini-use cases, and define a bunch of patterns for the standard interactions users will have for the site, triggers, goals and the priority for consideration on the site.
3. From each pattern will come a range of recommendations for navigation and information achitecture. e.g. a low priority usage pattern is for users to research domain specific terms used elsewhere in a site. The entry point for this pattern could be anywhere on the site, because of the nature of the content. Thus, a recommendation that term definitions be available from every page within the site, but the full list of terms is not available until the user is at the terms page.
4. Create a skeleton information architecture and site map from the recommendations. For small sites, a site map may be all that is required, but for larger sites, a defined information hierarchy may also be required. Site maps are typically best represented by a data flow diagram. Information hierarchies are best represented by some type of tree diagram. A common mistake is to assume that these are different representations of the same thing.
5. Populate the information architecture with the content.
6. Design a wire frame for the user interface. This will come almost directly from the site map for technical purposes, and the visual design for aesthetic and usability purposes. There will be give and take, because there’s no such thing as a perfect world or an infinitely long project time line. Such influences include financial, political, forward planning, psychological and moral reasons.

The thing I like about this process, is the objective steps which lead to the final architecture, particularly steps 2, 3 and 4. […] We often discuss web site usability and navigability with clients, and by having an objective process, we find that web site review/analysis is not only supported by objective criteria, but the process is actually a lot easier to peform, and the results much more detailed and useul. This makes both us and our customers happy.

(Originally posted to Synop weblog)