Skip to main content
Interface Atlas
5 min read
Guide

Information Architecture, Content Architecture, and Interface Systems

Why users cannot find your content, and how to build a knowledge graph instead of just designing web pages.

Published
By Interface Atlas Team

Contents

Most usability failures on technical documentation sites are not UI bugs. They are structural failures.

Users arrive with a specific problem, search for a term, land on a page, and immediately lose their bearing. They cannot tell if the document they are reading is a high-level overview, a deep-dive tutorial, or an API reference. They cannot predict where related information lives. The site looks beautiful, but the knowledge is structurally incoherent.

This happens when a team designs an interface before designing the Information Architecture (IA) and Content Architecture.

The Systems That Hold Knowledge Together

To build a publication that actually teaches, you must decouple the structure of your knowledge from the presentation of your knowledge.

  • Information Architecture: How content is categorized, labeled, and mapped so users can find it. It is the mental model of the space.
  • Content Architecture: How content is modeled in the system (schemas, fields, relationships) so it can be managed and retrieved predictably.
  • Interface Systems: The layout, typography, and interactive components that render the structured content to the user.

When these three layers are confused, publications devolve into unnavigable blobs.

The Core Distinction: Taxonomy vs. Navigation

The most common failure mode in technical publishing is confusing Taxonomy with Navigation.

Taxonomy is the backstage categorization of all your knowledge. It is exhaustive. It defines how concepts relate to one another (e.g., “React” is a sub-topic of “Frontend Frameworks”).

Navigation is the user-facing interface for moving through the site. It is curated. It exposes specific paths through the taxonomy based on what users actually need to do.

If you make your navigation an exact 1:1 replica of your taxonomy, you force the user to understand your entire organizational model just to click a link.

graph LR
    subgraph Weak Structure: Navigation = Taxonomy
        N1[Menu: Frontend] --> N2[Menu: Frameworks]
        N2 --> N3[Menu: React]
        N3 --> N4[Menu: Hooks]
    end

    subgraph Strong Structure: Decoupled
        T1[Taxonomy Database] -->|Queries| H1(Topic Hub: React)
        T1 -->|Queries| S1(Search Index)
        
        Nav[Global Nav] -->|Curated Link| H1
        Nav -->|Curated Link| G1(Guides)
    end

The Governing Model: The Content Graph

A modern technical publication is not a hierarchy of folders. It is a graph of relationships.

In Interface Atlas, we model knowledge across four distinct primitives. By separating them, we allow them to link together into a semantic network.

  1. Guides: The long-form teaching layer. They carry a thesis and explain how and why.
  2. Topic Hubs: The synthesis layer. They are not just lists of links; they curate guides and provide the landscape for a broad subject.
  3. Glossary: The definition layer. Short, precise explanations of specific terms, allowing guides to link out instead of bloating their own word counts.
  4. Blog: The chronological layer. Updates, news, and timely thoughts that do not belong in the durable canon.

A Worked Example

Imagine a reader trying to understand “Hydration.”

In a weak (flat) structure: They find a massive 5,000-word page called “React Performance.” Half the page is an API reference, a quarter is a tutorial, and the definition of Hydration is buried in paragraph 14. If they search for “Hydration,” they just get dumped at the top of that massive page.

In a strong (graph) structure:

  1. They search “Hydration” and land directly on the Glossary: Hydration entry.
  2. The glossary entry gives them a 100-word definition, and under “Related Guides,” it links to the Guide: Web Performance as Architecture.
  3. They read the guide. The guide links to the Topic Hub: Performance for further reading.
  4. They explore the topic hub to discover related concepts like Resumability.

The content model enforces the learning path.

Failure Modes to Avoid

  1. The Org-Chart IA: Structuring the documentation based on which internal team wrote it, rather than what the user is trying to accomplish.
  2. Flat Content, No Model: Dumping everything into a generic “Page” CMS type with a single WYSIWYG body field. This prevents you from ever programmatically relating guides to glossary terms.
  3. Interface-First Thinking: Designing a beautiful sidebar before deciding what content types actually need to be navigated.

Applying This to Interface Atlas

We enforce this architecture through our repository structure:

  1. Explicit Schemas: Our content collections dictate that a Guide must have topicKeys and glossaryKeys.
  2. Editorial Hubs: We do not auto-generate topic pages as simple tag lists. Topics are authored files that synthesize the guides beneath them.
  3. Pervasive Linking: A guide without links to the glossary or topic hubs is an orphaned node. The network only works when authors explicitly connect the edges.

Continue your exploration: