Designing Information

A few times over the past week or so, "information architecture" has been brought up in meetings, referenced on the new site design, or just bandied about as a function when selling. And when someone didn't know what we meant, we... had nothing to point them to. It's so baked into our understanding as interactive designers, we've never actually defined it from our point of view. Even in my book, where I discuss pretty much everything else to death, I talk past IA several times, but never look at it head on.

First of all, it's like a lot of things in this new interactive world, and has multiple meanings. As interaction designers, doing generally user-centered things, we're not generally talking about the technical structure of a system; though it may be related and you really should be aware of the organization of data stores, and how information moved between systems, other people do that.

Origins are useful. The term is generally attributed to Richard Saul Wurman, who meant architecture as "used in the words architect of foreign policy. I mean architect as in the creating of systemic, structural, and orderly principles to make something work – the thoughtful making of either artifact, or idea, or policy that informs because it is clear." There are some objections to the term whereby architecture is understood to mean a building, so immobile and permanent, but that's not what it means.

Making Sense of Information

So, it's about exerting creative influence over information. And really, all that an interactive system is about is information. Even if you use an interactive service to get actual stuff delivered to your door, the interactive part is all about information presentation and exchange. Borrowing from Brenda Dervin's article in the 2000 book Information Design information is "a tool we use to make sense of the world."

To that end, information architecture is about designing the information senses used in some system – and for our purposes, interactive systems like websites and applications – to encourage a mental model and encourage methods of interacting with the information. All to improve the user's experience, to encourage buying products, or whatever the goal of the system is all about.

For those who like analogy, compare interactive design to the structure of books or film:

You won't get far with a bad plot, and you won't get far with a bad IA.

Static systems - Structural Information Architecture

Information architecture can be broken down a zillion different ways. If you get out of interactive design, it can be applied equally validly to a dozen different types of work alone. But I am going to consider just two. First, what I'll call "static" systems.

A sitemap is a classic static IA model. If you draw something like this:

That's the information architecture for your interactive product. So, it's also important to know these exist even if you don't design it, or design it well. This can be critical not just to understand the concept, but if you go to redesign a system. If you ask and the client says it "has no IA" they may not be deliberately lying, but they are wrong. A good first step is to map out what it really is, and try to understand why. Internal structure and jargon is usually bad, but it's something, and tells you what the client thinks of their own organization, and understanding all that is a good first step for the designer.

The next step is to make something that addresses the true needs of the enterprise, the product, the project and the end users. Sometimes, the information is so important, has so much inherent truth or is so regulated there are limits on how it can be presented. Billing information, weather alerts, stock quotes and all sorts of stuff actually cannot be messed with too much without changing the actual meaning (or breaking a law or two). Those are external constraints. Internal constraints are systems that serve up the information; you can often work around or within these, but ignoring them will just anger the implementation teams and you'll be lucky to get any of your design implemented right.

Yes, these are not necessarily static in the true sense. These are interactive, so parts can appear, disappear, or move. And that's just today or based on current conditions or what sort of user you are.

So, underlying your design of the information architecture should not just be goals of the system, or the underlying truth of the information so it is best organized, but underlying principles that can be applied late. As the system expands or changes, it can be modified in sensible methods without a total redesign, or simply breaking the IA by tacking something new onto the side.

Incidentally, I tie this into the design of individual pages (or states of pages, or views or whatever else you are comfortable with) and call the whole exercise Information Design.

Fluid systems - Systematic Information Architecture

The second type of information architecture I'll call "fluid." Again, it's not really that true to call it that, but it works to remember them, at least for me. This is about taxonomies of information, and I think of it as fluid more every year as more and more information is user-generated or user-modified.

Tagging systems are an ideal sort of taxonomy in this sense. And the most open, or fluid would be folksonomies, like Flickr tags. End users type whatever they want and that becomes the organizational structure.

But even these are not totally open. There are systematic constraints. There are formatting conventions. Some information cannot be typed. Flickr, for example, also accepts the EXIF data from your camera, and location information, which must be in specific formats and has specific meanings. The manner in which this information can be accessed also strongly influences not just understanding, not just interaction, but the effective use of the tagging system by end users, and therefore the actual taxonomy. Even very open systems have to be designed, and designed with the same constraints as anything else, considering enterprise goals, system constraints and end user needs.

Then there are the systems that sort of take the middle path. Think of the huge catalog of information Amazon has. I consider that a fluid system, as the number of items (or even the balance between them) is constantly changing and almost totally unpredictable. Each item in the catalog can be tagged with general information, may or may not have a lot of other information attached to it, and has to have a few fields (a name, a category) for it to be displayed at all.

Architecting the experience

That concept of a category for Amazon is worth coming back to. There's fairly fluid information, but it's in a strict upper-level organization. That's because there are at least two sorts of IA being used to build that site. The sitemap level static system of major categories or a few expected pages (home, help, etc.) which is a top-level organizing principle for the more fluid organization of each product that lives inside the system.

Most of your products will, really, be like this. While it is good to be aware of the types of IA, and you may even need to provide several definitions, in the end it all has to work hand in hand.

And even more so, the architecture has to work with the interactive design (as I mentioned, I assure this by considering IA and IxD as a single exercise, called Information Design), the visual design and branding, the marketing, the customer care and help systems, how packaging works if you have any physical products, and the whole lifecycle.

Whether your design is relatively constrained, or open to end users contributing their own information or even mashing up your data their own way, there's a designed layer at some level. The way you do this will directly influence the ease of use, the clarity of purpose behind the product and will help define the experience your interactive product offers customers.

This, like your interaction and more than anything shiny painted on top, will express the brand of your product. Letting information architecture be built, but not designed, or not addressing user needs is a great way to assure failure.