Site architecture is not navigation

Most small businesses confuse site architecture with site navigation. The two are different things. Confusing them produces sites where the navigation is doing a job the architecture should have done.

Site architecture is the underlying structure of the content. What the site contains, how the parts relate to each other, how a piece of content fits into the whole. It exists whether or not the visitor ever sees it.

Site navigation is the surface affordance the user interacts with to move between parts of the architecture. Menus, breadcrumbs, links between related content, search, and the back button. It is one of several possible expressions of the architecture, not the architecture itself.

The mistake most small-business websites make is to design the navigation first. The team draws a top bar, decides on five or six items, and works out which content fits behind each item. The architecture is, in effect, designed to fit the navigation. The result is sites where the most-visited pages are buried because they did not fit a top-level slot, and where pages that should have been related to each other are not, because they ended up in different sections of the menu.

The right order, in my experience.

Start with the content. List every piece of content the site is going to contain. Not the pages. The pieces. A blog post is a piece. A product description is a piece. The “About” copy is a piece. The privacy policy is a piece. The list, on most small-business sites, is somewhere between thirty and a hundred items.

Group the content by the user task it serves. “I am evaluating whether to buy this.” “I am buying this.” “I have bought this and need to use it.” “I am looking for a job here.” Each group is a different mental task. The site architecture should reflect the tasks, not the company’s internal department structure.

Decide how each group is reached. Sometimes the answer is a top-level menu item. Sometimes it is a footer link. Sometimes it is a contextual link from a different page. Sometimes it is search. Most small-business sites assume the answer is “top-level menu item” for almost everything, which is why their menus are too long and their navigation is too noisy.

Test the architecture before designing the navigation. The cleanest test is a card sort. Print each piece of content on a card, ask three or four people in the audience to group the cards, and see whether the groupings agree. If they do not, the architecture needs more work. OptimalSort is the tool I use for this when the team cannot meet in person.

Two books on this that have shaped how I think about it.

Information Architecture for the Web and Beyond by Rosenfeld, Morville, and Arango. The fourth edition is the current one. It is the closest thing the field has to a community standard, and it is comprehensive in a way the design press never gets to.

How to Make Sense of Any Mess by Abby Covert. Shorter, more accessible, and more practical for small projects. Worth reading twice.

The single most useful question, when the navigation feels wrong, is to stop asking how to fix the navigation and ask whether the architecture underneath is right. The answer, more often than not, is no.