Many websites are primarily organised around a hierarchical tree structure. Creating these structures is one of the activities described as information architecture, and some would refer to this tree as the information architecture of a website.
I worked on a few of these tree structures for a range of clients. I felt like I had a fairly good intuition for it, and had picked up a few rule of thumb conventions from the IA world.
But I had a problem.
Tree structures like this are always subjective to a degree; no one will ever interpret them exactly the same way. But conversations with clients, stakeholders and team members about the right labels to use and where to put things always felt unnecessarily difficult. Things could unravel quickly, and discussions often veered off into preference and opinion. I had often chosen labels and categories strategically, but struggled to clearly articulate the rationale for those decisions. User research could be cited to back up a decision, but not everything can be researched thoroughly enough to do that.
Sometimes people went with my recommendation. Sometimes we compromised. Sometimes we went around in circles until all the words started to seem meaningless and we just moved on. But every time I would come away wondering why there wasn't a better way to do this.
I went back through my IA books and tried looking through new ones. I looked for video tutorials and blogs from trustworthy sources. But, curiously, I couldn't seem to find any framework for evaluating a tree structure that wasn't either too superficial, or far too general.
So, I decided to suggest one myself.*
After wracking my brains to identify and describe what I thought were the concepts that make of break a tree structure, I settled on a list of properties.
Some of the properties apply to the whole structure. Others apply to individual labels, and others to a set of sibling elements in the tree. But they all apply in situations with multi-level structures, and they are influencing the way people use and understand them.
These properties are:
- Exclusivity
- Exhaustiveness
- Scope exposure
- Hospitality
- Robustness
- Syntactical equivalence
- Balance
- Scope distribution
Most of these aren't concepts I've invented; many were things picked up from various sources, though I hadn't seen them written together like this (and I'd never seen anyone describe what I observed as 'scope distribution').
In the rest of this post, I'll describe each of the properties and suggest ways of testing your structure against them.
Properties 1 and 2: Mutually exclusive, collectively exhaustive
Apply to: Set of categories at same level
Exclusivity: The degree to which the categories make it clear exactly which one a particular item belongs in.
Exhaustiveness: The degree to which the categories provide a place for each item in the set.
If two categories are mutually exclusive, we can guarantee that they share no overlap; they are completely different things. In the context of category names, this means that anything that goes into a category couldn't also be interpreted as belonging in another.
If a set of categories are collectively exhaustive, it means that altogether they cover every possible item that could be placed within them.
These two properties work closely together and are typically used by consultants to structure problems, but happen to work rather well in helping us understand categories and how they relate to each other. Taken together, structures that have both of these attributes are referred to as being 'MECE' (pronounced mee-see).
The most basic way to make a MECE structure is to simply make a category and then an inverse 'everything else' category. For example:
- Financial information
- Non-financial information
In theory, this can be quite clear; there's no overlap, and by defining the second category as a negative of the first, we know the pair of them will always be exhaustive.
Opposites are also a quick way of achieving MECE:
- Revenues
- Costs
But this isn't going to work well for website structures; we want to make it clear what route to travel when searching for something in a hierarchy, but we also need to expose exactly what is available within it (see scope exposure). Having a catch-all 'everything else' category fails at this pretty spectacularly.
Despite it being not great for website structures, quite a lot of them use a sneaky 'everything else' category: the dreaded 'More' button (or when it's feeling really ashamed of itself, the '...' button).
Sometimes these aren't the end of the world if all that's placed in them are rarely-used pages or features. But putting anything that anyone might find important for some reason – even if it's just one person – shouldn't be hidden away in a mystery category like this.
So how do we achieve MECE category sets without these catch-all buckets? I haven't found any hard and fast rules, and suspect it will always depend on the items you need to categorise. But the concept of MECE is a good one to assess your structure against.
One thing to note about the exhaustiveness property is that 'exhaustive' can mean different things in different contexts. Librarians have the unenviable task of trying to map all knowledge, but in some ways this is easier than creating categories for smaller information sets, as these have to somehow convey their limits; i.e. what is NOT in this structure.
Testing exclusivity
Name an item, task, question or piece of information that your structure needs to guide people to. Ask a participant to talk you through their route through the tree revealing levels at appropriate times, and to mention any time where they're uncertain about which categories would be the right ones and why.
Testing exhaustiveness
You should find out fairly quickly if your categories aren't exhaustive when you try to arrange all your items within the structure; if you find yourself shoehorning things in, or a test participant doesn't seem to think any of the categories would be the right one, you know that you haven't created a truly exhaustive structure.
Property 3: Scope exposure
Applies to: Set of categories at same level, Individual labels
The degree to which a set of categories hints at what will and will not be available within them.
A set of categories can provide natural homes for the items within them, but it can also function to set an expectation about what is contained within them. As we just touched on, a mystery 'everything else' category might make it clear where to put something (storage), but doesn't help you know what you might find within it (retrieval); how can you predict what else might be in there? But a good set of categories can help you know what to expect, and aid discovery of information or options that the structure provides.
Testing scope exposure
Show a test participant the top level set of categories you're proposing. After they've reviewed them all, ask them to list out things they expect would sit within each category. Repeat for any lower levels systematically. Pay attention to how they react to seeing the answers. Surprise may not be a bad thing, but consider how and why people might not have expected to see what they did, and what implications that might have for your structure.
Property 4: Hospitality
Applies to: Structure as a whole
The degree to which a group of categories can accommodate new additions being made to it.
This is a concept that I came across in a library science context, and relates to how easy it is to fit new things into the structure in the future.
When it comes to more traditional kinds of cataloguing, such as library systems or mapping the animal kingdom, hospitality can be quite important, as making substantial changes to your system can be incredibly costly or difficult to co-ordinate across many people and institutions.
In the world of the web, we can be more flexible with our structures. If things change dramatically, we can just re-organise or create new structures that run from a single source of truth. But this can still be time-consuming and expensive, as well as disorientating for users. So there needs to be a threshold; a point below which we can accommodate new things into an existing structure, and above which it makes sense to start again.
Where exactly that point sits will vary from one context to another, but it's worth carefully considering future plans. If you're designing for an organisation, what goals do they have in mind for the future? What content or services might they want to incorporate into (or remove from) this structure? Considering this early can help you stress-test your structure and see how it might respond when things are added or removed.
Testing hospitality
Talk to stakeholders about future plans. Imagine how the structure might need to evolve and change in the future – even considering scenarios you might not like. Create speculative versions of the structure that include these new additions (or exclude things that could be removed) and run similar tests on the other properties. See how these changes affect your results.
Property 5: Robustness
Applies to: Structure as a whole
The degree to which a group of categories can adapt to different usage contexts
Closely related to hospitality is robustness; how well the same structure can adapt if it needs to be presented differently in different circumstances. What if the content needs to be translated; do the labels still have the same connotations? How is it affected if a user is signed in, or signed out? Might the structure become personalised to a user based on their membership level, usage patterns or customisations?
Work with your project team to try and anticipate the different possible states and contexts that this structure might need to appear in. Then think about how you'll need to adapt it to them by designing specific presentations for those contexts, and let each new context inform the others if a problem or opportunity to improve presents itself.
Testing robustness
Consider all the ways that this structure might have to adapt depending on who is viewing it and when. List them out and create a plan for how exactly the structure will appear in these different situations. Some examples could be:
- Signed in vs signed out
- Access privileges (e.g. members get additional content)
- Screen size and resolution
- Internationalisation
- Seasonality or time of day
- Statuses and scenarios (e.g. breaking news, flash sales)
Property 6: Syntactical equivalence
Applies to: Set of categories at same level
The way in which a label is framed grammatically.
One of the ways that we can indicate that a set of things belong together is by framing them in a consistent way. Syntax refers to the grammar of a phrase. Each of these are different syntactical options for the same label:
- Moving house
- House moves
- How to move house
Assuming this is referring to a guide to help people move house, any of these labels could work depending on your context. But particularly with labels like these that describe information rather than objects or concepts, it can be easy to fall into a trap of using an inconsistent framing in a set of items. Consider this list:
- Moving house
- How to buy a house
- Mortgage repayments
Reading through these it's fairly clear what they're about, but they don't scan all that well and it's not immediately clear that they all follow a common format or belong together. We can make this clearer by using a consistent syntax for each of them:
- Buying a house
- Moving house
- Repaying your mortgage
In this case, we're clearly implying that these are all helping you do something, because each of them is framed with a verb at the start. The fact that they all follow this format makes a stronger connection between them, and implies that they might all share a similar structure. In this case, we might also want to order them to imply a process; since there's less thought required to make sense of the list, it becomes clearer that they might be related sequentially too.
A commonly derided exhaustiveness hack is to label something based on a specific audience or group of people, such as 'For parents'. I call these 'people categories'. The problem with doing this is that things that are 'for parents' might also be for other people, and parents might also want things that aren't in the 'for parents' section. And I can personally guarantee that no parent has ever opened a website and said to themselves "ah, before I do anything else, I'd better make sure I'm looking in the parents section". That's not how this stuff works.
In my opinion, if you really have to divide things up by people categories, you have to commit to it. Rather than just using them as 'everyone else' categories, make sure you have a MECE list of people categories to choose from. This means that you must be sure that:
- Any given user will understand the labels you're using to describe them and know exactly which group they fall into – there can be no ambiguity
- Nobody that this content is relevant for is left out
- Any information that applies to multiple groups is included in both places
And by 'sure', I don't mean 'the stakeholder said it would be fine'; do plenty of user research to understand your audience.
There aren't many situations that fit this mould, and there's almost always a better way to organise things than by people categories. But if you have to do it, do the hard work to make sure they're appropriate in your situation.
Testing syntactical equivalence
Try to map out the grammatical structure you're using for a particular set of labels. Grab your nearest content designer, copywriter or language expert to get a second opinion if you're not sure.
Property 7: Balance
Applies to: Structure as a whole
The degree to which a tree structure has usable number of levels and items within its categories.
The concept of balance in a website's tree structure is one of the more established ones in IA work. Simply, avoid having trees whose branches are:
- Broad and shallow
- Deep and narrow
Exactly what 'usable' means in your context might vary. There are some rules of thumb out there, for example 5 items at most in top level navigation, no more than 8 siblings in a category and no more than 4 levels in your tree. These are guidelines rather than commandments, but deviating too far from them might unbalance your tree and could be a clue that your structure needs a rethink.
Testing balance
Create a diagram of your tree. Look for areas that are substantially larger or smaller than others; consider whether they can be split out or incorporated elsewhere.
If you feel like you're pushing the boundaries of one of the rules of thumb or your structure isn't as balanced as you'd like, consider running some usability tests, either on the abstracted structure (e.g. with tree testing), or with a low-fidelity prototype of the navigation system in context (e.g. wireframes). Make note of any difficulties people have and see if they give hints about alternatives you could try.
Property 8: Scope distribution
Applies to: Set of categories at same level
The way that the relationships between categories affect the boundaries between them.
This last one is a bit different. All the others up to now have been properties that can be approximately expressed on a spectrum. This one is a bit more complex, but I think it's still a concept that works with the others.
While a category label has properties in isolation, our perception of what it includes can change dramatically depending on the alternatives it is presented with. A ‘set’ of categories can therefore have properties that are unique to that specific combination, such that any changes to it would also change how users perceive the individual categories.
We can think of this as scope distribution; 'scope' being the boundaries of what a category includes, and 'distribution' referring to how the included elements are split across the individual categories in a set.
This is a bit tricky to explain, so perhaps an example can help.
Example – Laundry piles
The easiest way to understand this is taking a category set where each category represents a point on an spectrum.
To begin with, imagine a set of two categories, one called 'Lights' and another called 'Darks', and that these represent piles of clothes to go in a washing machine.
Lights | Darks
Think of a few items in your wardrobe and ask yourself which of the two categories you would place each item into.
Now imagine that someone adds a category called 'whites'. It's likely that there are a few items that you previously would have put in the 'lights' pile that now make more sense in the 'whites' pile.
Whites | Lights | Darks
This seems obvious, but something interesting and subtle has happened. The category 'Lights' has not changed its label in any way. And yet our definition of its scope has changed; things which fit into the category before now, for some reason, don't. All we did was add something to the group of categories, and the perception of the label changed.
We can keep going. Imagine we add another category to the set called 'Colours'. How would this affect things? What scope areas of the other three categories have been taken over by this new category? If you're like me, you'd move some of the brighter colours from the 'Lights' and 'Darks' category into this new category, but probably none from the 'Whites'. This time, the scope of two of our categories has changed, one for a second time, without us ever adjusting the names of either of them.
Whites | Lights | Colours | Darks
As you can see, 'just adding another category' is not a matter of simple addition; it can fundamentally change the way each individual category is perceived.
Testing scope distribution
This would be handled by a tree test, asking people to identify the place in a tree that they would expect to find the item in. Again, this can inform you of any overlaps between categories (exclusivity) if they have a hard time choosing one or the other.
I find this list helpful for evaluating site structures. It may not be possible (or desirable) to achieve perfection on each point, but it's really useful to make deliberate decisions about your tolerance for each property; you might be working on a structure where one of the properties matters less than usual. So it's not a scorecard, but a way of understanding and justifying your decisions. I hope you find it useful too.
If you want something more far-reaching I recommend Dan Brown's IA lenses; these were a bit too broad for my specific problem but are an excellent way of discussing and evaluating information architectures more generally.
I expect this to evolve over time, and I'd love to hear from you if you have thoughts about how to improve it.
* I did genuinely compile this list myself. However, deep in the literature, I eventually found a framework that was remarkably similar, from Patrick Lambe's book Organising Knowledge. His book is focused on taxonomies in general rather than web navigation systems exclusively, and his list is framed as qualities (binary) rather than properties (spectrums). And there was still no concept of scope distribution. So I stuck with my list, but he's an actual qualified taxonomist who knows what he's talking about, so here are the two to compare. See which one you prefer, and check out his book - it's really good.
