Information Architecture

Information Architecture

Design the structure that holds the content. Stack-agnostic. Applies to marketing sites, product surfaces, knowledge bases, e-commerce, and editorial content.

A well-designed IA makes the rest of the project easier. A poorly-designed IA forces every downstream decision to fight the structure.

When to use

• Designing a new site or major section from scratch
• Restructuring an existing site
• Adding a new content type or category
• Designing site navigation or menu systems
• Defining URL structure and slug patterns
• Building taxonomies or tag systems
• Auditing an existing IA for problems

When NOT to use

• Single-page design (use design-standards)
• Content production (use content-and-copy)
• SEO-driven content planning (use seo-keyword)
• Initial brand and audience discovery (use brand-discovery)

Required inputs

• The site or product scope
• The audience and what they're trying to do
• The content that exists or is planned
• Any constraints (parent IA, regulatory, technical)

If audience is unclear, run brand-discovery first. If content scope is unclear, run content-strategy first.

The framework: 6 layers

Information architecture has six layers. Each builds on the one below.

1. Mental models

Before structure, understand how the audience thinks about the domain.

• What concepts do they group together naturally?
• What words do they use? (Often different from what the company uses.)
• What is the dominant frame of reference? (By task? By role? By topic? By time?)
• What do they expect to find where, based on conventions in similar products?

Methods:

• Card sorting (open or closed): Give the audience the content items, ask them to group them. Open card sorts surface natural groupings. Closed card sorts validate proposed groupings.
• Tree testing: Give a proposed structure, ask users to find specific items. Surfaces where the structure breaks down.
• First-click testing: Given a goal, where do users click first? If first clicks are wrong, the labels and structure are wrong.

2. Sitemap

The map of all pages and how they relate.

Sitemap deliverables:

• A hierarchy diagram showing parent-child relationships
• Indication of page types (static, dynamic, listing, detail)
• Cross-references showing how pages relate beyond the hierarchy
• Sometimes a separate user-flow overlay for key journeys

Sitemap types:

• Hub-and-spoke (cornerstone content + supporting content): Common for content marketing
• Tree (strict hierarchy, every page has one parent): Common for product documentation
• Faceted (content lives in many overlapping categories): Common for e-commerce
• Flat (everything reachable from the home): Common for small sites

Most sites blend types. Pick the dominant pattern and document the exceptions.

3. URL structure

URLs are part of the IA. They are user-facing, indexed by search engines, and shape how content is referenced.

URL principles:

• Reflect the content hierarchy
• Lowercase, hyphen-separated
• Predictable (same pattern across same content type)
• Stable (URLs don't change without redirects)
• Short (under 60 characters where possible)
• Descriptive (slug indicates the content)
• Free of dates unless time-bound
• Free of session IDs and tracking parameters in canonical form

Common patterns:

/                                   home
/[section]                          section landing
/[section]/[subsection]             subsection landing
/[section]/[subsection]/[item]      detail page
/blog                               blog index
/blog/[slug]                        blog post
/blog/category/[category]           category index
/blog/tag/[tag]                     tag index
/products                           product catalog
/products/[category]                category page
/products/[category]/[product]      product detail

Pick a pattern and stick to it. Inconsistent URL patterns confuse users, crawlers, and analytics.

4. Navigation

The chrome that gets users where they need to go.

Primary navigation:

• The top-level structure of the site
• Should reflect what the audience cares about, not what the org chart looks like
• 5 to 7 items maximum (more becomes cognitively heavy)
• Each label is recognizable in 2 to 3 words
• Order matters (left/first gets the most attention)

Secondary navigation:

• Within-section navigation
• Often shown as sidebars, sub-menus, or in-page tabs
• Supports the primary nav, doesn't duplicate it

Utility navigation:

• Account, search, login, support
• Visually subordinate to primary nav
• Often top-right (LTR languages)

Breadcrumbs:

• For nested hierarchies (3+ levels deep)
• Always linked except the current page
• Match the URL hierarchy or the conceptual hierarchy
• Marked up with BreadcrumbList schema

Footer navigation:

• Comprehensive; sometimes includes everything
• Organized by category for findability
• Includes secondary content (privacy, terms, contact)

5. Taxonomy and metadata

The classification system applied to content.

Categories:

• A small, controlled list (typically 5 to 15)
• Mutually exclusive ideal (one item, one category)
• Used for structural navigation

Tags:

• A larger, often growing list (50+)
• Multi-assignment (one item, many tags)
• Used for cross-cutting connections, related-content, and long-tail discovery

Metadata fields:

• Author, date, content type, audience segment
• Whatever is useful for filtering, sorting, and surfacing

Common failures:

• Categories that overlap (item could go in 3 different categories)
• Tags that are unmaintained (sprawl into thousands, become useless)
• Metadata fields that get filled inconsistently
• Different content types using different taxonomies for the same thing (chaos)