Designing Intranet Information Architecture

Every company has the same internal joke: nobody can find anything on the intranet, so they Slack a colleague for the link instead. That's not a search problem or a CMS problem. It's an information architecture problem — the way content is structured, labeled, and navigated. An intranet doesn't fail because it's missing features. It fails because the org chart got turned into a navigation menu, and now finding the parental-leave policy requires knowing which department owns it. This is how to design intranet information architecture that holds up once real employees start using it: structure it around the task instead of the org chart, and label things the way people actually say them. Then test that structure before anyone builds a page.

Why intranets break at findability, not features

An intranet is a content site for a captive audience who didn't choose it and can't churn. That sounds easy — they have to use it — but it's the opposite. A public site earns attention; an intranet inherits a frustrated one. People arrive mid-task, already annoyed, looking for one specific thing: a form, a policy, a person, a deadline. If the architecture makes them hunt, they route around it entirely — and the workaround has a cost. A thousand "hey, where do I find…" messages quietly become the real knowledge system, and the intranet sits unused while the answers live in people's DMs.

The root cause is almost always the same: the navigation mirrors the org chart instead of the task. HR, IT, Facilities, Legal — clean boxes to the people who run them, useless to the person who just wants to expense a flight and doesn't know whether that's Finance or Operations. Conway's law shows up as a menu, and the whole job of intranet information architecture is to refuse that default and organize around the work people are actually trying to get done.

Structure around tasks, not departments

The first move is to organize the top level by what people are trying to do, not by who owns it. Employees don't think in departments; they think in errands. "Book time off." "Find the brand assets." "Submit an expense." "Look up someone's manager." Those are the labels that belong at the top of an intranet, because they match the language in someone's head when they land.

This is the difference between an organization-centric and a task-centric structure:

• Org-centric (the trap): Home → HR → Benefits → Leave → Parental Leave. Four clicks, and every click demands you know the corporate taxonomy.
• Task-centric (the fix): Home → Time Off → Parental Leave. The intranet meets the user where their goal is, and the department that owns the page becomes metadata, not navigation.

Departments still need homes — a place for IT to publish its own updates. But that's a secondary axis, a filter, not the primary spine of the intranet. Nielsen Norman Group's work on polyhierarchy is the unlock here: one piece of content can live in several paths at once, so the expense policy is reachable from both "Submit an Expense" and "Finance" without being duplicated. You design the primary path for the task and let ownership ride along as a facet.

Label in the user's words, not the company's

The fastest way to break an intranet is to name a section after an internal initiative. "TotalRewards." "OneStop." "The Hub." Nobody searches for those, because nobody calls benefits "TotalRewards" in their own head. Get the labels wrong and the structure underneath them stops mattering: a perfect hierarchy nobody can name is a perfect hierarchy nobody finds.

The rule is plain — use the words people would use if they were asking a coworker. "Time Off," not "Leave Management." "Get IT Help," not "Service Desk Portal." "Find a Coworker," not "Personnel Directory." When you must keep an internal program name for political reasons, pair it with the plain term so search and scanning still land: Benefits (TotalRewards). The plain word is what actually does the wayfinding.

This is recognition over recall (NN/g) applied to an intranet: a person scanning a menu should recognize their task in your label, not have to recall what your company decided to call it.

Test the tree before you build the pages

You can validate the architecture before a single page exists, and most intranet redesigns skip this and regret it. The structure is a hypothesis about how people categorize work, and a hypothesis is cheap to test.

• Card sorting tells you how employees would group your content. Hand 15 people the list of topics and let them cluster and name the piles. The groupings that recur are your real top-level categories — usually not the ones the steering committee drew.
• Tree testing validates the structure you landed on. Give people the bare navigation hierarchy, no visual design, and a task: "Where would you go to find the remote-work policy?" The success rate and the wrong turns tell you exactly where the intranet's labels and nesting mislead.

Run tree testing before visual design, because a beautiful page on a broken branch is still lost. If 40% of testers look for the remote-work policy under "Facilities" instead of "HR," that's not a user error — it's the architecture telling you where the content should actually live. NN/g's tree-testing guidance walks through the setup; an afternoon of it is usually enough to catch that miss before a single page ships.

Keep it shallow, and let search carry the long tail

Two structural defaults serve almost every intranet:

Stay shallow. Aim for most content within three clicks of home. Deep hierarchies feel tidy in a sitemap and miserable in use — every extra level is another label the user has to guess right. Broad-and-shallow beats narrow-and-deep, because scanning ten options on one screen is easier than making five sequential correct guesses.

Treat search as architecture, not a bolt-on. On an intranet, a large share of users start with search, especially for the specific document they know exists. That means your structure and your search index have to agree: the synonyms people type ("PTO," "vacation," "holiday") all need to resolve to the same "Time Off" destination. Search is a second front door, and it has to open onto the same building. It won't rescue a broken structure — it'll just surface the same confusing labels faster.

Intranet IA, the short version

Decision	Org-centric default (breaks)	Task-centric fix (works)
Top-level nav	Departments (HR, IT, Finance)	Tasks (Time Off, Get Help, Expenses)
Labels	Internal program names	Words employees actually use
One page, many paths	Duplicated or buried	Polyhierarchy — owned by a dept, reachable from tasks
Validation	Launch and hope	Card sort to build, tree test to verify
Depth	Deep, mirrors the org	Shallow — most content ≤3 clicks

Frequently asked questions

What is intranet information architecture? It's the structure, labeling, and navigation of a company's internal site — how content and tools are grouped, what each section is called, and how people move between them to finish a task. Good intranet information architecture is judged by one thing: can an employee find what they need without asking a human?

How is an intranet different from a public website's IA? The audience is captive but unmotivated, and the content is broad and cross-functional rather than marketing-shaped. A public site optimizes for a few conversion paths; an intranet has to serve hundreds of unrelated errands across every department, which is exactly why a task-centric structure beats an org-centric one.

Should the intranet navigation match our org chart? No. The org chart is how the company is organized, not how work is organized in an employee's head. Use tasks as the primary navigation and let department ownership be a secondary filter. The single most common cause of an unusable intranet is a menu that's secretly an org chart.

How many clicks deep should intranet content be? Keep most content within three clicks of the home page. If something needs more nesting, that's usually a signal the top-level categories are wrong, not that the content is genuinely that deep. Pair shallow structure with strong search so the rare long-tail document is still one query away.

How do we know our intranet IA actually works? Tree-test it. Give real employees the bare hierarchy and a handful of "where would you go to…" tasks, and measure how often they land in the right place on the first try. A success rate below ~70% on common tasks means the architecture — not the users — needs the rework.

Take it further

The discipline underneath all of this is clarity — whether a person can see where to go and trust that it's the right path. That's the UX Clarity framework, the lens behind every teardown in our information architecture hub. If you want it applied to your own product — public site or internal intranet — that's a Full UX Audit, where we score exactly where your structure and your users' mental model have drifted apart.

Sources: NN/g — Recognition vs Recall · NN/g — Tree Testing · NN/g — Polyhierarchy & Faceted Navigation.

Watching employees Slack each other for links instead of using the intranet? Apply for a Full UX Audit →