A toolkit of a few basic patterns (or models) that describe solutions to common IA problems.
One or more of these patterns will naturally apply to many information architecture problems.
These may serve as off-the-peg solutions, or as helpful descriptive shortcuts during the design process.
All-in-one
This is the simplest possible model. Everything goes on a single Home page.
It’s interesting to see many more sites using this approach, to simplify the experience and to reduce maintenance.
(I recommend this structure in the Bytecon case study)
Flat
A flat pattern is where all pages are arranged as peers, and every one is accessible from every other one. This is very common for simple sites, where there are a few standard topics, such as: Home, About Us, Contact Us, Products.
This may also be called a ‘monocline grouping’.
Index
An index structure is like the flat structure, with an additional list of contents.
An index is often organised in some way, to make stuff easier to find. For example, a list of files in a web directory (the index page), or could be an index of people’s names ordered by last name.
Dictionaries and phone books are both giant indexes. Look at the corners of the pages, where the data ‘index’ is: it may be the first few letters of the word, or a marker that shows the alphabetical range on the page.
Indexes work well when there is a medium amount of data, and also when that data can be ordered in a way that makes it easier to scan to what you want.
How many items can an effective index contain?
Quite a lot. Would it be quicker to use a search engine or a phone book to find a particular number? I’d guess that if the search engine works well, it would probably be a little bit quicker, but the phone book doesn’t do a bad job. For a clear difference, you’d need a large amount of data, such as a multi-volume encyclopaedia, where you would find alternative mechanisms more useful.
Hub-and-spoke (or daisy) pattern
This model is useful for multiple, distinct linear workflows. A good example may be an email application, where you will return to your inbox at several points, e.g. after reading a message, after sending a message, or after adding a new contact.
Sometimes, I find the term ‘daisy model’ more helpful, for architectures that use a number of transactions that share a common start/end point. The transaction loops can look like petals on a flower.
Strict hierarchy
A strict hierarchy describes a system where you can only access a lower-level page via its parent.
This could apply to a real-world model where there is a strict parent-child relationship between objects, such as arranging pages for company offices by their country. An office cannot be in more than one country.
Many data models also have strict parent-child relationships, such as Message boards, Threads and Posts. Every thread belongs to one message board; a message board can have many (child) threads. Each thread can have one or more subsequent (child) posts.
The important thing to remember about this is that, even if there’s a strictly hierarchical real-world model, that doesn’t mean that a strict hierarchy is the best way to represent it online. You should consider your users’ goals and contexts of use. For example, while it’s possible to arrange all your products by product category, that might not be the most intuitive way for a user to find it. Supermarkets often place the same items in more than one place, knowing that consumers will think about them and look for them under more than one category.
Multi-dimensional hierarchy
A multi-dimensional hierarchy is where there are many ways of browsing to the same content. In a way, several hierarchies co-exist, overlaid on the same content. The structure of the content can appear to be different, depending on the mode you’re looking in.
A typical example is a site like Amazon, which lets you browse books by genre, or by title, and also lets you search by keyword. Each of these hierarchies corresponds to a property of the content, each of which can be useful for people in different situations.
Search
Many users and sites rely on the ability to use it to get to content quickly. While it’s strictly more a navigation tool than an architecture, a search tool is often built in to a site’s architecture, like an elevator is built in to the architecture of a building.
Search functions present a dynamic view of a set of content, and offer instant links to each result. This allows users to jump straight to content, without having to browse through hierarchies or indexes.
When search works well, it can be a huge benfit. Generally, the more content there is, the more value search can offer.
One or more of these patterns will naturally apply to many information architecture problems.
These may serve as off-the-peg solutions, or as helpful descriptive shortcuts during the design process.
All-in-one
This is the simplest possible model. Everything goes on a single Home page.
It’s interesting to see many more sites using this approach, to simplify the experience and to reduce maintenance.
(I recommend this structure in the Bytecon case study)
Flat
A flat pattern is where all pages are arranged as peers, and every one is accessible from every other one. This is very common for simple sites, where there are a few standard topics, such as: Home, About Us, Contact Us, Products.
This may also be called a ‘monocline grouping’.
Index
An index structure is like the flat structure, with an additional list of contents.
An index is often organised in some way, to make stuff easier to find. For example, a list of files in a web directory (the index page), or could be an index of people’s names ordered by last name.
Dictionaries and phone books are both giant indexes. Look at the corners of the pages, where the data ‘index’ is: it may be the first few letters of the word, or a marker that shows the alphabetical range on the page.
Indexes work well when there is a medium amount of data, and also when that data can be ordered in a way that makes it easier to scan to what you want.
How many items can an effective index contain?
Quite a lot. Would it be quicker to use a search engine or a phone book to find a particular number? I’d guess that if the search engine works well, it would probably be a little bit quicker, but the phone book doesn’t do a bad job. For a clear difference, you’d need a large amount of data, such as a multi-volume encyclopaedia, where you would find alternative mechanisms more useful.
Hub-and-spoke (or daisy) pattern
This model is useful for multiple, distinct linear workflows. A good example may be an email application, where you will return to your inbox at several points, e.g. after reading a message, after sending a message, or after adding a new contact.
Sometimes, I find the term ‘daisy model’ more helpful, for architectures that use a number of transactions that share a common start/end point. The transaction loops can look like petals on a flower.
Strict hierarchy
A strict hierarchy describes a system where you can only access a lower-level page via its parent.
This could apply to a real-world model where there is a strict parent-child relationship between objects, such as arranging pages for company offices by their country. An office cannot be in more than one country.
Many data models also have strict parent-child relationships, such as Message boards, Threads and Posts. Every thread belongs to one message board; a message board can have many (child) threads. Each thread can have one or more subsequent (child) posts.
The important thing to remember about this is that, even if there’s a strictly hierarchical real-world model, that doesn’t mean that a strict hierarchy is the best way to represent it online. You should consider your users’ goals and contexts of use. For example, while it’s possible to arrange all your products by product category, that might not be the most intuitive way for a user to find it. Supermarkets often place the same items in more than one place, knowing that consumers will think about them and look for them under more than one category.
Multi-dimensional hierarchy
A multi-dimensional hierarchy is where there are many ways of browsing to the same content. In a way, several hierarchies co-exist, overlaid on the same content. The structure of the content can appear to be different, depending on the mode you’re looking in.
A typical example is a site like Amazon, which lets you browse books by genre, or by title, and also lets you search by keyword. Each of these hierarchies corresponds to a property of the content, each of which can be useful for people in different situations.
Search
Many users and sites rely on the ability to use it to get to content quickly. While it’s strictly more a navigation tool than an architecture, a search tool is often built in to a site’s architecture, like an elevator is built in to the architecture of a building.
Search functions present a dynamic view of a set of content, and offer instant links to each result. This allows users to jump straight to content, without having to browse through hierarchies or indexes.
When search works well, it can be a huge benfit. Generally, the more content there is, the more value search can offer.