Information Architecture (IA) = how to organize, categorize, and label the content of a website/App, and how content relates to one another. Note that it is not a single diagram, not a single deliverable, but a continuous optimization process — as content changes and users change, IA iterates accordingly.
A real-life analogy: IA is to a website what the spatial planning of a large building is. The signs and elevator buttons users see when entering (= navigation) are only the tip of the iceberg; behind them lies a full set of blueprints for 'what goes in which room, how floors are divided' (= IA structure), as well as a cataloging system for 'what label to put on each item, how to categorize them' (= taxonomy). The three work together to make the building usable.
Read these 6 articles along three core axes:
(1) What IA is + the three core models — clarify the three layers of 'visible navigation / underlying IA structure / taxonomy', then distinguish 'IA vs sitemap' (the two terms most often confused with each other).
(2) How to build the structure — should content be spread out flat (flat hierarchy) or buried in deep layers (deep hierarchy)? This is the first hard decision in IA.
(3) How to implement navigation and content pages — when to use left-side vertical navigation, how to build a taxonomy from scratch, and how to fix a high-frequency pitfall page (privacy policy/terms of service page).
1. What is IA: three core models + how it differs from a sitemap
IA is abstract and hard to define; NNGroup breaks it down into three models for understanding. The key is to distinguish between 'what users can see' and 'what the internal team uses', as well as between 'organizing content' and 'organizing concepts'.
| Model (EN / CN) | What it is | Front/Back Stage | Analogy (building) | Can users see it? |
|---|---|---|---|---|
| Visible Navigation | UI that guides users on 'where I am, where I can go': menus, links, breadcrumbs, accordions | Front Stage | Signs, elevator buttons (only a limited area is visible) | Yes, and users interact with it directly |
| Underlying IA Structure | A complete map of all key pages/screens across the site + their interrelationships; the team uses it to design navigation and decide content ownership | Back Stage | Full set of architectural blueprints (the entire building, not just the current floor) | Not visible, but more detailed and complete than visible navigation |
| Taxonomies & Metadata | A logical classification system (concept map) that describes the characteristics of each piece of content and links similar content together | Back stage (occasionally surfaces as filters/search suggestions) | The 'label cataloging system' for items | Mostly invisible, partially presented as filters/search suggestions |
Division of labor and relationships between the three (must memorize):
| Dimension | Visible Navigation | IA Structure | Taxonomy |
|---|---|---|---|
| Serves | Users (operation entry point) | Design team (planning tool) | System (content association/retrieval) |
| Emphasis | Intuitive, simple,aligned with users' mental models | Comprehensive, logical | Logically precise, conceptual relationships |
| Organizes | Paths | Content | Concepts |
| Degree of technicality | Lowest | Medium | Highest, broadest |
Core principle: Visible navigation pursues 'matching how users think', while taxonomy pursues 'logically accurate classification' —these two goals often conflict, which is why they need to be split into separate layers each responsible for their own part, rather than using one single structure to forcefully meet both requirements.Why: The categories in users' minds (for example, classifying 'returns' under 'my orders') do not always align with the cleanest logical classification (classifying 'returns' under 'after-sales policy'); navigation accommodates the former, taxonomy serves the latter, each leveraging its strengths.
IA vs Sitemap: the most common confusion
Many people treat 'drawing a sitemap' as 'doing IA'. That is wrong. NNGroup uses a concentric circles diagram to clarify: IA is the full set of activities in the outermost ring, while a sitemap is only one output in the innermost ring.
| Ring (from outside to inside) | Name | What it includes |
|---|---|---|
| Outer ring | IA Activities | Content Inventory (identifying and categorizing all content) + Content Audit (evaluating what to keep/remove/update) + IA UX research (Card Sorting, Tree Testing, to understand findability and organization) + Taxonomies & Tags |
| Middle ring | Plan Website Structure | Content organization (how to group and layer) + navigation design |
| Inner ring | Site Map | Visualizes content hierarchy and page relationships + serves as a planning/communication tool |
| Comparison dimension | Information Architecture (IA) | Sitemap |
|---|---|---|
| Nature | Abstract overall practice/process (categorization, labeling, findability, navigation logic) | Concrete visual deliverable (a hierarchical diagram) |
| Coverage | Full: includes user research, content classification, label design | Narrow: only shows page hierarchy and flow |
| Focus | Details such as labels, pagination, search bars, breadcrumbs | Does not focus on specific navigation components or naming |
| Purpose | Plan the overall content architecture (ongoing optimization) | Communicate with teams/stakeholders, plan |
Example of NNGroup's own sitemap: it uses color coding for hierarchy —blue nodes = first-level information, green = second-level objects, yellow = third-level objects, intuitively presenting the content hierarchy of nngroup.com.
Counterexample/pitfall: Claiming 'IA is done' after only delivering a sitemap. A sitemap does not include content classification, user research details, or naming logic — it is one of the deliverables of IA, not IA itself. Neither is set in stone; both are continuously adjusted as user research and website iteration progress.
2. The first hard decision: Flat vs Deep Hierarchies
After content is confirmed, the first structural decision is: how wide to spread top-level categories, how deep to bury content below. This is a tradeoff,with no absolute better or worse.
| Dimension | Flat Hierarchy | Deep Hierarchy |
|---|---|---|
| Number of top-level categories | Many (all main categories visible at a glance) | Few (concise top level) |
| Hierarchy depth | Shallow | Multiple layers of subcategories |
| Interaction cost (number of clicks) | Low, fewer clicks to reach destination | High, long path |
| Visibility | Strong, scope clear at a glance | Low, overall structure hard to grasp |
| Main risk | Information overload: too many categories overwhelm users, who may skip important items | Cognitive load: cramming large amounts of content into a small number of categories → category names become vague and hard to understand |
| Suitable scenarios | Requiring quick lookup | Information-dense, large content volume requiring layered management |
Real-world cases (numbers must be remembered):
| Website | Structure | Specific numbers |
|---|---|---|
| New Zealand government website | Flat | 15 top-level categories, convenient for quick browsing |
| Ernst & Young | Deep | Only 5 top-level categories, but under 'Services' there are 11 subcategories, and under 'Consulting' there are another 10 further subdivisions |
Core principles / comprehensive recommendations:① Avoid extremes — being too flat (too many categories) or too deep (content buried too deep) both cause problems; ② Moderately flat > Moderately deep — because more options are visible, users more intuitively understand what the website offers; ③ User research is key — through user testing and needs research, understand users' cognitive models of content and their key priorities before finalizing the structure.Why: Visibility is the prerequisite for users to build an overall understanding of 'what this website has'; flat structures trade visibility for interaction cost, which is usually more cost-effective; but 'how flat is not overloaded' must be found through testing, not guesswork.
3. Navigation implementation: when to use Left-Side Vertical Navigation
Vertical navigation (navigation bar arranged vertically on the left side of the screen) is especially suitable for websites that are content-heavy, have broad categories, and will continue to grow. It can accommodate more top-level categories and facilitate quick scanning, at the cost of taking up page space.
Why choose vertical navigation (4 reasons):
| Reason | Mechanism | Key data/examples |
|---|---|---|
| 1 Accommodates more categories, improves findability | Not limited by horizontal space, can display more specific categories with high information scent, without shortening names or reducing quantity; users do not need to click a vague top-level item first to find specific content | Abel Restaurant easily accommodates 13 global navigation categories |
| 2 Supports future expansion | Adding new categories does not require redesigning the entire navigation | Suitable for institutions with continuously growing content such as universities, governments, and healthcare |
| 3 Easier to scan quickly | Users' gaze favors the left side,80% of attention is concentrated on the left half of the screen; vertical lists let users take in more information at a glance, more efficient than moving back and forth horizontally | —— |
| 4 Familiar and easy to use for users | Very common in desktop applications, users are already accustomed to it | Slack and Gmail both use left-side vertical navigation |
Challenges (2):① Takes up more space — compresses the content area, especially on small screens/tablets; ② Overlong menus hide important items — categories are pushed below 'the fold' (off-screen), requiring scrolling to see.
Content-to-chrome ratio case study:Nua Bikes The old design used left vertical navigation, with a content-to-chrome ratio of approximately 5:1; after the redesign switched to horizontal navigation, the ratio rose to 12:1 on the same screen size — there are far fewer top-level categories in the navigation, but the content space increased substantially.By contrast, IBM Watson Studio: on extra-large displays, vertical navigation has a negligible impact on the content-to-decoration ratio, because white space (or dark background empty space) is already added on both the left and right sides.
5 Best Practices:
| # | Practice | How to do it / Why | Counterexample |
|---|---|---|---|
| 1 | Left-align and design it to be prominent | Place it on the left side of the screen (suitable for left-to-right reading languages); use color/borders to distinguish it from the rest of the page; avoid right-side navigation Avoid right-side navigation(users pay less attention to the right side and can easily miss it) | Audi's design system uses a high-contrast dark background to ensure the left navigation is prominent and easy to read |
| 2 | Do not duplicate navigation | Do not display the same content using both horizontal and vertical navigation at the same time,same content, which causes confusion and redundancy | BDO Consulting uses both a horizontal bar and a right-side hamburger menu, and the items in the two are completely identical (the hamburger only adds locations/events/news), which is purely redundant |
| 3 | Avoid using icons alone | Icons must be paired with text labels; using icons alone increases cognitive load, forcing users to guess or make extra clicks | NOAA only displays icons by default; users must click to see category names, which unnecessarily adds interaction cost |
| 4 | Optimize overlong menus | Place the most important options in the visible area;place less important options at the bottom of the menu; when a long menu is unavoidable, provide search/filter as a supplementary lookup method | Sunglass Hut's old solution used center-aligned text, creating ragged edges that weakened the scanning advantage of vertical lists |
| 5 | Mobile adaptation | Vertical navigation can naturally adapt to mobile; only layout details need adjustment, no major overhaul is required | heywoodgolf's vertical navigation required only minor changes to adapt from desktop to mobile |
Overall counterexample:Accenture hides its broad information space entirely under a single "Services" category, artificially limiting the number of top-level categories — as a result, the findability of specific consulting areas is reduced and interaction cost increases (users are forced to open top-level categories one by one to browse, confirm they are not suitable, then exit). This is a typical case of "sacrificing discoverability for the sake of a clean top level."
IV. Taxonomy: How to Build the Backend "Tag Catalog System" from Scratch
Taxonomy is the backend structure of IA. It uses a standardized set of metadata rules to tag content and establish logical relationships,making up for content associations that the visible navigation system may miss. Every piece of content on a website is marked with one or more taxonomy terms, and the backend uses these to direct users to related content.
Three Core Characteristics:
| Characteristic | Meaning |
|---|---|
| Controlled Vocabulary | A finite, predefined set of terms for content creators to use when tagging new content |
| Hierarchical structure | Terms are arranged in parent-child relationships (for example, under "Cars" there are "Personal cars" and "Shared cars") |
| Non-extensibility | Content creators cannot arbitrarily add new terms; they may only use established ones |
What Taxonomy Can Do (3 Major Uses):
| Use | Mechanism | Real-world example |
|---|---|---|
| Build content associations | Make related content recommendations based on taxonomy (far more precise than high-level categories in navigation) | Related article recommendations on the NN/g website come from a detailed taxonomy rather than high-level navigation categories |
| Support Faceted Navigation | Users apply multiple filter dimensions simultaneously to locate content precisely, without drilling down through cumbersome hierarchies | The left-side search facets on the U.S. Library of Congress website: multi-dimensional filters such as topic, part/collection, and original format, implemented by a powerful faceted taxonomy |
| Improve search suggestions/results | The system recommends more accurate terms or optimizes results based on the taxonomy | The World Bank: when a user types the beginning "Europe population…", the system suggests the preferred term "Population, total, European Union" and related categories |
Taxonomy vs Other Metadata Tools (Increasing Complexity):
| Tool | Supported relationships | Complexity / Use case |
|---|---|---|
| Taxonomy | Primarily parent-child relationships; can be a single hierarchy or faceted (multi-dimensional) | Basic |
| Thesaurus | Parent-child + synonym relationships (equivalent terms) + associative relationships (related but not the same) | Medium; resolves term consistency and improves retrieval completeness |
| Ontology | The widest range of semantic relationships (location, attributes, status, etc.) | Most complex; used in technical domains to describe multi-dimensional information of complex knowledge |
Diagram mnemonic: ① A polar bear in a hierarchical taxonomy is classified only by a single "parent-child/class-member" relationship; ② The same car in a faceted taxonomy has an independent small hierarchy for each attribute (shared/personal/cargo), allowing fine-grained feature combinations; ③Ontology can go beyond parent-child relationships to capture other attribute relationships of polar bears, such as conservation status and habitat.
How to Build a Taxonomy (8-Step Process):
| Step | What to do |
|---|---|
| 1 Content inventory and audit | Determine the content to be organized and its scope |
| 2 Reference existing taxonomies | Check whether industry-standard taxonomies can be reused/modified (resources can be found at BARTOC.org)BARTOC.org ) |
| 3 Define core concepts | Extract concepts from content, user data (such as search logs), and business requirements |
| 4 Evaluate terms | Ensure terms are relevant to user needs; avoid isolated or overly narrow terms |
| 5 Select preferred terms and alternative terms | For terms that users will encounter, prioritize clear, user-friendly ones |
| 6 Build concept relationships | Define parent-child relationships and associative relationships |
| 7 Iterate and review | Refine together with stakeholders and subject matter experts (SMEs) to ensure applicability |
| 8 Apply + maintain | Tag content, train content managers; establish a regular review mechanism (add/merge/delete terms) |
Key insight: Taxonomy is "backend infrastructure" — users barely see it, but it determines how well search, recommendations, and filtering work.Why: Its value lies precisely in "logical precision" — it catches the fine-grained content associations that visible navigation cannot achieve, using a controlled, stable term system on the backend.Implicit counterexample: Letting content creators arbitrarily invent tags (violating "non-extensibility") will quickly cause term drift and loss of control, breaking associations and retrieval entirely — this is why taxonomy must be controlled and have a maintenance mechanism.
V. A High-Frequency Pitfall Page: 5 Major Mistakes on Privacy Policy/Terms of Use Pages
Privacy Policy and Terms of Use pages are often treated as a "legal checkbox," with user experience neglected, resulting in content that is hard to understand and hard to navigate,which in turn damages user trust. NNGroup summarizes 5 common types of mistakes and optimization directions.
| # | Mistake | Problem manifestation | Optimization suggestion | Positive example / Counterexample |
|---|---|---|---|---|
| 1 | Obscure or overly vague language | Full of legal jargon; users cannot understand it or feel the company is hiding something | Use plain language; provide specific examples (such as listing the types of data shared with third parties + policy links); provide a simplified summary while retaining detailed terms for reference | Positive:LinkedIn includes a plain-language written summary + a video summary link + full-page "explanations." Counterexample:Ameren was criticized by users as "vague and imprecise, basically saying 'we can do whatever we want'" |
| 2 | Lack of policy overview | Only shows the update time, without stating what was updated | Provide a concise overview at the top of the page (scope, key points, recent updates); attach a brief summary of update content, not just the date | Positive:eBay has a dedicated page summarizing all policies + brief overviews; study participants commented "it's very simple, all questions can be answered on this page." Counterexample:Forever 21 large blocks of text without summaries, perceived as "written for lawyers" |
| 3 | Poor typography | Font too small, large blocks of text without breaks, all caps | Use at least 14pt font; break text into reasonable paragraphs, bold key points; avoid all caps; ensure readability on both mobile and desktop | Positive:Google mobile and desktop pages were praised as "easy" and "straightforward." Counterexample:Instagram long, narrow text columns on mobile waste space;Spotify terms are in all caps, leading users to ask "Why is everything in capital letters?" |
| 4 | Incomplete navigation functionality | Lacks an effective table of contents, making it hard to quickly locate specific content | Provide a clear table of contents + links to specific sections; use left navigation or collapsible menus to simplify finding long content | Positive:Eventbrite legal terms pages are categorized first by audience, then by topic, making it clear who each policy applies to. Counterexample: Although Eventbrite's own privacy policy page has an internal table of contents, it has no information scent and cannot support meaningful navigation |
| 5 | Information not in expected locations | Users are used to finding policy links in the footer or settings page, but some websites do not follow this layout | Add policy links uniformly in the footer; provide policy summaries and links relevant to a feature on related feature pages (such as notification settings) | Positive:Facebook is accessible via multiple routes (main menu/settings menu/top and bottom of the privacy quick page). Counterexample:Clear Care the web application has no footer after login; participants could not find the privacy policy, and searching ultimately yielded no results |
Key insight:Transparency is key — policy pages must be user-centered, using concise language and design to enhance readability. A well-designed policy page not only meets legal requirements but can also increase user trust in the brand. Why: This page naturally has a "low-experience default" (legally led, jargon-heavy), so it is a touchstone for testing whether a team "truly implements IA principles even on edge pages" — the 5 points above are almost all concentrated applications of the earlier IA/navigation/taxonomy/typography principles on one specific page.
Sourced from NNGroup Topics / Information Architecture (6 articles). Usability principles (10 heuristics, discoverability/findability, information scent) and usability testing methods can be found in NNGroup Usability Testing and the 10 Usability Heuristics (Full table of 10 heuristics · Complex application practices · User pleasure hierarchy · Testing methods: 5-user rule/recruitment/remote/task scenarios/step-by-step tasks/attitude vs behavior/4-step analysis/small-sample error/competitive evaluation); platform-level specifications for navigation and system components can be found in Apple HIG Interaction Patterns (25 flow patterns · Onboarding/input/feedback/media/system integration). Images (three IA model diagrams, nngroup.com sitemap, Library of Congress/World Bank faceted navigation, vehicle hierarchical vs faceted taxonomy, polar bear ontology, screenshots of various navigation and privacy policy pages, NOAA icon video) and original files are retained in sources.
Sources and Related Materials
- NNGroup Usability Testing and the 10 Usability Heuristics (Full table of 10 heuristics · Complex application practices · User pleasure hierarchy · Testing methods: 5-user rule/recruitment/remote/task scenarios/step-by-step tasks/attitude vs behavior/4-step analysis/small-sample error/competitive evaluation)
- Apple HIG Interaction Patterns (25 flow patterns · Onboarding/input/feedback/media/system integration)