Information architecture defines how content and functionality are organized, labeled, connected, and found. Begin with user goals and a content inventory, model relationships and metadata, create a hierarchy or faceted structure, and test retrieval with representative tasks. Navigation is one expression of the architecture, not the architecture itself.
Who this is for: UX designers and content teams restructuring navigation, labels, search, or large collections in a digital product.
- Ground structural choices in user goals, vocabulary, content attributes, ownership, and lifecycle evidence.
- Choose hierarchy, facets, cross-links, and search metadata according to real retrieval paths and content relationships.
- Evaluate proposed structures with card sorting, tree testing, search evidence, and content governance checks.
Inventory content and goals
List pages, objects, actions, files, help content, and system states with owner, audience, purpose, format, status, sensitivity, and update cycle. Identify duplicates, gaps, and obsolete material. A navigation redesign built without understanding the underlying collection often gives old confusion a cleaner surface.
Research what people are trying to find or accomplish, the words they use, what they know at entry, and how their route changes by context. Search queries, support cases, interviews, and task observation reveal retrieval needs. Avoid equating the current menu structure with the customer's mental model.
Model relationships and labels
Define content types, attributes, parent-child relationships, sequences, associations, and permissions. Some collections fit a hierarchy; others need facets such as status, owner, date, or region. Use cross-links when one item belongs in several task contexts rather than duplicating content that will drift apart.
Write labels that distinguish siblings, match user vocabulary, and predict destination content. Test ambiguous terms in context. A short label is not automatically clearer, and internal department names rarely explain customer tasks. Establish naming rules for new objects so the architecture stays coherent after launch.
Create retrieval paths
Map common and consequential tasks from likely entry points. Decide what belongs in global navigation, local navigation, contextual links, search, filtering, and saved views. Prioritize a coherent path over exposing every destination at once. Include empty, permission-limited, and no-result states in the retrieval model.
Plan metadata and search behavior alongside visible menus. Synonyms, titles, descriptions, status, and access rules affect whether an item can be found. Search should not become the repair for an incoherent collection, while a strict hierarchy should not force people to know the organization's preferred category before they can begin.
Test and govern the structure
Use open card sorting to explore grouping language, closed sorting to assess proposed categories, and tree testing to evaluate findability without visual design. Each method answers a narrower question. Combine results with task evidence and content constraints rather than letting one similarity matrix decide the architecture automatically.
Assign owners for taxonomy, labels, metadata, archiving, redirects, and quality review. Monitor failed searches, navigation exits, support contacts, and task tests after release. Version structural decisions and migration rules. Information architecture degrades when teams add content without a defined place, relationship, or retirement path.
Restructure a hypothetical policy library
Hypothetical scenario: employees cannot find current travel and expense rules in a growing internal site.
- Inventory hypothetical policies, forms, regional exceptions, owners, effective dates, duplicates, and archived versions.
- Study employee tasks and search language, then model policy topic, region, role, status, and effective date.
- Draft task-based categories with facets and contextual links between a policy and its required form.
- Run card sorting and tree testing, revise ambiguous labels, and assign governance for future policy changes.
Information architecture specification
Document structure and governance beyond a navigation diagram.
- User goals, entry contexts, vocabulary, priority tasks, access needs, and research sources.
- Content inventory, type, purpose, owner, audience, sensitivity, status, duplicates, gaps, and lifecycle.
- Taxonomy, hierarchy, facets, relationships, labels, synonyms, metadata, permissions, and search behavior.
- Navigation paths, contextual links, filters, no-result behavior, migration, redirects, and edge states.
- Card-sort and tree-test evidence, limitations, owners, review cadence, monitoring, and change log.
Common mistakes
- Treating the current site map as a neutral inventory of what users need and how they describe it.
- Forcing every item into one hierarchy when attributes and task contexts support several retrieval routes.
- Launching new navigation without ownership rules for labels, metadata, additions, and archived content.
Try one
Users search for invoices, while the company navigation calls the same records billing documents. What should the architecture team do?
A sound answer checks whether the terms are truly equivalent across tasks, then uses customer vocabulary in labels, synonyms, metadata, or contextual help as appropriate. It tests retrieval in the proposed tree and search system. Renaming one menu item without reviewing related content types, permissions, and sibling labels may create new ambiguity rather than solve findability.
Sources
- Nielsen Norman Group information architecture guideGuidance on organizing, structuring, and labeling digital content for findability.
- Nielsen Norman Group tree testing guideGuidance on evaluating whether people can find content in a proposed hierarchy.