Introduction to hierarchy of information

A hierarchy of information means that a bunch of related bits of information have been assembled into a structure that reflects what they all have in common. We put information into hierarchies in order to make a large message more likely to be completely received and understood. A UX Designer should be able to articulate and employ the principles of hierarchy in their designs to increase the likelihood of their designs being usable and enjoyable.

Terminology

In this post, I refer to a message as a grouping of individual pieces of information that have something in common. A large message often contains several smaller messages. The conclusion represents whatever idea, plan, outcome, etc. that the message sender wants the recipient to experience. Examples of the difference between a message and information:

  • A blog post is a message that contains several points of information on the same topic. The conclusion is usually the topic of the post.
  • A mobile application is a message that sends and receives information to and from a user in order to let the user complete a task. The outcome of the task is the conclusion of the message.
  • An informational website is a message that contains information a user needs to make a decision, which represents the conclusion.
  • A formal academic paper is a message that gathers up information that the author has assembled in order to prove a conclusion.
  • A prescription bottle is a message that contains several pieces of information regarding how to safely consume a poison that does something useful when not taken too much. The conclusion is that the recipient takes the medicine, feels better, and doesn't die.
  • A TV show is a message that contains several pieces of information about something that has either actually happened or that the author wants you to suppose has happened. The conclusion can vary depending on if it's fiction, non-fiction, allegory, call to action, telethon, etc.
  • A UX designer must create documentation so the developers know how the UX should look and behave. It's a message that contains many pieces of information of many different kinds. The conclusion is the successful release of the product.
  • The lights on the back of a car are one message that is made of separate pieces of information about what that car is doing or will do next. The conclusion is that the other cars don't wind up in the same place at the same time, because that's usually painful and costly.

Purpose of hierarchy

One way that makes it easier for a person to understand something new is by comparing it to something they already know. This goes for the structure of the content as well as it applies to what is actually said in the content. If everyone agrees on one way to create an information hierarchy, then when we present our large new message using that format, we are giving the recipient something to compare the new message to, to help them understand it.

It's the same principle by which we structure information so that computers can understand it.

When we create a hierarchy, we're helping the recipient of the message understand what all the little bits of information have in common with each other. Because ultimately, that's probably what we want them to understand the most about the message. It's easy to just say a lot of stuff, but making a larger point about what a lot of different things have in common is much harder and more valuable. So it's really important to get the structure right if we want our message to be truly understood by the recipient. Using standardized rules for organizing information into a hierarchy is one method that should be employed, among many others.

If the recipient can't recognize the hierarchy of the information because it doesn't look like any hierarchy they've ever seen, it can have one or more of the following effects:

  • they could have a poor impression of the sender of the message
  • they can be too distracted by trying to make sense of something that will never make sense to be able to focus on the actual information
  • they can draw an unintended conclusion from the message
  • they can give up trying to draw a conclusion from the message

No matter which effect, the intended outcome of the message is never realized.

Therefore it's critical that anyone who designs messages in order to drive conclusions understands and applies the rules of effective hierarchy of information.

Elements of a user experience that need strong hierarchy

  1. Navigation - both in how it's presented and how it's structured
  2. Arrangement of elements on the screen
  3. Content and copy
  4. Task flows

Cultural expectations of hierarchy

Not all cultures have the same rules or expectations around how information is structured. This blog post is only referring to English language-based audiences. I think that this goes for other Romance languages and I wouldn't be surprised if it were more broadly applicable, but I don't have enough experience to say for sure. I just want to acknowledge that because I know that UX design practices in other parts of the world vary greatly but still create experiences that work for the audience in question.

Rules for outlining applied to structuring a useful hierarchy within a user experience

"Outlining" is usually presented in school as an academic exercise to help a writer structure their ideas before expounding on them. But the rules of "outlining" are essentially general instructions for creating a predictable and orderly hierarchy of information of all kinds. As I mentioned above, I first learned these rules in high school and I have found them to be of critical importance in every job I've had as an adult, and especially as a UX designer. In fact it could be that my interest in UX can be traced back to this introduction to putting disparate information into a useful form.

For this section, I am referencing Purdue University's website for writing tips. Most universities and many other websites present the same information in different ways, but I went with this one because I like it the best. It's just a great resource in general that I've been referencing since I was a writing tutor in college.

In this section I will present the rules for outlining as defined by Purdue with some annotations relating them to UX and the ideas expressed above. These are the same rules I was originally taught, which I would present directly if I still had those old notebooks.

Knowing the rules

As defined by Purdue, and agreed with by me, here are the elements of a proper hierarchy. Any hierarchy can be compared to these rules in order to evaluate or improve it. When I design or evaluate a user experience, I stick with these rules.

The goal of employing these rules is to know how to create one message that's made of several interlocking and related messages, so that the user understands how each of the messages corresponds to each other, so that they can draw an accurate conclusion.

Parallelism

Each heading and subheading should preserve parallel structure. If the first heading is a verb, the second heading should be a verb.

The first time a user opens an app or a website, they're trying to figure out what they can do and how to get it done. They skim the headings and labels and without really thinking about it, automatically organize what they find into their own mental model. If we want that mental model to be accurate, then the headings and labels must be predictable and provide information that takes no effort to commit to memory.

The Purdue website gives this list as a good example:

  1. Choose desired colleges
  2. Prepare application

Imagine these as buttons inside an app. As a user, I now have a clear and accurate understanding of what I can do.

If it was like:

  1. Learn about colleges
  2. My colleges

"My colleges" might be an accurate heading for a list of applications I've already made, but in this context I can't create a mental model of how these two items relate to each other because that information wasn't relayed by the structure.

Coordination

All the information contained in Heading 1 should have the same significance as the information contained in Heading 2. The same goes for the subheadings (which should be less significant than the headings)

This just means that the headings should be coordinated with each other so that they're all presenting the same information in the same way.

(In this text, they are using "heading 1" and "heading 2" to refer to "The first heading" and "the second heading", not subheadings.)

As a UX guideline I would rephrase it as:

If we assign some information to a certain heading level, it should be at the same level of importance as other information assigned to the same level.

As a user, when I'm automatically assembling the information being presented into my own mental model, I need to know what information is more important and what information is less important. I infer this from the size of the information. Bigger stuff is more important than smaller stuff. Therefore as a designers, we must be sure that the information that we present as being the same size is actually of the same importance. This helps users form the understanding that we want them to form.

In the UX design process, it's really important that we don't break this rule to promote a piece of content that we think should be more prominent. The best way to do that is to evaluate the whole structure and find a way to make it make sense for that item to be higher up.

Subordination

The information in the headings should be more general, while the information in the subheadings should be more specific.

This means that everything that sits under a certain heading must be a specific piece of information that can be summarized by the heading.

Following this guideline helps support several established UX best practices, such as:

  1. Matching user's expectation: The user is assembling their own understanding of what's going on as they skim the interface. They're expecting that headings are general and subheadings and text gets more specific as it flows down and out, because that's how most things work.
  2. Accuracy: Elements that are in proximity to something that looks like a heading must really be a child of that heading or else we're providing inaccurate or misleading information. Even if it's just a coincidence that those two things look related. A user has no way of knowing what you intended other than what they can see.

Division

Each heading should be divided into 2 or more parts.

This means that something isn't really a parent unless it has children, and if something isn't a parent, we shouldn't suggest that it is through the formatting.

For example, I can put a level 4 heading anywhere I want, but it doesn't really belong there unless it has a reason. The reason is that it's describing everything below it. If there's nothing below it, it's not describing anything, therefore it's not serving any purpose.

When you think something should be a heading but it has no children, you can use that as a jumping-off point to help you know what changes to make to improve your structure. Try saying something like this: "It's supposed to have children but it doesn't, therefore I should either move it into a a different section, or make sure nothing is missing."

This is a level 4 heading that has no children. If it has no children, why am I equating it with the other headings that do have children? If I'm breaking the rules that you have been using the form a mental model, can you now trust that mental model? I'm really just wasting your time by calling attention to something without providing anything in return.

Applying the rules

How do I go from a big pile of information bits to something organized and easy to understand? These are some tips offered by Purdue.

Starting with a blank page

Purdue describes the first steps of creating an outline as:

  1. Determine the purpose of your paper.
  2. Determine the audience you are writing for.
  3. Develop the thesis of your paper.

It's extremely true that we must first determine the purpose of our message/user experience before doing anything. In UX, that means clearly defining the tasks that will be carried out by the user in concert with the software.

Then, who is the user? What are their expectations?

As I wrote earlier, the "thesis" of a paper is its conclusion. The "conclusion" of a user experience is the intended outcome of the experience. It's really important to have a crystal clear understanding of the intended outcome before doing anything.

It's also really important not to treat the purpose and the conclusion as the same thing. Imagine there are two apps that both have the same purpose: to let users graphically move elements around a screen to knock pigs off of structures.

But they could have radically different outcomes:

  1. Nothing in the real world has changed, but the user feels a sense of accomplishment.
  2. Some real-world pigs have been knocked out of real world structures using the instructions sent from the app. I hope that was your intended outcome!

This is why it's really important that both of these are separately defined!

Using the rules to find the structure

Once your purpose and conclusion have been decided, Purdue recommends these steps to create an outline:

  1. Brainstorm: List all the ideas that you want to include in your paper.
  2. Organize: Group related ideas together.
  3. Order: Arrange material in subsections from general to specific or from abstract to concrete.
  4. Label: Create main and sub headings.

These are the same steps we should take to organize a user experience into a useful structure: 

  1. Brainstorm: List all the information we need to gather from the user and present back to them
  2. Organize: Group related ideas together.
  3. Order: Arrange material in subsections from general to specific or from abstract to concrete.
  4. Label: Create main and sub headings.

Using the rules to diagnose

Employing the rules during the design process is important, but they can also be used to determine why something "feels wrong" or "off" in an existing design. That's because when something "feels" wrong, it's because our internal processing engine is trying to follow the rules and is letting us know that something isn't working. If we know the rules, then we can better articulate what isn't working in order to fix it.

Things to look for:

Something feels too small or unimportant

When your gut says this piece of information is more important than how it looks in the design, check to make sure the heading has appropriate siblings. This happened to me when I was writing this post. I noticed that I was violating the rule of division, and I had a heading that didn't have any siblings. When I bumped up the heading, it still worked within the structure and didn't look weird anymore.

If it doesn't work within the structure when you bump it up a level, look at the whole structure. Where is this thing's real parent? Should it in fact be the parent? The structure can and should evolve as you spend more time with it.

Test users and stakeholders report confusion

Check the headings and see if they tell their own story accurately. If I only look at the outlines, am I getting an accurate snapshot of the content? Are the headings, buttons, and other elements placed in relation to each other in a way that accurately reflects how the user should think about them? There could be some other reason, like maybe the content itself isn't right, but this is a good starting point.

Navigation feels "cluttered" and "not quite right"

It happens to me sometimes, most recently while putting this site together, that I have put some stuff in the nav but it doesn't "feel" right.

First look at the actual content that the navigation reflects. Check the rules of coordination and parallelism and compare those rules to the way things are distributed across each of the screens - is there coordination between the screens? Are the screens titled in a way that's parallel to each other?

Then check the outline being formed by the navigation itself. For example, when putting together my site, I originally had these elements in the subnav:

  • Home
  • My Work
  • Siri Shortcuts
  • LinkedIn

It just didn't "feel right" to me, so I moved through each of the rules described above to find the problem. This isn't like an algorithm where I move through each of the rules line by line, because I have internalized these rules. Instead it was a process of carefully thinking about my observations, using the rules in an unconscious way. These were the steps:

  1. One of these things is not like the other. "LinkedIn" is just a link to an external site so it wouldn't be correct to have it sit next to the others. That would create the incorrect impression that they all behave the same way, when they don't.
  2. So, I decided to put the LinkedIn link just on my home page.
  3. Then I made a button for the RSS feed of my site, which I determined also didn't "feel right" being presented as siblings to the other navigation items. So I stuck it on the home page too.
  4. Now I had two buttons, which meant I had a list, which meant that it needed a heading. So I thought about what they both had in common, which were that they were both methods for keeping in touch with me. So I gave them the heading "Keep in touch".
  5. Then I realized that now that they had a heading, I could put them in the side nav.
  6. THEN I realized that this might be an appropriate place to use this cool font I found that felt overwhelming and pretentious everywhere else I tried to use it.
  7. Then I realized I had a heading that said "Keep in touch", which implies being able to contact me, but I wasn't providing a method to actually do that directly, so I created my email form page.
  8. Now I had fulfilled all the rules of an outline in my navigation: The items were coordinated with each other, parallel with their siblings, and each group of siblings was appropriately divided and sat under an appropriate headline.
The rules are getting in my way and not letting me do something I want to do

There are some situations where the structure is apparent enough without strictly following the rules of size as long as there are still enough indications of what's related to what, using proximity, similarity, etc.

Conclusion

I hope that through reading this blog post, you have learned how important hierarchy and structure is to creating good user experiences, or if you already knew that, you have gained some specific insight into how broadly applicable the same set of rules can be. And I hope you also learned a little something about me and how I work. Thanks for reading!