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.

在小型产品中，用户通过探索找到操作路径。但在大型应用——多模块SaaS、ERPs、分析平台、交易市场——中，探索式操作不再可行。产品结构本身必须承担导航功能。信息架构就是对这种结构的设计：明确存在哪些内容、如何命名，以及各内容之间的关联关系。

优秀的信息架构是“隐形”的。用户无需思考结构就能找到所需内容。糟糕的信息架构则会让用户时刻在脑中“绘制地图”。

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?

为实体、板块和操作所取的名称，是大型应用中影响最为深远的设计决策之一。糟糕的命名会在用户每次访问时造成认知摩擦。

原则：

**使用用户的词汇，而非工程师的术语。**如果用户称之为“工作任务”，就不要用
```
task_assignment
```
；如果用户称之为“客户”，就不要展示
```
contact_entity
```
。
表述具体。“设置”过于模糊。“账户设置”“工作区设置”“通知偏好设置”能让用户清楚知道自己所处的位置。
**保持一致。**如果侧边栏中称为“Project”，那么面包屑、页面标题、确认弹窗和API错误信息中都必须统一使用“Project”。
**区分相似事物。**如果产品同时有“Users”和“Members”，二者的区别必须有实际意义，且在全产品中保持一致的传达方式。
**按操作效果命名。**用“Archive”而非“隐藏”；用“Publish”而非“保存至线上”；用“Transfer ownership”而非“更换用户”。

命名审核问题：

新用户无需培训就能理解这个术语吗？
这个名称在所有出现的场景中是否保持一致？
这个名称描述的是事物的功能，而非存储方式吗？

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]

UI应直接、清晰地体现底层数据模型。用户通过与产品交互构建心智模型——这个心智模型应与数据的实际运作方式匹配。

**实体与页面一一对应。**每个主要数据实体（Project、Invoice、User、Product）通常都应有独立的列表视图和详情视图。不要为了看似简便而将不同实体合并到同一页面——当某个操作影响到用户未看到的内容时，他们会感到困惑。

**暴露关联关系。**如果Project包含Tasks，且Tasks归属于Users，那么UI层级应反映这种关系：

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

面包屑、父级标签和上下文引用（“此项目中有3个任务”）会从视觉上强化数据关联关系。

**展示转换路径。**UI应明确展示数据在系统中的流转方式。草稿变为已发布；发票从待处理变为已支付；用户晋升为管理员。这些状态转换应清晰可见：

状态标签显示当前状态和可用的转换选项
操作按钮以转换动作命名：“Publish”“标记为已支付”“Promote to admin”
时间线或历史记录展示过往的转换过程

**明确操作范围。**在用户确认操作前，必须让他们清楚知道操作会产生的影响：

“是否归档此项目？”
此操作还将归档47个任务，并从所有仪表盘中移除该项目。
团队成员将立即失去访问权限。
[取消]  [归档项目]

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:

Action type	Example	Dialog required
Permanent deletion	Delete project, remove user	Always
Bulk destruction	Delete all items in a filter	Always
Irreversible state change	Publish, Submit, Send	Yes if no undo
Wide-scope change	Transfer ownership, change billing plan	Always
Account-level action	Cancel subscription, delete account	Always
Permission escalation	Grant admin access	Yes

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)

任何不可逆、影响范围广或会导致数据丢失的操作，在执行前都需要用户明确确认。确认弹窗并非“礼貌性提示”——而是与用户的“契约”。

需要确认弹窗的场景：

操作类型	示例	是否需要弹窗
永久删除	删除项目、移除用户	始终需要
批量销毁	删除筛选结果中的所有项	始终需要
不可逆状态变更	发布、提交、发送	无撤销功能时需要
大范围变更	转移所有权、更改计费方案	始终需要
账户级操作	取消订阅、删除账户	始终需要
权限提升	授予管理员权限	需要

确认弹窗结构：

[标题：具体明确，而非通用表述]
“是否删除项目：Website Redesign？”

[正文：说明范围和后果]
“此操作将永久删除：
• 47个任务
• 3个里程碑
• 所有关联文件

此操作不可撤销。”

[次要操作]  [破坏性主操作]
    [取消]              [删除项目]

规则：

标题要明确指出具体实体——比如“是否删除项目：Website Redesign？”而非“您确定吗？”
正文要准确说明受影响的内容以及操作是否可撤销
破坏性操作按钮要以具体动作命名，而非“确定”或“是”
破坏性操作按钮要在视觉上突出：红色填充，或置于右侧
始终提供“取消”选项，且默认聚焦“取消”（按回车键不应触发删除操作）
对于最高风险的操作（删除账户、不可逆批量操作），要求用户输入实体名称进行确认

无需使用确认弹窗的场景：

保存或更新（自动保存+撤销功能更佳）
离开未保存更改的页面（改用未保存更改提示横幅）
低风险可逆操作（可取消归档的归档操作）

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.

Global Header Consistency. In applications with deep hierarchy, keep the primary header and top-level navigation consistent across all views. Changing the global navigation based on the user's current depth disorients them and removes their easy path back to other content.

Persistent context. In deeply nested views, the user must always be able to answer: where am I, what does this belong to, and how do I get back?

Shallow hierarchy (1–2 layers): Use a simple "← Back to [Parent]" link. Breadcrumbs (Home > Parent > Current) often add unnecessary visual noise for simple structures.
Deep hierarchy (3+ layers): Use breadcrumbs to provide a clear map of the user's location and an easy path to any parent level.

Use parent labels and contextual headers to reinforce the current location.

信息架构最直观的体现就是导航。随着产品规模扩大，导航也必须随之扩展。

**扁平结构更快捷，深层结构更易查找。**主导航层级尽量不超过3级。如果产品需要更多层级，应引入分组和搜索功能，而非增加层级。

**按用户目标分组，而非按产品功能分组。**用户导航是为了完成任务。应围绕用户想要实现的目标来组织导航项，而非按后端架构划分。

错误示例：设置 → 集成 → Webhooks → 事件类型
正确示例：开发者 → Webhooks

**为高级用户逐步展示功能。**主导航中显示最常用的板块。次要功能放在设置、二级导航中，或通过搜索访问。不要将所有功能都放在顶层。

**全局搜索作为“逃生舱”。**在大型应用中，搜索能减轻导航负担。明确知道自己需求的用户，不应需要经过4层导航才能找到目标内容。

**Logo作为首页入口。**产品Logo应始终是可点击的链接，返回主着陆页或仪表板。这是用户的普遍预期——相当于导航的“重置按钮”。

**全局头部保持一致。**在层级较深的应用中，主头部和顶层导航应在所有视图中保持一致。根据用户当前所在层级更改全局导航，会让用户感到困惑，也会切断他们返回其他内容的便捷路径。

**持久化上下文。**在深层嵌套视图中，用户必须始终能回答：我在哪里？这个内容属于什么？我如何返回？

**浅层级（1-2层）：**使用简单的“← 返回至[父级]”链接。对于简单结构，面包屑（首页 > 父级 > 当前页）往往会增加不必要的视觉干扰。
**深层级（3层及以上）：**使用面包屑清晰展示用户的位置，并提供返回任意父级的便捷路径。

使用父级标签和上下文标题来强化当前位置。

information-architecture

Original

Translation