Information Architecture

Information Architecture

In small products, users find their way by exploring. In large applications — multi-module SaaS, ERPs, analytics platforms, marketplaces — exploration breaks down. The structure itself must do the navigational work. Information architecture is the design of that structure: what exists, what it is called, and how it relates to everything else.

Good IA is invisible. Users find what they need without thinking about the structure. Bad IA forces users to hold a map in their head.

Naming is Design

The names given to entities, sections, and actions are one of the most consequential design decisions in a large application. Bad names create cognitive friction on every visit.

Principles:

• Use the user's vocabulary, not the engineer's. If users call it a "job", do not call it a task_assignment. If they call it a "client", do not surface contact_entity.
• Be specific. "Settings" is vague. "Account settings", "Workspace settings", "Notification preferences" tell the user exactly where they are.
• Be consistent. If it is called "Project" in the sidebar, it must be called "Project" in the breadcrumb, the page title, the confirmation dialog, and the API error message.
• Distinguish similar things. If the product has both "Users" and "Members", the distinction must be meaningful and consistently communicated.
• Name actions by their effect. "Archive" not "Hide". "Publish" not "Save to live". "Transfer ownership" not "Change user".

Naming audit questions:

• Would a new user understand this term without training?
• Is this name used consistently across every surface it appears?
• Does this name describe what the thing does, not how it is stored?

Internal vocabulary is not customer vocabulary

The terms a company uses internally are frequently not the terms the customer should see. An internal casual shorthand ("the recon job", "a P2 ticket") is precise for the team but opaque to an outsider. When a term crosses from the internal build into the customer-facing app, translate it to the customer's word, or a universally understood one — never ship the internal shorthand by default.

• Introduce as few new terms as possible — a hard ceiling of ~10 invented terms for the whole product, and fewer is always better. Every new coined term is something the user must learn before they can act. Prefer terms so universal that the end user already knows them over anything you'd have to teach.
• Placement tells half the story. Where a feature sits — which section, which nav group, next to what — communicates as much as its label. A well-placed control needs less naming; a well-named control in the wrong place still confuses. Design the location and the name together.

Label length: buttons are terse, titles continue the story

• Buttons: 1 word, ideally — 2 is fine, 3 is the maximum. A button is an action verb, not a sentence. "Save", "Publish", "Invite member".
• Titles and headings carry the fuller explanation. Let the surrounding title, section header, or helper text extend the narrative that the button can only hint at. The button says what; the title says what this whole area is about.

Mental Model Follows Data Model

The UI should be a direct, legible expression of the underlying data model. Users build a mental model of the product by interacting with it — that mental model should match how the data actually works.

Match entities to screens. Each major data entity (Project, Invoice, User, Product) typically deserves its own list view and detail view. Do not collapse distinct entities into one screen because it seems simpler — users will be confused when one action affects something they did not see.

Expose relationships. If a Project contains Tasks, and Tasks belong to Users, the UI hierarchy should reflect this:

Projects
  └── Project: Website Redesign
        └── Tasks
              └── Task: Fix header  [Assigned to: Maria]

Breadcrumbs, parent labels, and contextual references ("3 tasks in this project") reinforce the data relationships visually.

Show transformation paths. The UI should make it clear how data moves through the system. A draft becomes published. An invoice moves from pending to paid. A user is promoted to admin. These state transitions should be visible:

• Status labels that show current state and available transitions
• Action buttons labelled with the transformation: "Publish", "Mark as paid", "Promote to admin"
• Timeline or history showing past transitions

Signal the scope of actions. Before a user commits to an action, they must understand what it will affect:

"Archive this project?"
This will also archive 47 tasks and remove it from all dashboards. 
Team members will lose access immediately.
[Cancel]  [Archive project]

Confirm Dialogs for Dangerous Actions

Any action that is irreversible, affects a wide scope, or causes data loss requires explicit confirmation before execution. The confirm dialog is not a courtesy — it is a contract with the user.

When a confirm dialog is required:

Confirm dialog anatomy:

[Title: specific, not generic]
"Delete project: Website Redesign?"

[Body: scope and consequences]
"This will permanently delete:
• 47 tasks
• 3 milestones
• All associated files

This cannot be undone."

[Secondary action]  [Destructive primary action]
    [Cancel]              [Delete project]

Rules:

• Title names the specific entity — "Delete project: Website Redesign?" not "Are you sure?"
• Body states exactly what will be affected and whether it can be undone
• The destructive action is labelled with the action, not "OK" or "Yes"
• The destructive action is visually distinct: red fill, or positioned on the right
• Cancel is always available and is the default focus (keyboard enter should not trigger deletion)
• For the highest-risk actions (account deletion, irreversible bulk operations), require the user to type the entity name to confirm

What not to use a confirm dialog for:

• Saving or updating (autosave + undo is better)
• Navigation away from unsaved changes (use an unsaved changes warning banner instead)
• Low-stakes reversible actions (archiving with an unarchive option)

Navigation Structure in Large Applications

IA manifests most visibly in navigation. As products grow, navigation must scale with them.

Flat is fast, deep is findable. Aim for no more than 3 levels of hierarchy in primary navigation. If the product requires more, introduce grouping and search rather than more levels.

Group by user goal, not by product feature. Users navigate to accomplish tasks. Group navigation items around what users want to do, not around how the backend is organised.

Bad:  Settings → Integrations → Webhooks → Event types
Good: Developer → Webhooks

Progressive disclosure for power users. Show the most-used sections in primary navigation. Secondary features live in settings, secondary nav, or are reached via search. Do not surface every feature at the top level.

Global search as escape hatch. In large applications, search reduces the navigation burden. Users who know what they want should never have to navigate through 4 levels to find it.

Logo as Home. The product logo should always be an interactive link leading back to the primary landing page or dashboard. This is a universal user expectation — a "reset button" for navigation.