ExplorationmediumIntermediate

Content Tree / Sitemap

Also known as: Site Structure / Navigation Model

Hierarchical structure of information and navigation for a digital product.

What is it

Strategic value

Allows discovering dead ends and structural errors before writing a line of code. Facilitates communication between UX, development and stakeholders through a common visual language.

Category: Information architectureEstimated time: 4-8 hours for medium site (50-100 pages)

The Content Tree (or Sitemap) is a hierarchical visual representation of a digital product's information architecture. It shows how pages, sections, and content are organized and connected through navigation.

What it is for

Define the navigation structure of a digital product
Align the team on information architecture
Identify missing or redundant content
Serve as the basis for navigation and menu design

Research methods that feed it

Card Sorting (open and closed)Tree TestingExisting content analysisMental model interviews

When to make it

When to use it

When designing a website or app from scratch
When restructuring an existing product's navigation
When users report problems finding information
Before designing wireframes or prototypes

When NOT to use it

For very simple products with 3-4 screens
If you haven't researched how users think about structure (do Card Sorting first)
As a final document — it should evolve with the product

How it is made

Required components

Page nodes: rectangles or boxes labeled with each page name
Connectors and arrows: lines showing hierarchical relationships between site areas
Numbering system (identifiers): each page with unique number (e.g. 1.0, 2.0, 2.1, 2.1.1) to link with wireframes and flows

Optional components

○Pagestacks: stacked boxes icon for multiple pages with similar structure
○Decision points (diamonds): when visualization depends on a condition
○Business/user context: varied sizes or color codes to represent priority
○Key/Legend: explanation of symbols, lines and colors
○Rationale: attached document explaining decision reasoning

How to create it step by step

1Content inventory: List all current or planned product content.
2Research mental models: Use Card Sorting to understand how users group information.
3Define hierarchical levels: Organize content into levels (L1: main sections, L2: subsections, L3: pages/screens).
4Map connections: Define relationships between sections and main navigation flows.
5Validate with Tree Testing: Test the structure with users by asking them to find specific information.
6Document and share: Create a visual diagram using tools like Miro, FigJam, or GlooMaps.

Tips for small teams

Start with the 3 most critical flows, don't try to map everything
Use free tools like GlooMaps or Octopus.do
Validate with remote Tree Testing (no lab needed)
Keep maximum 3 depth levels to avoid complexity

Contextualized example

Context: University website redesign.

Before: Navigation organized by department (Admissions, Academic, Administration). Students couldn't find scholarship forms.

Card Sorting revealed: Students group by 'what I want to do': Apply → Study → Pay → Graduate.

New tree: L1: I Want to Apply | My Degree | Financing | Campus Life. Result: 40% fewer support tickets about 'I can't find X'.

How to tell it is done well

Quality criteria

Unambiguous traceability: numbering convention that matches exactly with content matrices, wireframes and test plans
Reinforced information hierarchy: facilitates understanding parent-child relationships and discovering dead ends before coding
Format scalability: for massive sites, can be moved to spreadsheet format sacrificing visual for efficiency

Common mistakes

Organizing by internal company structure instead of user mental model
Creating too many depth levels (more than 3 clicks)
Not validating with real users
Treating the map as a static document

Authority quotes

“In practical terms, user-centered design means the days of designing a site map that mirrors an org chart are over.”
— Visual Vocabulary / JJG

“Any page you identify in your site map should have a number, and your numbering system should allow for subsequent changes as new iterations are created.”
— IA Documentation Standards

“Creating a site structure can seem like a somewhat arbitrary process to the untrained eye, and therefore easy to modify without considering the consequences.”
— Information Architecture