Should you group nav items by what they are or by what the user wants to do?

Group navigation by what users want to do, not by what your internal categories call things, because people navigate toward goals rather than around an org chart. Task-led grouping should be the default, and category-led grouping is the exception you reach for only when the audience genuinely thinks in those categories. The deciding factor is the user’s mental model, the labels and structure already in their head, and good navigation matches that model instead of mirroring how the company happens to be organized.

People arrive at a site with an intention, not an awareness of your departments. They want to “track an order,” “get help,” “see pricing,” or “start a free trial,” and they scan the navigation for words that match that intention. When the menu is built around user goals, those scans land instantly. When it is built around internal structure, the user has to translate their goal into your taxonomy first, guessing which division owns the thing they need, and every guess is a chance to guess wrong and stall.

Organizing by internal category fails because the company’s structure is invisible and irrelevant to the visitor. Your business may be split into “Solutions,” “Platform,” and “Services” for reasons that make perfect sense internally, but a user trying to fix a billing problem does not know which of those words hides the answer, and frankly does not care. The org chart is a map of how you are arranged, not a map of what users are trying to accomplish, and navigation that mirrors it asks the user to learn your company before they can use your site.

A concrete example: a software company’s first navigation read “Products,” “Solutions,” “Services,” and “Resources,” the way its internal teams were divided. Users hunting for a download, a price, or support kept landing in the wrong section because those labels described the company, not their tasks. Reworked around goals, the same content sat under “Get Started,” “Pricing,” “Support,” and “Learn,” and the wrong-turn problem largely disappeared, because each label now answered a question a real visitor was actually asking. The pages did not change, only the lens the navigation was grouped through.

One thing the rule does not cover: some audiences truly do think in categories, and matching the mental model occasionally means leading with what things are. A specialist reference site, a parts catalog, or a tool whose expert users navigate by established type names should group by those categories, because for that audience the category is the goal, the word they would use unprompted. The rule is not “never group by what things are,” it is “group by the user’s mental model,” and when that model is categorical, follow it. The mistake is defaulting to your categories because they match your structure, not because they match your users.

To decide well, find out how your users describe what they came to do, through research, support tickets, search logs, or simply listening to how they phrase requests. Lead with task-based groupings that echo those phrasings, and use category-based groupings only where you have evidence the audience genuinely thinks in categories. Test labels against real intentions rather than internal naming, and let the user’s mental model, not the org chart, draw your navigation.