Information Architecture & Navigation Patterns

The plain-language idea

Information architecture (IA) is the practice of deciding what content and functionality exist in a product and how they're organized, labeled, and related to each other — independent of how any of it looks. Navigation is the visible expression of that structure, not the structure itself. Redesigning a nav bar without first fixing a broken IA is decorating a building whose rooms are in the wrong order; it'll look better and still confuse everyone who walks through it.

The most common IA failure is organizing content around how the company is structured instead of how users think about the content. A settings page split into "Account," "Billing," and "Notifications" because three different internal teams own those areas is org-chart IA — it made sense in a planning meeting and nowhere else. Users don't know or care which team owns what; they know they want to "change my email" or "stop getting emails," and a good IA groups by that intent instead.

Navigation patterns trade off depth (how many clicks to reach content) against breadth (how many options are visible at once):

• Top nav — a small number of top-level items, always visible, best when the whole product fits in 5-7 categories.
• Sidebar nav — supports more items and nested hierarchy without crowding a horizontal bar, common once a product has enough sections that a top nav would either scroll or overflow.
• Tabs — for switching between a small number of sibling views of the same content (not a substitute for real navigation between unrelated sections).
• Breadcrumbs — don't replace primary navigation; they answer "where am I" inside a hierarchy that's already several levels deep, and let a user step back up without hitting "back" repeatedly.

See it in a real thing: two menus, one product

A settings screen with items grouped as Profile, Team, Billing, API Keys, Integrations, Danger Zone is grouped by what a user is trying to accomplish — the first five are each a distinct, nameable task, and "Danger Zone" is a deliberate, separately-signaled category for irreversible actions. The same screen grouped as General, Admin, Enterprise, Developer is grouped by internal product-tier logic — a user has to already know which tier "delete my account" lives under before they can even start looking. The content underneath can be identical; the difference is entirely the grouping decision, made before either version was ever styled.

What people usually miss

Watch out

• A deep hierarchy isn't automatically bad, and a flat one isn't automatically good. The real tradeoff is depth vs. breadth: cramming everything into a flat top nav to "avoid extra clicks" just produces a crowded bar that's slower to scan than two well-labeled clicks would have been.
• Breadcrumbs are a "where am I," not a "how do I get anywhere." A page that relies on breadcrumbs as its only wayfinding still needs primary navigation — breadcrumbs answer position within a hierarchy the user already entered, not how to enter a different one.
• Tabs quietly break when the "sibling views" assumption stops holding. Tabs work for views of the same object (an item's Details/Reviews/Shipping); once one "tab" is actually an unrelated section with its own sub-navigation, it should be a real nav item, not a tab pretending to be one.
• IA problems get misdiagnosed as visual-design problems. "Users can't find X" is frequently answered with a redesign of the nav's look when the actual fix is renaming or regrouping items — restyling a wrong structure ships a prettier version of the same confusion.

Why this matters in interviews

"How would you organize navigation for [some multi-section product]?" is testing whether a candidate reaches for structure first — what are the real user tasks, how should they group — rather than jumping straight to "I'd put a sidebar on the left." Naming the depth/breadth tradeoff and the org-chart-vs-user-mental-model failure mode is what separates a structural answer from a purely visual one.