Even real-life menus come with constraints. Photo by Nathan Dumlao on Unsplash

Four Tradeoffs When Designing Navigation Menus

To be an information architect is to immerse oneself in tradeoffs: sacrificing one approach or direction for another. When we choose to focus on nouns instead of verbs, or breadth instead of depth, or expert users instead of novice users, we’re making a tradeoff. We’re accepting (deliberately or not) the risk of going one way and not the other.

I’ve started inventorying the range of tradeoffs we make when designing the main navigation menu. The tradeoffs are most clearly in focus here because they orient users about what’s here and what’s available. The best menus also guide users, clarify the purpose of the product, and distinguish it from similar products. But no menu can do everything. Enter the tradeoffs.

Like any design tool, the tradeoffs do not tell us the right answer. They are, instead, thought experiments, asking us to consider, “What if you focused on this aspect of the structure instead of that?” To answer “why not both?” is tempting, but not in the spirit of the tool. In a tradeoff, you select one direction to explore the consequences of such a decision: not only what you gain but what you must give up.

Every tradeoff is a question that presents a dichotomy, a choice between two seemingly opposing options. Each option sets a direction for the menu, establishing a principle that guides the design and content of the menu. The question is meant to spur debate or discussion — first about how it applies to your particular product or domain, and second about what direction to go in.

To give you a taste of where I’m at, here are four tradeoffs that crop up again and again, regardless of the project, domain, or product.

A note about the examples: The examples provided were not designed by me, so I’m interpreting (speculating, really) the decisions made. The tradeoffs are decision-making tools, not tools to evaluate an existing product, and unless we were part of the process, we have no means to understand the range of constraints, parameters, and inputs into the design.

Should the menu convey breadth or depth?

Show all topics to demonstrate the breadth of the structure
OR
Show the depth of a few key topics

You may be excited to reveal your product’s underlying structure in all its glory — after all the blood, sweat, and tears that went into it. Emphasizing breadth means showing the full range of categories without revealing the layers below. Emphasizing depth means showing only a few top-level categories and dedicating pixels to spelling out the lower levels.

When showing breadth, the challenge is to determine the right order and approach for showing many categories that are on par with each other. If you choose to show depth, beyond selecting which categories to include, you also must determine the most effective way of conveying the hierarchy.

Amazon.com shows us what happens when you aim to convey both breadth and depth. I stretched the browser window across two screens to reveal everything in the top nav. Remember when they just sold books?

This tradeoff is an example of Equitable vs. Biased, a type of tradeoff that asks designers to treat every aspect of the structure the same (breadth) or to be selective about what’s emphasized (depth). Another tradeoff in this vein is “Are all items given the same weight?” That is, using the same style treatment across all items, or visually distinguishing some of the items.

How does the navigation support users with different levels of familiarity?

Provide orientation for new users
OR
Provide easy access for frequent users

A long-time principle of designing digital products is that you can’t be all things to all people. Perhaps you, too, have had to encourage stakeholders to prioritize some user needs over others. One clear dichotomy is users who are familiar with the product and those who are not. Emphasize one and you might alienate the other.

Focusing on new users might entail highlighting introductory or orientation content, or surfacing features that help them onboard. Making such a choice about the navigation means finding other places to serve the needs of frequent users.

At first blush, Motley Fool’s navigation seems to prioritize new users, even folks new to investing. Leading with “Our Services” signals they want to educate potential customers about what they do.

This seems to be an example of Whole vs. Parts tradeoff (though I’m still considering it). That is, choosing between showing the essential parts instead of showing the whole thing. For new users, we want to show the whole thing, even if its perspective is skewed to orientation. For experienced users, we need to provide access to the whole app, but the menu provides access to key functions.

What purpose does this menu serve?

Adhere to a single purpose, like orienting the user about the range of offerings
OR
Address several different purposes, like orienting users, promoting new content, and providing access to accounts

One design principle I lean on is that a given menu should have a singular purpose. This principle helps design teams keep the product’s menu focused, avoiding turning it into a “junk drawer” of features and functions. This requires defining that purpose — providing access to the core features, managing the user’s account, explaining the structure of the product, etc.

While in theory it’s best to avoid using a menu to serve multiple purposes, it’s sometimes unavoidable. This tradeoff calls attention to the fact that designing without intention leads to confusion later on — like not knowing where and how to add new content to the structure.

IMDB, perhaps my favorite site on the web, has a main menu that feels like a hodge-podge of features, barely organized. I sense this menu’s main purpose is to convey everything that IMDB does, but may also serve entertainment industry pros who aren’t searching for a movie or TV show.

This tradeoff is an example of One vs. Many. Another example of this kind of tradeoff is “How does the menu explain the category?” Designers might choose to add descriptions to each item in a category, providing clarity on the entire category. They might choose to include an single over-arching description of the category itself adjacent to the items in the category.

How does the menu invite users to participate?

Highlight what actions users can take
OR
Reveal the composition of the product

Menus on digital products don’t simply have to describe everything on offer — at least not in such an explicit way. A menu can draw users in by presenting tempting offerings — showing the interesting elements that make up the product. (The IMDB example above seems to go in this direction.) Another approach is to indicate what someone can do within this product.

Lego divides their online presence into two sites. Their ecommerce site keeps the navigation concise, inviting participation with three simple verbs. No doubt they know that you’re mostly likely there to buy (or at least look around the store). This menu focuses on the actions.

By contrast, Lego’s entertainment site — seemingly targeted at kids — reveals the “composition” of their product line. No actions in this menu. Instead, we see content types (games, videos) and topics (the themes of the toys).

While it might seem like this is a verbs vs. nouns trade-off, I’ve avoided that characterization because it’s not precise enough. Instead, I see this tradeoff as an example of What vs. How. In these tradeoffs the menu can either focus on explaining what something is — by describing its parts or what’s on offer or the information space — or presenting how it works — emphasizing processes, actions, or tasks. Another example of this tradeoff is comparing outcomes (what you can accomplish) with features (how you accomplish those outcomes).

I’m still in the early stages of collecting and documenting the tradeoffs. There are more than 30 tradeoff questions in my initial list. Whether that list will grow or shrink only time (and a good editor) will tell. I’m more interested in getting the framing right for each tradeoff, so it can stand on its own and still be meaningful to a wide range of IA practices.

If you don’t mind a peek behind the curtain, you can see the rest of the tradeoffs in this Google Sheet, a working document where I’m ironing out the structure and content.

A snapshot of my working document where I’m developing the structure and content for the tradeoffs.

You may be familiar with another tool I developed — the Information Architecture Lenses. The lenses are perspectives, standpoints from which to evaluate and consider the design choices you made. They compel questioning a concept to hone it, refine it, and clarify it. By contrast the tradeoffs offer starting points, broad sweeping decisions about the direction of the navigation menu. Will you go left or right, up or down? Broad vs. deep? Nouns vs. verbs?

These broad decisions were simple in the early days of designing navigation: But now, not so much.

The growth of the practice, the complexity of our products, and additional perspective, all demand that we look at our decisions — these tradeoffs — with greater nuance.