Information Architecture and Navigation
LESSON
Information Architecture and Navigation
By the end of this lesson, you will be able to...
Turn real user questions into an information structure instead of copying an organization chart.
Separate the content model, navigation paths, search vocabulary, and ownership rules that work together in a product.
Compare an information architecture under search, exploration, permissions, and growth constraints.
Idea in one sentence: Good navigation gives users a path through the concepts they use, while the system keeps ownership and implementation details behind that path.
Core Insight
Imagine Marta, a support lead, opens an internal operations portal. A customer asks for a partial refund on the last invoice. Marta knows the customer, the order number, and the result she needs. She does not know which team owns the invoice service.
The portal's top navigation is:
Platform | Core Services | Growth | Finance | Trust | Developer Tools
The invoice is under Finance. The order is under Growth. Refund permissions are managed by Trust. The audit record is exposed by Core Services.
Marta opens three sections, searches for “partial refund,” and finds two results with different names. The content exists. The portal still makes the answer expensive to find.
This is an information-architecture problem, not only a navigation-color problem.
The user asks a question about a customer task. The portal asks her to reconstruct the company's ownership model. That translation cost is the pressure that makes a better structure necessary.
The Naive Model: Mirror the Organization
A reasonable first design is to make the top-level navigation match the teams that build and maintain the product:
Finance owns invoices, so invoices belong under Finance. Trust owns permissions, so refund controls belong under Trust.
This model has real benefits. It is easy for teams to maintain. Ownership is visible. A new employee can guess where a feature came from. Permissions and support escalation may already follow the same boundaries.
It breaks when users do not think in team names. Marta thinks:
Find the invoice, check the order, issue the partial refund, and leave an audit trail.
She does not need to know whether those actions cross three service boundaries. The system can preserve that ownership behind the experience.
The stronger model is not “ignore teams.” It is:
Organize the visible path around user questions and stable concepts. Keep ownership, permissions, and implementation boundaries as supporting metadata.
A Plain-to-Precise Bridge
Plain meaning:
Information architecture is the product's arrangement of concepts, labels, relationships, and paths so people can find, understand, and act on information.
In Marta's scenario:
The portal needs a stable way to connect a customer, an order, an invoice, a refund, and an audit record. Marta should be able to begin with the question “How do I refund this invoice?” and reach the related objects without learning team ownership first.
Technical terms:
- A content model names the objects, states, actions, and relationships the product supports.
- Navigation exposes some of those relationships as paths, menus, links, breadcrumbs, or contextual entry points.
- Findability is the user's ability to locate the right object or action with reasonable effort.
- Information scent is the evidence in a label, grouping, or result that tells the user “this path is likely to lead to what I need.”
These pieces are related but not identical. A correct content model can still have poor navigation. A good menu can still fail if search uses different words from the user. A search result can find an object while leaving the user unable to understand what it is or what action is safe.
The Four Moving Parts
1. Questions and tasks
Start with the questions people ask, not with the screens the team already built.
Examples from the portal:
- “Why did this customer's payment fail?”
- “Can I issue a partial refund?”
- “Which invoices are still unpaid this month?”
- “Why did the webhook stop arriving?”
These questions reveal outcomes, not implementation. They are useful because they can be tested with people who do not know the organization chart.
2. Objects and relationships
A question becomes easier to support when its objects are explicit:
Customer -> Order -> Invoice -> Payment
|
-> Refund -> Audit record
The relationship matters. A refund is not just a menu item. It is an action on a particular invoice or payment, with a state, permission, amount, and audit consequence.
3. Labels and vocabulary
Users need labels that match how they describe the object or task. Teams may use “credit adjustment,” “reversal,” and “partial refund” for related operations. The interface should choose a primary label, expose useful synonyms to search, and explain differences where they matter.
Changing a label is not cosmetic if the old label sends people down the wrong path.
4. Paths and entry points
One object may be reachable from several legitimate questions. Marta might start from a customer, an order, an invoice list, or a support case. These paths should converge on the same canonical object instead of creating duplicate copies with different permissions or stale data.
Multiple paths do not mean that every menu should contain everything. They mean the design should recognize how users enter the problem.
A Small Design Method
Use this sequence when a product feels like a hallway of team names.
Step 1: Collect real questions
Write ten to twenty recent questions from support tickets, search logs, chat messages, or observation. Keep the user's words. Do not translate them into team names yet.
For Marta, “partial refund on last invoice” is stronger evidence than “Finance workflow.”
Step 2: Extract objects, actions, and states
Underline nouns and verbs. Then name the state that changes the action.
Object: invoice
Action: issue partial refund
State: paid, partially refunded, fully refunded, disputed
Constraint: permission and remaining refundable amount
Evidence: payment record and audit trail
The state matters because “refund invoice” means different things when the invoice is unpaid, already refunded, or under dispute.
Step 3: Cluster by user questions
Group related questions by the work people are trying to do:
Investigate a customer problem
Manage money and refunds
Monitor integrations
Review reports and trends
Manage access and trust
These clusters are hypotheses, not final categories. Test whether users can predict what belongs in each group.
Step 4: Choose labels and alternate paths
Choose a primary label that is concrete and stable. Add synonyms to search and contextual links where users enter through another object.
For Marta:
Billing -> Invoices -> [invoice] -> Refund
Customer -> [customer] -> Orders -> [order] -> Invoice
Support case -> Related payment -> [invoice]
All paths lead to the same invoice and refund operation. Ownership remains visible in audit details and escalation information, not as the first obstacle.
Step 5: Test the path with a task
Give someone a task without explaining the structure:
Find the latest invoice for customer 1842 and issue a refund for only the undelivered item.
Watch where they look, what they call the object, what they expect to happen, and where they hesitate. A path that appears obvious to its author may have weak information scent for everyone else.
Worked Example: Three Designs for the Same Portal
Use Marta's refund question as the input and trace what changes.
| Stage | Team-shaped portal | Task-shaped portal | What the system must preserve |
|---|---|---|---|
| Input | “I need a partial refund.” | Same user question. | Customer, order, invoice, amount, permission, and audit context. |
| Transition | Marta chooses Finance, then searches for a term used by Trust. | Marta chooses Billing or opens the customer/order context. | A canonical invoice and refund action. |
| Intermediate state | She sees several similarly named tools and cannot tell which owns the current invoice. | She sees the invoice status, refundable balance, related order, and available action. | State and authorization still come from the underlying services. |
| Decision | She asks a colleague or guesses which tool changes the real record. | She selects the undelivered item, enters an amount, and reviews the consequence. | The product validates amount, permission, and mutation before committing. |
| Output | The content exists, but search and cross-team translation consume time. | The user reaches the right object through a recognizable path. | Ownership and auditability remain intact behind the navigation. |
| Naive failure contrast | “Put each feature under its owning team.” | “Expose stable user concepts and connect them to owners.” | A simpler menu must not erase permission or state boundaries. |
The task-shaped design is not automatically correct. Its labels still need testing. “Billing” may be clear to finance staff but unclear to support agents. “Refunds” may be better as a direct action under an invoice. Information architecture turns those choices into visible hypotheses.
So far, the main mechanism is this:
user question -> object and state -> label and path -> action -> evidence of success
The organization chart can support the mechanism. It should not replace it.
Search and Navigation Are Partners
Teams often respond to bad navigation by adding search. Search is valuable, but it does not remove the need for structure.
Search works best when users know what to ask, when synonyms are indexed, and when results explain object type, state, and context. Navigation works best when users are exploring, learning the product, or deciding which concept matches their problem.
A user who searches “partial refund” should find invoices and refund actions. A user who only knows “the customer was charged twice” needs a path from the customer or order to the payment history. The two entry modes should converge on the same object model.
The trade-off is depth versus exploration. More levels can reduce the number of choices at each step, but deep paths increase backtracking and hide alternatives. A flat list makes everything visible, but forces the user to scan and remember more. Choose the structure that lowers the next decision's cost, then test it with real tasks.
Common Confusions
Confusion: user questions are just personas in disguise
Why it is tempting:
Both can be written as statements about a person.
Better model:
A persona summarizes context and behavior patterns. A user question names the work the product must help someone complete. One persona can have many questions, and different roles can share one question.
Confusion: ownership does not matter
Why it is tempting:
Team labels create the original problem, so removing them feels like the solution.
Better model:
Ownership still matters for permissions, maintenance, escalation, and accountability. It belongs in supporting information and operational paths, not necessarily at the top of every user task.
Confusion: search makes navigation unnecessary
Why it is tempting:
Search can jump directly to a result.
Better model:
Search helps with known or guessable targets. Navigation teaches the product's concepts and supports exploration. Both need the same vocabulary and canonical objects.
Confusion: fewer categories always means simpler architecture
Why it is tempting:
A short menu looks calm.
Better model:
Fewer categories can increase ambiguity. Simplicity means reducing the user's next decision, not merely reducing the number of labels.
Check Your Understanding
Check: A product team proposes top-level menus named Payments, Risk, Growth, and Infrastructure. What should you ask before approving them?
Think first, then reveal.
Answer: Ask which real user questions each menu helps answer, whether users recognize the labels, and whether one task must cross several team boundaries. The names may be useful for ownership, but they are not evidence of findability.
Check: A search result finds an invoice by ID but does not show its customer, payment state, or remaining refundable amount. Is the information architecture solved?
Think first, then reveal.
Answer: No. The result solves retrieval but not understanding or safe action. The object needs enough relationship and state context for the user's next decision.
Practice: Rebuild a Support Portal Entry Path
A support portal contains these items:
Refund service
Order ledger
Customer profile
Payment attempts
Webhook deliveries
Monthly revenue export
Access policy
Incident timeline
Support agents ask:
- “Why was this customer charged twice?”
- “Can I refund only the missing item?”
- “Did the fulfillment partner receive the order?”
Design a first-pass information architecture.
Your answer should:
- name the user-facing groups or entry points;
- map each question to objects, states, and actions;
- choose one primary label and at least one useful search synonym;
- show one alternate path that starts from a customer or order;
- preserve ownership, permissions, and audit context behind the user path;
- identify one task you would test before treating the structure as successful.
A good answer is not judged by matching one menu exactly. It should make the user's question visible, reduce unnecessary team-boundary translation, and keep enough context for a safe action.
Resources
- [ARTICLE] Information Scent — Focus: Notice how labels and groups signal whether a path is likely to answer the user's question.
- [ARTICLE] Card Sorting — Focus: Use a small sorting exercise to test whether users group concepts the way the proposed navigation assumes.
- [TUTORIAL] GOV.UK Contents List — Focus: Study a restrained navigation pattern that supports orientation without becoming the whole information architecture.
Key Takeaways
- Start with the questions and tasks users bring, then model the objects, states, actions, and relationships behind them.
- Navigation, search, labels, and ownership are different layers; they should agree without being identical.
- Multiple entry paths can converge on one canonical object instead of creating duplicate records and confusing permissions.
- The trade-off is structure versus exploration: deeper grouping can reduce scanning but increase backtracking and hidden choices.
- Test information architecture with real tasks before treating a tidy menu as evidence of findability.
← Back to Product Design, UX, and Interface Foundations