Information Architecture Patterns: Design for Findability, Not Menus

An information architecture can look tidy and still be impossible to navigate.

The menu has balanced columns. The labels survived stakeholder review. Every feature has a home. Yet a customer looking for an unpaid invoice searches under “Billing”, checks “Reports”, and gives up one screen away from it.

The structure is internally coherent. The route does not match the cue the customer started with.

That is the useful way to judge an IA pattern. Not by how elegantly it arranges the product, but by whether it creates predictable routes from a real starting point to a useful destination.

A pattern is a response to a finding problem

Hierarchy, facets, hubs, search, recents, and contextual links are not competing aesthetics. Each solves a different finding problem.

A hierarchy works when people understand a stable parent–child relationship. Facets work when the same set of objects must be narrowed by several independent attributes.

A hub works when people repeatedly return to one context before choosing the next action. Search helps when they know enough about the destination to express a useful query.

The mistake is selecting one of these patterns before describing how people will look for the thing.

“Use a sidebar” is not an IA decision. “Let an account manager move from a customer to its open renewals without knowing which team owns the workflow” is.

Write a retrieval brief before drawing navigation

A retrieval brief is a compact specification for one important finding task. The name is a practical synthesis, not an industry standard.

For each task, capture:

• the person’s current context;
• the object, action, or answer they need;
• the words and visible cues they are likely to recognise;
• what they probably know and do not know;
• the first destination that would count as progress;
• a credible wrong turn;
• the route back after that wrong turn;
• any permission, state, or device constraint that changes the route.

Consider an administrator who needs to remove access from a former contractor. They may start with the person, the workspace, security settings, or a recent activity record.

Those starting points imply different routes to the same controlled action. Forcing the administrator to remember that the owning team named the feature “Identity lifecycle” is a recall test, not a design.

Research should establish the language and context in the brief. GOV.UK guidance recommends observing what people are trying to do, how they do it now, and where they struggle—not treating internal opinion as user evidence.

Behavioural differences also matter. The work on evidence-backed user archetypes is useful when frequency, domain knowledge, responsibility, or risk changes how someone searches.

Choose an organising principle by its failure mode

Every structure makes some relationships obvious and hides others. Choose the loss deliberately.

Hierarchy: one primary place, cheap orientation

Use hierarchy when items have a defensible parent and users benefit from understanding location. It gives browse paths, scope, and orientation.

It fails when an item belongs equally in several branches or when teams keep adding intermediate categories to settle ownership disputes.

Breadcrumbs can expose a hierarchy, but they cannot create one. The GOV.UK Design System explicitly advises against breadcrumbs for flat structures or as progress indicators in a linear transaction.

Facets: several valid questions about one set

Use facets when people need to narrow a collection by dimensions such as status, owner, date, risk, or region.

Facets depend on reliable metadata. If “owner” is missing, “status” means different things across teams, or permissions alter counts silently, the interface promises distinctions the data cannot support.

This is where IA touches system design. A useful view may require authoritative fields, defined freshness, and explicit permission behaviour.

Those choices belong beside the product promise in system design.

Hub and spoke: repeated work inside a stable context

Use a hub when people repeatedly orient around an object such as an account, project, patient, or incident, then enter specialised workflows.

The hub fails when it becomes a dashboard-shaped dumping ground. Each spoke needs a reason to be reached from that context, not merely a team asking for visibility.

Search: direct access for a describable destination

Search is strong for known items, large collections, and vocabulary that people can express. It is weaker when they do not know what exists or use language absent from the index.

Search therefore needs aliases, useful metadata, forgiving query handling, and results that explain why they match. A search box cannot compensate for an undefined object model.

Design a finding system, not one perfect route

People arrive with different knowledge. One may know the object’s name. Another knows its category. A third only knows the task they want to complete.

WCAG 2.2 reflects this difference. Its “Multiple Ways” criterion requires more than one way to locate a page within a set, apart from steps in a process.

For a complex product, the practical combination may include:

• browse for understanding the available space;
• search for direct retrieval;
• contextual links for moving between related objects;
• recents or favourites for repeated work;
• breadcrumbs or parent links for orientation;
• a safe return route when access or state changes.

Multiple routes should converge on the same concepts. If navigation says “Members”, search returns “Users”, and an empty state recommends “People”, the product creates three vocabularies for one object.

W3C requires repeated navigation to keep the same relative order unless a person initiates the change.

It separately requires components with the same functionality to be identified consistently across a set of pages.

Consistency is not cosmetic here; it lets knowledge earned in one area transfer to another.

Test the structure before testing the interface

Visual polish can rescue a weak test session by adding icons, placement, or familiarity. Test the structure without those cues first.

Turn retrieval briefs into tasks. Give participants the context and desired outcome without quoting the destination label. Ask where they would go, record the route, and probe what each label suggested.

Tree testing is useful for this stage because it isolates labels and hierarchy. Measure more than eventual success:

• the first branch chosen;
• direct versus recovered success;
• destinations mistaken for the answer;
• backtracking and repeated branches;
• labels interpreted in incompatible ways;
• tasks that succeed only after guessing.

Do not mistake a tree test for a finished usability verdict. A 2025 study comparing tree-test variants with a high-fidelity prototype found that tree representation affected navigation behaviour.

Use the test to diagnose structural risk, then test the proposed navigation in a realistic workflow with permissions, data, search, responsive behaviour, and interruptions present.

Information-scent research offers a helpful lens: people follow cues that appear likely to move them towards their goal. A route can be structurally short yet feel unsafe when its labels provide weak scent.

Instrument the cost of getting lost

A single page-view funnel rarely explains findability. Add signals that reveal failed retrieval and recovery.

Useful events include:

• a search immediately after opening navigation;
• repeated query reformulation;
• zero-result and low-result searches;
• returning to the same parent after visiting a child;
• switching between sibling sections before an action;
• use of an old bookmark or retired URL;
• support contacts that ask where something is;
• abandonment after a permission or empty state.

Interpret combinations, not isolated counts. High search use may mean navigation failed, or that search is the fastest route for expert users. Backtracking may signal confusion, or healthy comparison.

Segment by task, role, tenure, device, and permission where those differences affect the route. The average can hide a structure that works for administrators and fails for occasional collaborators.

Define the decision before collecting more telemetry.

Assumption mapping can expose whether the team is testing label comprehension, object relationships, or the cost of changing an established route.

Treat an IA change as a product migration

Moving a destination changes learned behaviour. It may also change URLs, bookmarks, deep links, permissions, analytics continuity, help content, onboarding, and support scripts.

Write a migration map before release:

Existing route	New route	Continuity mechanism	Owner	Retirement signal
Old navigation label	New label and parent	Temporary alias or pointer	Product/design	Direct retrieval is stable
Saved URL or deep link	New destination	Redirect or route resolver	Engineering	Old traffic is negligible and understood
Search vocabulary	New canonical term	Synonyms and query mapping	Search/content	Users adopt the new term without failed queries

Keep recovery visible long enough to learn. An immediate hard removal makes a clean interface and dirty evidence: the team sees fewer uses of the old route because it no longer exists, not because people understood the new one.

Large changes deserve explicit stop conditions. If critical tasks lose direct success, support demand rises, or a permission state creates a dead end, the team should know whether to restore the route, add an alias, or revise the structure.

Give IA an owner and a change rule

Information architecture decays through reasonable local decisions. A team adds one shortcut. Another invents a synonym. A third creates a new parent because no existing category fits its feature.

Avoid a central committee reviewing every label. Instead, record the structural decisions that create future constraints:

• the canonical name and meaning of key objects;
• the organising principle used at each level;
• routes that must remain available;
• allowed exceptions and their expiry;
• evidence required for a new top-level destination;
• the person accountable for cross-product coherence.

Review the IA when the object model changes, a route serves a new population, permissions split the experience, findability signals deteriorate, or several exceptions accumulate around the same concept.

The durable asset is not the current menu. It is the agreement between user language, product objects, and recoverable routes—and the team’s ability to revise that agreement without making people relearn the product blindly.

Sources

• W3C: WCAG 2.2 — Multiple Ways
• W3C: WCAG 2.2 — Consistent Navigation
• W3C: WCAG 2.2 — Consistent Identification
• GOV.UK Service Manual: Learning about users and their needs
• GOV.UK Design System: Breadcrumbs
• Information and Software Technology: Validation of information architecture — cross-methodological comparison of tree testing variants and prototype user testing
• CHI: Using information scent to model user needs and actions on the web

Read next

• A Practical Guide to User Archetypes
• From Theory to Practice: System Design for Product Managers
• How to Approach Assumption Mapping Systematically