Information Architecture & Navigation

Information architecture (IA) is the art and science of organizing, labeling, and structuring content so people can find what they need and understand where they are. Rosenfeld, Morville & Arango (Information Architecture for the Web and Beyond, the "polar bear book") frame IA as four interlocking systems: organization, labeling, navigation, and search. Navigation is the visible surface of the IA; the structure underneath is what makes navigation possible. A beautiful nav bar over a broken taxonomy is lipstick on a maze.

Findability is the goal. As Morville puts it: "What you can't find, you can't use." If users can't locate a feature, it does not functionally exist. IA is upstream of UI — fix the structure before you style the menu.

1. The four IA systems

| System | Question it answers | Artifacts | |---|---|---| | Organization | How is content grouped and structured? | Sitemap, taxonomy, content model, hierarchy | | Labeling | What do we call things? | Label set, controlled vocabulary, nav labels, microcopy | | Navigation | How do users move through the structure? | Global/local/contextual nav, breadcrumbs, filters | | Search | How do users find by query, not browse? | Search box, autocomplete, results page, facets, scoping |

These are not independent. A category that's hard to label is usually a sign the organization is wrong. Search that returns junk is usually a labeling/metadata problem, not a search-algorithm problem.

2. Mental models — match the user's vocabulary, not your org chart

A mental model is the user's internal map of how your domain works. IA succeeds when your structure matches that map and fails when it mirrors your internal team boundaries, database tables, or executive reporting lines.

• Don't ship the org chart. "Products / Services / Solutions / Resources" is a company structure, not a user task. Users think "I need to fix my login" not "I'll visit the Identity Platform division."
• Use the user's words. Run the labels you're considering against real search-log queries, support tickets, and interview transcripts. If users say "invoices" and you say "billing statements," you lose them.
• Domain ≠ jargon. Internal jargon ("SKU configurator," "entitlements") is precise to you and opaque to them. Reserve precise domain terms only where the audience itself uses them (a tax product can say "Schedule C" — accountants expect it).

> Rule: the navigation should read like the user's to-do list, not your team's directory.

3. Organization schemes — exact vs. ambiguous

Rosenfeld/Morville split organization schemes into two families:

Exact (objective) — unambiguous, mutually exclusive buckets. Easy to maintain, great for known-item lookup, useless when the user doesn't know the exact term.

| Scheme | Use when | Example | |---|---|---| | Alphabetical | User knows the name | A–Z staff directory, glossary, country picker | | Chronological | Time is the key axis | Changelog, news archive, order history | | Geographical | Place is the key axis | Store locator, regional pricing |

Ambiguous (subjective) — group by meaning. Harder to design (judgment calls, overlap), but far more useful for exploratory browsing because users rarely know the exact term.

| Scheme | Use when | Risk | |---|---|---| | Topic / subject | Browse by what it's about | Items legitimately fit two topics | | Task | Organize by what user wants to do ("Track a package") | Tasks evolve; verbs drift | | Audience | Distinct user types with distinct needs ("For Developers / For Teams") | Users misidentify which group they're in | | Metaphor | Borrow a familiar model (desktop, cart, trash) | Metaphor breaks at the edges; don't over-extend |

Most real products use a hybrid: a topic/task spine for primary nav, with exact schemes (date, A–Z) as sort/filter options inside. Avoid a single nav that mixes schemes incoherently ("Products, About Us, 2024, Spanish") — that's a hybrid done badly.

> Heuristic for choosing: if the user knows the exact item name → exact scheme (let them sort A–Z or search). If they're exploring or don't know the term → ambiguous scheme (topic/task). Most failures come from forcing an exact scheme on an exploratory user: an A–Z list of 400 features is useless to someone who doesn't know feature names.

4. Taxonomy, hierarchy, and the depth-vs-breadth tradeoff

A taxonomy is the named hierarchy of categories. Two structural levers define it: breadth (options per level) and depth (number of levels to reach content).

| | Broad & shallow | Narrow & deep | |---|---|---| | Shape | Many top-level choices, few clicks down | Few top-level, many clicks down | | Pro | Fast to reach content; everything near surface | Each choice is simple; less to scan | | Con | Overwhelming menus; choice paralysis (Hick's Law) | "Pogo-sticking," users get lost, abandon | | Best for | Sites with diverse, equally-weighted content | Strict, well-understood classifications |

Guidance (NN/g & IA practice):

• Prefer broad and shallow for the web. Users tolerate scanning more options far better than they tolerate clicking through many levels of uncertainty. Aim for 3 clicks-ish, but depth matters less than confidence — users will click deep if every step clearly signals progress. The real killer is uncertain clicks, not many clicks.
• Keep most content within ~3–4 levels of the home/root. Beyond that, findability craters.
• A common sweet spot for a level is 5–9 sibling items (Miller's "7±2" is a memory limit, not a hard nav rule — for scannable visible menus you can exceed it; for recall you can't).
• Controlled vocabulary: a curated, governed list of allowed terms (with preferred terms + synonyms/"see also"). It keeps labels consistent and powers search synonyms — "laptop" finds items tagged "notebook."
• Faceted classification (Ranganathan's heritage): tag each item with multiple independent dimensions (price, color, brand, rating) so users can combine filters rather than navigate one rigid tree. This is the backbone of e-commerce and any large, multi-attribute catalog. Facets must be orthogonal (independent) and each value should return results — never offer a filter that yields zero items.

5. Navigation types

| Type | Role | Where it lives | |---|---|---| | Global / primary | The top-level map; present on (nearly) every page | Top bar / sidebar | | Local / secondary | Children of the current section | Sub-nav, side menu within a section | | Utility | Account, search, cart, settings, language, help | Top-right corner, footer | | Contextual / inline | Links embedded in content ("related," "see also") | Within the page body | | Breadcrumbs | Show position in hierarchy + path back up | Just below header | | Footer ("fat footer") | Catch-all: low-traffic but important links, legal, sitemap | Page bottom | | Supplemental | Sitemap, index, guide — alternate routes for the lost | Linked from footer |

Every page should answer three questions instantly: Where am I? What's here? Where can I go? If a page can't answer all three, the navigation is incomplete.

Global vs. local, in practice. Global nav is the constant across the whole product — it's the user's anchor, so keep it stable; changing it page-to-page destroys orientation. Local nav is contextual to the current branch and changes as you move between sections. A common structure: a fixed global bar (top), a section-specific local nav (sidebar or sub-tabs) that appears only inside a section, breadcrumbs to tie them together, and a fat footer as the universal safety net. Utility items (login, search, cart) live apart from content nav so users learn "tools live top-right" — don't scatter them into the content menu.

6. Navigation patterns per device

| Pattern | Best for | Cost / caveat | |---|---|---| | Top horizontal bar | Desktop, ≤7 primary items | Runs out of room fast; not for deep IA | | Left sidebar | Apps/dashboards with many sections; deep IA | Eats horizontal space; weak on narrow screens | | Tabs | Switching views of the same object (Overview/Activity/Settings) | Not for unrelated destinations; ~2–5 tabs | | Bottom nav (mobile) | 3–5 top-level destinations, thumb-reachable | Max 5; icons need labels; not for deep trees | | Hamburger / drawer | Secondary or overflow nav on mobile | Hides nav → lower discovery & engagement | | Mega-menu | Broad catalogs needing many visible links at once | Overwhelming if unstructured; needs grouping + headings; keyboard/hover traps | | Faceted nav / filters | Large result sets (catalog, search) | Must show counts, allow multi-select, be clearable |

Hidden navigation has a real cost. NN/g's research is consistent: when primary nav is hidden behind a hamburger, discoverability and engagement drop versus visible nav. On mobile the compromise is bottom tab bar for the 3–5 most important destinations (always visible) plus a drawer for the long tail. Don't bury primary actions in a hamburger just because the icon is tidy. On desktop, a hamburger on a wide screen with room for a real menu is almost always wrong.

Mega-menu rules: group links under visible sub-headings, keep columns scannable, support keyboard navigation and a generous hover-intent delay (so users don't lose the menu by cutting a corner), and never put only a mega-menu link to a section with no landing page.

7. Wayfinding — "you are here"

Wayfinding borrows from architecture: people need constant, cheap signals of location and direction. Without them, users get the digital equivalent of being lost in a parking garage.

• Current-location indicator — highlight the active nav item (bold/accent/underline + aria-current="page"). The single most-skipped, most-needed cue.
• Breadcrumbs — show the full path (Home > Catalog > Laptops > XPS 13) and make every crumb clickable. Use location breadcrumbs (hierarchy), not "history" breadcrumbs (where you've been) — history confuses.
• Page titles & headings match the nav label that led there. If the link said "Pricing," the page's <h1> says "Pricing." Label-destination consistency is a wayfinding signal.
• Back / up — "up" (to parent) ≠ browser "back" (to previous). Offer an explicit up affordance for deep pages so users don't depend on browser back.
• Deep links — every meaningful state has its own URL so it can be shared/bookmarked, and so a user landing cold from search can still orient (breadcrumbs + active nav do the orienting).
• Hierarchy cues — indentation, nesting, and progressive disclosure show structure as users descend.

Breadcrumb mechanics: show every ancestor as a link, separated by a consistent glyph (> or /); the current page is the last crumb and is not a link (it's where you are). On deep mobile screens where the full trail won't fit, collapse the middle (Home > … > XPS 13) but keep the immediate parent visible — "up one level" is the most-used crumb. Breadcrumbs are an addition to primary nav, never a replacement for it.

8. Search — when, and how to do it well

Browse vs. search: browse when the user doesn't know the exact term or wants to explore (good IA shines here). Search when they know what they want and the catalog is large. Offer both on any site past a few dozen pages — they're complementary, not rivals. Search is also the safety net for an imperfect taxonomy: when browse fails, search saves the session.

Search box design

• Make it visible (don't hide search behind an icon on content-heavy sites) and wide enough to show a typical query (~27+ characters).
• Magnifying-glass icon + placeholder; a visible "Search" button helps discoverability.
• Persist the query in the box on the results page so users can refine, not retype.
• Scope it clearly when search is scoped ("Search docs" vs. global) and let users widen scope from zero-results.

Autocomplete / suggestions — suggest queries, categories, and direct results as the user types. Reduces typos and mental effort (and surfaces your vocabulary). Make suggestions keyboard-navigable.

Results layout — most-relevant first; show enough context (title, snippet, type, breadcrumb-to-location) to judge each hit; highlight matched terms; allow sort (relevance/date/price) and filter/facet narrowing of the result set. Always state the result count and the interpreted query ("12 results for wireless headphones") so the user can tell whether the engine understood them. Each result should carry enough metadata to not require a click to disqualify it — type badge, location/breadcrumb, date, price — because the cheapest search is the one where the user judges relevance from the list, not by opening five tabs.

Scoped search lets the user constrain before querying ("in Documentation," "in this folder," "in Orders"). Make the current scope visible in or beside the box, and always offer a one-click "search all / widen scope" escape — especially from a scoped zero-results page, where the answer often lives just outside the current scope.

Zero-results is a design state, not an error. Never dead-end. Show: a plain-language "No results for X," likely causes (typo, too specific), suggestions ("Did you mean…"), broadened/related results, popular content, and a clear path to contact/help. A blank "0 results" page is an abandonment machine.

Federated / unified search — across multiple sources (docs + help + community + products), label each result's source and let users filter by it. Don't merge incomparable types into one ranked blob with no indication of what each is.

| Search anti-pattern | Fix | |---|---| | Exact-match only (no typo/synonym/stemming) | Add fuzzy matching, stemming, synonym ring from controlled vocab | | Search box hidden behind an icon on a content site | Show a real input field | | Query cleared on results page | Persist query, allow inline refine | | Zero-results dead-ends | Suggestions + broadened results + help path | | No facets on large result sets | Add multi-select facets with counts |

9. Labeling — clear, consistent, scannable

Labels are the contract between your structure and the user's understanding. The best label is the one the user would have guessed.

• Clarity over cleverness. "Our Story" loses to "About." Witty section names ("The Lab," "Hub") force a guess; users won't gamble a click on a maybe.
• Consistency. Same concept = same word, everywhere (nav, breadcrumb, page title, button). Don't call it "Account" in the header, "Profile" in the menu, and "Settings" on the page.
• Scannability & case. Use sentence case for nav and UI labels (easier to read than Title Case, less shouty than ALL CAPS). Keep labels short — 1–2 words for nav.
• Parallel structure. All nouns or all verbs within a set ("Track, Pay, Return" or "Tracking, Payments, Returns" — not mixed).
• No empty labels. "Solutions," "Services," "Resources," "More" tell the user nothing. Replace with what's actually inside.
• Test labels with tree testing and first-click before shipping — labels are the most testable, most often-wrong part of IA.

10. URLs and structure as IA

URLs are user-facing IA, not just routes. A readable URL is a wayfinding cue and a trust signal.

• Readable, hierarchical paths: /laptops/dell/xps-13 not /p?id=48213. The path should mirror the taxonomy so a user can hack the URL up a level and land somewhere sensible.
• Stable & permanent: when IA changes, 301-redirect old URLs — don't break bookmarks and inbound links (broken links are a findability and SEO failure).
• Lowercase, hyphenated, no stop-words: /get-started, not /Get_Started or /the-getting-started-page.
• URL structure, breadcrumbs, and nav hierarchy should all agree. Disagreement is a smell that your IA isn't single-sourced.

11. Content model & the sitemap

The taxonomy describes categories; the content model describes the things and their relationships — what a "Product," "Article," or "Course" is made of, what metadata it carries, and how it links to other types. Good navigation and faceted search both fall out of a good content model: facets are just exposed metadata fields, and contextual "related" links are just modeled relationships.

• Model content types and their attributes first. If a "Recipe" has cuisine, difficulty, time, and dietary tags, those are your facets and your filter UI — for free.
• A sitemap (the document, not the SEO XML) is the IA blueprint: a node-and-edge diagram of every page/section and how they nest. Use it to spot orphans (no inbound nav), over-deep branches, and lopsided sections before wireframing.
• Tagging vs. tree. A strict tree forces one home per item; tagging/faceting lets one item live under many lenses. Most large content needs both: a primary tree for browsing + tags/facets for cross-cutting discovery and search.

12. Cross-channel / omnichannel IA

Users move across web, mobile app, email, support chat, voice, and physical touchpoints in one journey. Rosenfeld/Morville's later work pushes IA beyond the single site toward consistent place-making across channels.

• Consistent vocabulary across channels — the same thing has the same name in the app, the website, the receipt, and the support macro.
• Continuity — a task started on mobile should be resumable on desktop; the user's mental model carries across devices.
• Channel-appropriate depth — a watch or voice interface exposes a slice of the IA (top tasks), not the whole tree. Decide what each channel surfaces; don't shrink the desktop nav onto a watch.
• Place, not pages — Morville/Arango argue users perceive a place ("my bank"), not a set of disconnected screens. Inconsistent IA across channels breaks the illusion of one place and forces the user to re-learn the structure at each touchpoint. Govern the taxonomy and label set centrally so every channel reads from one source.

> Do not just make the desktop site responsive and call it omnichannel. Omnichannel IA is deciding which tasks belong on which channel and keeping the structure and vocabulary coherent across all of them.

13. Research methods — prove the IA before you build it

IA is hypothesis-driven; these methods test it cheaply, before code.

| Method | What it tests | When | |---|---|---| | Open card sort | How users group & name content (generative) | Early — to discover categories | | Closed card sort | Whether items fit your predefined categories | After you have draft categories | | Tree testing ("reverse card sort") | Can users find an item in your hierarchy — labels + structure only, no UI | Validate a proposed tree | | First-click testing | Does the first click land on the right path? (First click right ⇒ ~2–3× more likely to succeed overall) | Validate nav labels on a layout | | Reverse card sort | Synonym for tree testing — give a task, watch them navigate the tree | — |

Workflow: open card sort to generate a candidate taxonomy → closed card sort or tree test to validate it → first-click test the labels on a wireframe → ship → watch search logs and analytics → iterate. Card sorting reveals the model; tree testing reveals whether your model is findable; first-click reveals whether your labels point the right way.

Findability metrics to monitor live:

• Task success rate & time-to-find (from tree/usability tests).
• First-click accuracy (% whose first click was on a successful path).
• Search-exit rate / zero-results rate & top zero-result queries (a backlog of missing content or missing synonyms).
• Pogo-sticking / back-button rate on category pages (signals wrong grouping or labels).
• Search-vs-browse ratio trending toward search can mean browse is failing.

14. Common mistakes

| Mistake | Why it fails | Fix | |---|---|---| | Org-chart navigation | Mirrors internal teams, not user tasks | Structure around user goals/vocabulary | | Too-deep hierarchy | Findability collapses past ~4 levels; users pogo-stick and abandon | Flatten; prefer broad-and-shallow | | Hamburger hides primary nav | Out of sight → lower discovery & engagement (NN/g) | Visible nav on desktop; bottom-tab top 5 on mobile | | Jargon / clever labels | Users won't gamble a click on a guess | Plain, user-tested words | | No current-location cue | Users don't know where they are | Active-state highlight + aria-current + breadcrumbs | | Inconsistent labels | "Account/Profile/Settings" for one thing erodes trust | One concept, one word, everywhere | | Exact-match-only search | A typo or synonym = zero results | Fuzzy + stemming + synonyms | | Dead-end pages / zero-results | Nowhere to go = abandonment | Always offer next steps, related content, help | | Filters that yield zero items | Wastes a click, erodes trust in facets | Disable/hide empty values; show counts | | Mixed organization schemes in one nav | "Products, About, 2024, Español" — incoherent | Pick a primary scheme; put exact schemes in sort/filter | | IA decided in the design tool | Pretty menu over an untested tree | Card-sort & tree-test before visual design |

15. Designer's checklist

• ] Structure reflects user tasks/vocabulary, validated against search logs & support tickets — not the org chart.
• ] Primary nav has ≤7 visible items (web top bar) or 3–5 (mobile bottom nav); overflow is intentional, not hidden-by-default.
• ] Most content within ~3–4 levels of root; broad-and-shallow preferred.
• ] Every page answers Where am I / What's here / Where to next (active-state, breadcrumbs, clear links).
• ] Labels are plain, consistent across nav/breadcrumb/title/button, sentence case, parallel, tested.
• ] Search present for any site past a few dozen pages: persistent query, autocomplete, facets, designed zero-results, scoping.
• ] URLs are readable, hierarchical, permanent (301s on change), and agree with breadcrumbs + nav.
• ] Facets are orthogonal, show counts, are multi-select and clearable, never offer empty values.
• ] Cross-channel vocabulary is consistent and tasks are resumable across devices.
• ] Content types and their attributes are modeled, so facets and "related" links fall out of metadata, not hand-curation.
• ] IA validated by card sort → tree test → first-click before build; findability metrics watched after.

Sources: Rosenfeld, Morville & Arango, Information Architecture for the Web and Beyond (4th ed., "polar bear book"); Nielsen Norman Group (broad-vs-deep hierarchies, hamburger-menu discoverability, breadcrumbs, mega-menus, first-click testing, search UX); Ranganathan (faceted classification); Miller, "The Magical Number Seven" (memory limit, not a nav law).