After user journeys have been defined, the project has a clear understanding of the outcomes users must achieve within the system. Journeys describe the sequence of actions a user takes to complete a goal and connect multiple capabilities into meaningful workflows. But journeys alone do not describe how the system is organized. Before interface design begins, the delivery team must answer a different question: Where do these journeys actually happen within the system? The artifact that answers this question is the information architecture.
What Information Architecture Defines
Information architecture describes the structural organization of a system — the types of pages or views that exist, how those pages relate to each other, how users move between them, and how content and data are organized. In simple terms, it describes the structure of the system's environment. If user journeys describe movement, information architecture describes the space in which that movement occurs.
The Gap Between Journeys and Design
Many teams move directly from journey mapping to visual design. Designers begin sketching layouts, navigation elements, and interface patterns, and engineers soon follow with implementation work. But when design begins before information architecture is defined, the structure of the system emerges implicitly rather than intentionally. Pages appear because they were needed for a specific screen design. Navigation evolves as new features are introduced. Content relationships are discovered gradually as the system grows. This approach often produces confusing navigation, duplicated content structures, and inconsistent user flows. Information architecture prevents this drift.
Pages, Not Screens
One important distinction in information architecture is the difference between pages and screens. A screen represents a specific visual layout; a page represents a conceptual location within the system. A system might include page types such as a homepage, article page, search results page, user dashboard, content editor, or product listing page. Each page type may have multiple layouts across devices, but the underlying structure remains the same. By defining these page types before visual design begins, the team stabilizes the structural foundation of the system.
Navigation as Structure
Information architecture also defines the navigation model of the system — how users enter it, how they move between sections, how they discover related content, and how they return to important destinations. A well-defined navigation structure helps ensure that journeys remain efficient and understandable. Without a clear architecture, navigation often evolves organically during design, leading to systems that feel inconsistent or difficult to explore.
Content and Entity Relationships
Many modern systems manage complex content and data relationships: articles relate to authors, products belong to categories, events connect to locations and participants. Information architecture defines these relationships at a structural level. Understanding them early helps ensure that content models and data structures align with the intended user experience — when these relationships are discovered late, they can require significant redesign of both the interface and the underlying system.
Information Architecture in the Artifact Chain
Within the artifact chain, information architecture translates journeys into structural form:
Journeys describe what users must accomplish. Information architecture defines where those actions occur within the system. Design then determines how those locations appear and behave visually.
Structure Before Interface
Information architecture often receives less attention than visual design because it is less visible — it focuses on structure rather than aesthetics. But strong architecture makes good design possible. Without a clear architecture, each stage of delivery interprets the system differently: design introduces new pages to support visual layouts, development introduces additional routes to support features, and content structures evolve independently of navigation. Over time, the system becomes difficult to understand. A defined architecture anchors the structure early, and every later artifact — from component inventories to development tickets — builds on the same structural model. Software systems become easier to design, implement, and maintain when their structure is defined before their appearance.