information-architecture

信息架构

在小型产品中，用户可以通过探索找到方向。在大型应用中——多模块 SaaS、ERP、分析平台、市场平台——探索就行不通了。结构本身必须承担导航工作。信息架构就是对这种结构的设计：包含什么、如何命名，以及各部分之间如何关联。

好的信息架构是隐形的。用户无需思考结构就能找到所需内容。糟糕的信息架构会迫使用户在脑海中记住一张地图。

---

命名就是设计

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

原则：

• 使用用户的词汇，而不是工程师的词汇。 如果用户称它为“工作”，就不要叫它 task_assignment。如果用户称它为“客户”，就不要显示 contact_entity。
• 具体明确。 “设置”很模糊。“账户设置”“工作区设置”“通知偏好”能让用户确切知道自己身在何处。
• 保持一致。 如果侧边栏中称为“项目”，那么面包屑、页面标题、确认对话框和 API 错误消息中也必须称为“项目”。
• 区分相似事物。 如果产品同时有“用户”和“成员”，两者的区别就必须有实际意义，并且始终清晰传达。
• 根据操作效果命名。 用“归档”，而不是“隐藏”。用“发布”，而不是“保存到线上”。用“转移所有权”，而不是“更改用户”。

命名审查问题：

• 新用户不经培训就能理解这个术语吗？
• 这个名称在所有出现的位置都保持一致吗？
• 这个名称描述的是事物能做什么，而不是它如何存储吗？

内部词汇不等于客户用语

公司内部使用的术语通常不应展示给客户。内部随意使用的简称（“重对账任务”“P2 工单”）对团队来说很明确，对外部人士却晦涩难懂。当某个术语从内部构建流程进入面向客户的应用时，应将其转换成客户使用的词，或普遍理解的词——绝不要默认直接使用内部简称。

• 尽可能少引入新术语——整个产品中自创术语最多约 10 个，而且越少越好。 用户每学会一个新造词，才能多进行一项操作。优先使用终端用户已经熟悉的通用术语，而不是需要专门教授的词。
• 位置能传达一半的信息。 功能所在的位置——属于哪个版块、哪个导航组、靠近什么内容——传达的信息不亚于它的标签。位置合理的控件不需要太多命名；名称再好的控件，放错位置仍然会令人困惑。应当同时设计位置和名称。

标签长度：按钮简洁，标题延展说明

• 按钮：理想情况下为 1 个词——2 个词也可以，最多 3 个词。 按钮是动作动词，不是句子。“保存”“发布”“邀请成员”。
• 标题和标题层级负责提供更完整的说明。 让周围的标题、版块标题或辅助文本补充按钮只能暗示的内容。按钮说明做什么；标题说明整个区域是关于什么的。

---

心智模型遵循数据模型

UI 应直接、清晰地呈现底层数据模型。用户通过与产品交互来建立对产品的心智模型——该模型应与数据的实际运作方式一致。

让实体对应页面。 每个主要数据实体（项目、发票、用户、产品）通常都应有自己的列表视图和详情视图。不要因为看起来更简单就把不同实体合并到一个页面中——当某项操作影响了用户看不到的内容时，他们会感到困惑。

展现关系。 如果一个项目包含任务，而任务属于用户，那么 UI 层级应体现这种关系：

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

面包屑、父级标签和上下文引用（“此项目中有 3 个任务”）能以可视化方式强化数据关系。

展示转换路径。 UI 应清楚地说明数据如何在系统中流转。草稿变为已发布，发票从待处理变为已付款，用户被提升为管理员。这些状态转换应清晰可见：

• 显示当前状态和可用转换的状态标签
• 标明转换操作的按钮：“发布”、“标记为已付款”、“提升为管理员”
• 显示过往转换的时间线或历史记录

明确操作范围。 用户确认操作前，必须了解该操作会影响哪些内容：

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

---

危险操作的确认对话框

任何不可逆、影响范围广或会造成数据丢失的操作，都必须在执行前明确确认。确认对话框不是客套——而是与用户之间的约定。

需要确认对话框的情形：

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

确认对话框的组成：

[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]

规则：

• 标题应明确指出具体实体——“删除项目：网站改版？”而不是“确定吗？”
• 正文应准确说明会影响哪些内容，以及是否可以撤销
• 破坏性操作的按钮应标明具体操作，而不是“确定”或“是”
• 破坏性操作按钮应在视觉上突出：使用红色填充，或放在右侧
• 始终提供取消选项，并将其设为默认焦点（按键盘 Enter 不应触发删除）
• 对于风险最高的操作（删除账户、不可逆的批量操作），要求用户输入实体名称以确认

不应使用确认对话框的情形：

• 保存或更新（自动保存并支持撤销更好）
• 离开有未保存更改的页面（应改用未保存更改警告横幅）
• 风险较低且可撤销的操作（例如可取消归档的归档操作）

---

大型应用中的导航结构

信息架构（IA）最明显地体现在导航中。随着产品发展壮大，导航也必须随之扩展。

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

按用户目标分组，而不是按产品功能分组。 用户通过导航来完成任务。应围绕用户想做的事来组织导航项，而不是按照后端的组织方式来分组。

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

为高级用户提供渐进式披露。 在主导航中展示最常用的部分。次要功能放在设置、次级导航中，或通过搜索进入。不要在顶层展示所有功能。

将全局搜索作为备用入口。 在大型应用中，搜索可以减轻导航负担。知道自己要找什么的用户，不应需要通过 4 层导航才能找到它。

将 Logo 设为主页入口。 产品 Logo 应始终是可交互的链接，指向主落地页或仪表板。这是用户普遍的预期，也是导航的“重置按钮”。

保持全局页眉一致。 在层级较深的应用中，所有视图中的主页眉和顶层导航都应保持一致。根据用户当前所在的层级来更改全局导航，会让用户迷失方向，也会让他们失去返回其他内容的便捷途径。

保持上下文可见。 在深层嵌套的视图中，用户必须始终能够回答：我在哪里？这里属于什么？我该如何返回？

• 浅层级（1–2 层）： 使用简单的“← 返回[上级]”链接。对于简单结构，面包屑（主页 > 上级 > 当前页面）往往会带来不必要的视觉干扰。
• 深层级（3 层及以上）： 使用面包屑，清楚标示用户所在位置，并提供返回任意上级层级的便捷途径。

使用上级名称和上下文页眉来强化当前位置。

让结构在不断扩展时依然清晰

信息架构很少因一次决策就崩坏，而是逐渐磨损：每新增一个页面，就把链接放到看起来最近的位置；几次发布之后，菜单就变成了一张没人绘制过的楼层平面图。如果在产品中穿行就像在购物中心里迷路，每条走廊都通向更多走廊，同一家店还出现在三层楼，那么结构就已经失效了。购物中心希望人们闲逛，因为这样有利可图；网站或应用则不然。

不要随意改动结构。 访客学会各项内容的位置后，就会依赖这种熟悉感。移动、重命名或重新归类导航内容，会让他们之前的学习付诸东流，所以只有为了客户才做出改变，而不要仅仅因为新功能需要一个位置。

• 一个目标，只放一处。 一个页面出现在两个菜单下，会让用户疑惑它们是不是两项不同的内容。选好它所属的分组，然后只链接一次。其他路径应放在页面内容中，而不是导航中。
• 一个目标，只用一个名称。 一个菜单里写着 “Quickstart”，另一个菜单里写着 “CLI”，但都指向同一个页面，看起来就像两个页面。两个名称相同、内容不同的页面也是如此。
• 每一层只采用一种分组原则。 顶层可以按任务、受众或对象分组，但要始终如一。一个菜单按任务排序，旁边的菜单按角色排序，相当于重复回答同一个问题，也让每个条目都能同时归入两组。
• 每个标签只用一次。 顶层菜单和另一个菜单中的列不得使用相同名称。
• 添加条目是有成本的。 在导航中添加新链接之前，先决定它会替代什么，或会扩展哪个现有分组。如果它无处可归，说明分组方式有问题；新增一个兜底栏目也解决不了。
• 数一数。 每组大约七个条目、总共几个分组，是人们可以快速浏览的规模。超过这个规模，用户就会从使用菜单变成阅读菜单；长尾内容应交给搜索或落地页。

检查结构是否偏移。 列出所有导航链接及其目标，并按目标排序。每个重复出现的目标和每个重复出现的标签，都是一项发现。

---

隐藏，而非删除——但也别直接呈现出来

当某项功能或控件增加了界面复杂度，但仍有一部分用户需要它时，你有三种选择，而不是两种。错误在于把它当成“显示”或“移除”的二选一。

1. 直接呈现 — 主要内容，始终可见。只将主用户路径上的操作放在这里。
2. 移除 — 如果某个控件不值得占用空间，也没有用户流程依赖它，就删掉它。更少、更清晰的控件，胜过完整却杂乱的界面。
3. 藏在可展开或可收起的元素后面 — 这是折中方案，而且往往是正确选择。将次要功能移入模态框、抽屉、手风琴、弹出框或可展开面板中：能够发现，但不会立即呈现。 用户只需一次交互即可访问该元素，因此默认视图仍然清爽。

有意增加摩擦也是一种功能。 在用户需要时再显示选项——不要预先加载所有选项。这与 H1–H3 层级规范（参见 modular-scale-typography）遵循的是同一种思路：当视图出现更深层次的层级时，将次要层级放入可展开或可收起的元素中。

根据内容的分量选择容器：手风琴／可展开区域适用于用户在当前位置阅读的内嵌详情，弹出框／抽屉适用于简短的次要任务，模态框适用于需要打断当前流程的专注子任务或确认操作。

比较的每个维度只用一个词

随时间的变化和同类对象之间的差异是两个问题。分别使用各自的词汇，绝不要在同一张卡片中用一个词同时表达两者：如果标题用 “heavy drift” 表示同类对象之间的差异，而各行又用 “drift: 3 changes” 表示每个对象相较自身过去的变化，就会让人无法理解。

---

审查清单

• 实体名称是否源自用户使用的词汇，而非系统术语？
• 在所有界面（导航、面包屑、对话框、错误提示）中，是否始终使用同一个名称？
• UI 层级是否反映了数据模型层级？
• 数据状态转换（草稿 → 已发布、待处理 → 已付款）是否清晰可见并标注明确？
• 每项操作是否都在用户确认前说明了其影响范围？
• 所有不可逆或影响范围较大的操作是否都有确认对话框？
• 确认对话框是否写明了具体实体并列出后果？
• 确认对话框中的破坏性操作是否标注了具体操作，而非“确定”？
• 确认对话框中是否默认聚焦“取消”？
• 主导航是否按用户目标分组，而非按产品功能分组？
• 每个目标页面是否只在导航中出现一次，且名称唯一？
• 每一层导航是否遵循单一的分组原则？
• 最近添加到导航中的项目是否扩展了现有分组，而非新建一个兜底分组？
• 导航层级超过 3 层的产品是否提供全局搜索？
• 产品 Logo 是否链接回落地页或主仪表板？
• 无论层级深浅，所有视图中的主标题栏和全局导航是否保持一致？
• 对于层级较浅（1–2 层）的结构，是否使用返回链接；对于层级较深（3 层以上）的结构，是否使用面包屑？
• 如果某个视图同时比较随时间的变化和同类对象之间的差异，是否分别为两个维度使用不同的词语？