What is the purpose of a navigation sidebar menu and why is it worth thinking about? If you're on a docs site, it probably has a left nav. Things that are everywhere tend not to be considered very much.
I think a nav menu serves two fundamental purposes:
- Help readers find the information they're looking for
- Give readers insight into the conceptual model of a body of knowledge (in our case, a conceptual model of New Relic)
Find information
When I imagine someone finding information, I find that my initial impulse is to picture someone moving in a straight line from question to answer. I feel this impulse, even though I know it to be false!
When human beings move through collections of information—whether it's a docs site, a bookstore, or a temporary collection of information created from an internet search—they do so in a meandering, inefficient, and emotionally impulsive way. Although this process is inefficient, it's the primary way that human beings build conceptual models of understanding!
The ground-breaking library scientist, Marcia Bates, described this organic process of information gathering as berrypicking. In her model, browsing is what people do when they're trying to make sense of a poorly understood body of knowledge.
As I see it, the left nav menu is primarily a tool for browsing.
Conceptual model
When our conceptual model of New Relic is confusing to us, our nav is going to reflect that. This does a disservice both to our readers and ourselves.
When we look at the nav and are confused by how its organized, this is a fundamentally useful clue to us (the docs team) that we need to work on our conceptual model.
As a reader browses through our nav, are they picking up on key terms? Are they starting to get a sense of the shape of New Relic as a system? Are they able to build enough of a mental model to take action in a meaningful way?
Here are some quick ways that you can improve any part of the nav that you're looking at:
- Move one or two of the most important docs to the top of the nav section so that people can see them without expanding any more of the nav.
- Scan the categories in the section of the nav. Can you tell at a glance what docs are in each of those categories? If not, rewrite them so that the clearly describe what's in them. This might involve removing jargon or other New Relic-specific terms.
- Human beings tend to only be able to think about 5-7 separate things at a time. Does your nav category have more than seven sub-categories or docs? That might be a clue that you need to rethink the organization of your nav.
Search and the nav
There's one thing that browsing in a nav is profoundly unsuited for: finding a specific piece of content in a body of knowledge. No matter how much we fine-tune and improve the navigation information architecture, we'll never get it to place where someone can use it to find a single, specific doc on our site. Using the nav to find a specific doc is a bit like using a map of the United States to navigate to a small town in eastern Oregon.
Search, on the other hand, is an excellent tool for navigating to a specific doc if you know what search terms to use. We can use our nav to surface important keywords that someone can use to search for specific docs content.
For example, in our nav we have Kubernetes and Pixie. If our nav had Pixie by itself, it would only be useful to people who already know what Pixie is and that it's something you use with Kubernetes. By tying Pixie and Kubernetes together, we can help people formulate more useful search terms into our docs site.
Best practices
Given all of the above, here are some initial high-level nav best practices, represented as a series of questions about the nav:
- Does the nav give me clear direction on where I should start reading?
- Look at the nav, can I tell which docs are most important?
- How many clicks in the nav do I need to do before I get a clear call to action?
- Does the nav introduce me to important keywords I need to know? (Are there any important keywords that are missing?)
- Does the nav show a clear progression or user journey I might follow to success?