information-architecture-navigation

信息架构导航

目的

帮助 Agent 更轻松地查找、浏览和理解信息。将信息架构视为一个由组织方式、标签、导航、搜索、元数据、内容结构和寻路方式构成的产品系统。在视觉样式之前，优先优化用户任务的完成和理解。

何时使用此技能

当用户要求你执行以下任务时，使用此技能：

• 评审或重新设计导航、菜单、面包屑、选项卡、侧边栏、搜索、筛选器、分面浏览、分类页面、文档结构、内容中心、设置 IA、引导流程、产品仪表板或信息密集型页面。
• 创建信息模型、站点地图、分类体系、标签集、导航模型、内容分组、搜索 UX、元数据架构或 IA 风格指南。
• 提高可查找性、可发现性、寻路体验、内容层级、交叉链接或搜索结果质量。
• 将内容清单或产品功能集转化为实用的结构。
• 实现与 IA 相关的前端组件，例如导航地标、搜索表单、面包屑、筛选器、结果列表、菜单、选项卡和内容模板。

何时不使用此技能

如果用户只要求以下内容，请勿将此技能作为主要技能：

• 不涉及导航或可查找性的视觉样式、品牌表达、色彩、插画或动效。
• 不涉及内容结构或标签的营销宣传文案。
• 超出 UX 层面要求的后端搜索排序算法、数据库索引或 IR 调优。
• 纯内容写作，除非任务涉及结构、标题、标签或导航。

核心原则

1. 兼顾查找与理解。 帮助用户找到信息的结构，也应帮助他们了解产品包含什么、自己身处何处，以及接下来可以做什么。
2. 从用户、内容和情境出发。 不要只根据公司组织架构来设计。了解用户任务、实际内容、业务约束、平台约束、治理要求和词汇用法。
3. 内容维度多元时支持多种路径。 对稳定且互斥的结构使用层级；当用户会从不同角度查找同一内容时，使用分面、标签、搜索区域和上下文链接。
4. 明确呈现隐性的 IA。 即使用户看不到，元数据、受控词汇、别名、结果调优、重定向和编辑精选项也会影响用户体验。
5. 让标签兑现承诺。 每个标签都应准确预示其对应的内容或操作。优先使用用户熟悉的语言，而非内部术语或巧妙的品牌表达。
6. 让用户明确自己身处何处。 每个屏幕都应回答：我在哪里？这里有什么？我可以去哪里？刚才发生了什么变化？如何返回？
7. 将搜索视为一个系统，而非一个输入框。 搜索包括索引内容、查询输入、建议、拼写和同义词支持、结果呈现、排序／筛选、无结果后的补救方式以及分析。
8. 从底层构建内容结构。 标题、内容块、元数据、相关链接和内容模板应帮助通过搜索、通知、外部链接或社交分享直接进入深层页面的用户。
9. 记录决策以便复用。 IA 必须持续维护。应在风格指南或设计系统指南中记录标签规则、分类规则、元数据字段、导航位置规则和例外情况。
10. 无障碍是可查找性的一部分。 语义结构、标题、地标、键盘操作、可见焦点、易读标签和屏幕阅读器名称都是 IA 要求，不是锦上添花。

有关每项原则的可复用卡片，请参阅 references/principle-cards.md。

默认建议

除非用户的产品情境明显更适合其他选择，否则请采用以下默认建议。

产品目标

默认围绕用户的主要任务和心智模型进行组织，然后再兼顾业务优先级。

如果产品是受监管、用于归档、法律事务或参考查询的系统，且用户期望采用正式的领域结构，则应调整默认做法。

调整默认做法前，先询问：“这款产品主要是任务驱动、参考／查询驱动、交易驱动，还是合规／归档驱动？”

受众与用语

默认使用通俗、熟悉、以用户为中心的标签。只有当目标受众已经使用内部术语时，才使用这些术语。

如果受众是专家、受监管行业从业者或特定领域人士，且精确性比对新手友好更重要，则应调整默认做法。

调整默认做法前，先询问：“主要受众是谁？他们已经用哪些术语来指代这些概念？”

导航模型

默认采用精简的全局导航，为较深层级的部分设置局部导航，通过上下文链接关联相关内容，并在层级超过两级时使用面包屑导航。

如果产品是单一用途应用、扁平的营销网站，或更重视进度导航而非位置导航的工作流，则应调整默认做法。

调整默认做法前，先询问：“用户通常是按类别浏览、逐步完成任务、搜索已知条目，还是比较／筛选大量条目？”

层级深度

默认采用足够宽而浅的层级，以展示主要选项而不让用户不知所措。除非类别稳定且可预测，否则应避免深层级树状结构。

如果领域本身自然需要层级结构，例如文档、文件系统、政策或目录分类体系，则应调整默认做法。

调整默认做法前，先询问：“这些类别是否稳定且互斥，还是条目自然会属于多个分组？”

内容分组

默认每个视图只采用一种主要组织原则：任务、主题、受众、生命周期、时间顺序、地理位置、格式或字母顺序。除非各部分划分清晰，否则不要在同一菜单中混用不同方式。

如果着陆页有意提供多种入口方式，例如“按角色”“按任务”和“按主题”，则应调整默认做法。

调整默认做法前，先询问：“对用户来说，此刻哪种入口方式最重要？”

标签

默认使用简洁的文本标签：目的地使用名词，操作使用动词。主要导航中的图标应配有文字。

只有在空间极其有限，且图标得到普遍认可、经过测试并且无障碍时，才调整默认做法。

调整默认做法前，先询问：“产品是否已有经过验证的术语或受控词汇，需要我保留？”

搜索

当内容量大、变化频繁、类型多样，或用户通常知道自己想找什么时，默认添加搜索。先提供简单的搜索框；如果内容类型不同，再提供范围限定搜索或筛选器。

不要仅仅为了弥补糟糕的组织方式而添加搜索。应先改进标签、分组和元数据。

在实现以搜索为核心的用户体验前，先询问：“搜索应覆盖哪些内容？是否有些内容类型应单独搜索？”

分面与筛选器

当用户需要根据类型、主题、日期、地点、受众、状态、价格、格式、所有者或兼容性等稳定属性，从大量条目中缩小范围时，默认使用分面。

如果条目数量较少、属性数据不可靠，或筛选会产生无结果／无意义的组合，则应调整默认做法。

添加分面前，先询问：“用户实际会用哪些属性来比较结果？”

元数据与受控词汇

默认对高价值字段采用轻量级受控词汇，并为常见用户用语添加别名／同义词。

如果内容量少、时效短，或人工整理已足够，正式管理词汇带来的开销就会大于收益，此时应调整默认做法。

正式制定词汇规范前，先询问：“上线后由谁维护术语、别名、元数据字段和弃用标签？”

响应式与跨渠道行为

默认在网页、移动端和其他渠道中保留相同的概念结构，同时根据各设备调整呈现方式和交互。

当渠道上下文会改变用户任务时覆盖此默认做法，例如移动端快速查找与桌面端批量管理。

跨渠道更改信息架构前请先询问：“用户是否需要在每个平台上执行相同的任务，还是每个平台都支持不同的工作？”

无障碍

默认采用符合 WCAG 要求的语义结构、清晰可见的焦点、键盘导航、无障碍名称、图标的文本替代、有效的标题顺序，以及对动态搜索／筛选变更的状态播报。

不要询问无障碍是否重要。仅当需要明确法律或内部合规目标时才提问。

前端状态

对于网页产品，默认让导航、搜索查询、所选筛选条件、排序顺序和分页状态可通过 URL 分享或还原。

对于涉及隐私、临时状态或仅限原生应用的场景，覆盖此默认做法。

覆盖此默认做法前请先询问：“用户是否应该能够分享、收藏或返回这一确切的筛选／搜索状态？”

必须向用户提问的问题

仅当答案会改变信息架构时才提问。提问时请推荐一个默认方案。

在以下情况使用 question 工具或同等工具：

1. 目标不明确。 用户未提供产品、功能、用户任务或内容领域。
2. 受众不明确。 标签或分类法取决于使用专业术语还是面向大众的用语。
3. 导航模式不确定。 不清楚用户是浏览、搜索、筛选、比较，还是按顺序完成一系列操作。
4. 内容／模型不确定。 需要了解内容类型、元数据、规模、生命周期或所有权。
5. 搜索范围不确定。 要新增或重新设计搜索，但尚未定义索引内容。
6. 治理方式不确定。 建议需要持续维护分类法、元数据、重定向或编辑内容。
7. 平台／无障碍限制。 网页、原生应用、自助终端、语音或辅助技术环境之间的实现存在显著差异。
8. 旧版约束。 迁移、现有 URL、分析、SEO 或设计系统兼容性可能会限制结构。

不要询问标签是否应该清晰、设计是否应该无障碍，或用户是否应该理解导航等常规问题。直接采用默认做法。

使用 references/decision-prompts.md 中适用于提问工具的提示词。

工作流

A. 评估现有 IA 或 UI

按以下顺序检查：

1. 用户目标和入口。 确定用户要完成的任务、已有背景，以及可能的进入途径：主页、深层链接、搜索结果、通知、广告、书签或内部工作流。
2. 内容清单和内容类型。 列出可见或隐含的主要对象、操作、元数据、状态和关系。
3. 组织方案。 确定主要的分组原则。指出混杂、重叠或由组织架构驱动的分组。
4. 层级和结构。 检查深度、广度、顺序和父子关系是否符合用户预期。
5. 标签和语言。 评估清晰度、一致性、具体程度、辨识度以及词汇是否贴合用户。
6. 导航和路径指引。 检查全局、局部、上下文、辅助和流程导航。确认页面是否能回答“我在哪里、这里有什么、我能去哪里？”
7. 搜索和发现。 检查查询输入、搜索范围、建议、结果、筛选器、排序、排名提示、摘要、空状态／无结果状态以及恢复路径。
8. 元数据和隐性 IA。 找出缺失字段、同义词、别名、内容所有权、重定向、结果调优和分析需求。
9. 无障碍访问和键盘行为。 检查语义地标、标题、链接／按钮、焦点顺序、菜单行为、ARIA 名称和动态公告。
10. 前端可行性。 检查 URL／状态持久化、组件复用、响应式行为、性能、本地化和设计系统适配。
11. 确定修复优先级。 区分阻碍查找内容的问题和润色问题。建议以最小的结构性改动解决用户任务。

按以下格式输出评估结果：发现 → 证据 → 影响 → 建议 → 实施说明。

B. 创建或重新设计 IA

按以下顺序进行：

1. 明确产品问题。 确定主要用户、首要任务、内容范围、业务目标、平台、限制条件和成功指标。
2. 选择最简单且实用的结构。 对简单／稳定的领域优先采用清晰的层级结构；仅在内容规模或用户行为有需要时，才添加分面、搜索和上下文链接。
3. 定义内容对象。 指明每种对象类型、必填字段、可选元数据、状态、所有者和关系。
4. 选择组织方案。 根据视图选择任务／主题／受众等方案。除非创建不同的入口版块，否则避免混用方案。
5. 起草层级和导航。 提供主导航、局部导航、面包屑／流程步骤、上下文链接和辅助工具。
6. 起草标签。 使用用户熟悉的词汇、统一的语法模式和清晰易辨的标签。为常见的其他说法添加别名。
7. 设计搜索／发现。 定义可搜索内容、区域、查询支持、筛选器／分面、结果摘要、排序顺序和空状态。
8. 自底向上设计结构。 为从深层入口进入的用户添加页面模板、标题、相关链接、元数据、“下一步最佳选择”链接和内容区块。
9. 根据场景验证。 至少演练三项任务：查找已知内容、探索式浏览，以及从误入页面／无结果中恢复。
10. 指定前端行为。 定义语义化标记、URL 状态、键盘行为、焦点管理、加载／错误／空状态和分析事件。
11. 记录治理方式。 说明由谁维护标签、分类体系、元数据、重定向和搜索调优。

将设计建议作为结构化的 IA 方案输出，而非装饰性布局。

决策框架

适合采用层级结构的情况

• 内容具有清晰的父子关系。
• 用户预期内容采用目录、政策、文档、文件或目录清单结构。
• 条目大多只归属一个位置。
• 浏览路径本身有助于用户理解该领域。

选择分面导航的情况

• 内容项可根据多个相互独立的维度进行描述。
• 用户会比较、缩小范围并组合属性。
• 内容量足够大，平面列表已不再实用。
• 可以维护元数据质量。

选择搜索的情况

• 用户通常知道目标的名称、ID、关键词、位置或属性。
• 内容变化过快，仅靠手动导航已不足够。
• 内容集过大或过于多样，仅靠浏览难以查找。
• 可以利用搜索日志改进标签、同义词和结果排序。

选择上下文导航的情况

• 用户通过搜索或外部链接进入深层页面。
• 相关内容比完整层级更有用。
• 工作流需要“下一步”“相关”“也适用于”或“了解更多”等链接。
• 内容模型能够可靠地表达关系。

选择补充导航的情况

• 用户需要概览、替代访问方式或恢复工具。
• 系统包含长尾内容或面向多个受众。
• A-Z 索引、站点地图、指南、术语表、新手引导或向导可以减轻认知负担。

实用规则

• 每个导航区域都需要有明确的用途。除非重复链接有助于用户定位或完成任务，否则不要在多个区域重复相同链接。
• 不要一次性展示所有分类层级。应逐步呈现更深层级。
• 同级标签在语法和粒度上应保持一致。
• 分类标签应描述内容组，而不是营销优先事项。
• 除非其中的内容确实相互关联，且用户能预测其中包含什么，否则应避免使用“资源”“解决方案”“学习”和“更多”。
• 将高频、高价值任务放在醒目的导航位置；不要把它们藏在搜索、页脚或兜底菜单中。
• 面包屑用于表示层级中的位置，而不是记录用户的点击历史。
• 选项卡用于展示同一对象的同级视图，而不是跳转到互不相关的目的地。
• 筛选器用于缩小结果集范围，而不是作为跨越互不相关区块的主导航。
• 使用筛选器时，应提供结果数量和当前筛选条件摘要。
• 对空状态和无结果状态，始终提供恢复路径。
• 将分析数据作为证据，而不是唯一的事实来源。结合搜索日志和点击数据与用户研究或任务分析。
• 迁移期间，应记录已弃用的标签和重定向。

无障碍与包容性要求

• 使用语义化地标：header、nav、main、aside、footer；存在多个导航区域时，使用描述性 aria-label 值。
• 使用符合内容结构的逻辑标题层级，而不只是根据视觉大小设置。
• 导航使用真实链接，操作使用真实按钮。
• 提供清晰可见的焦点状态和可预测的键盘顺序。
• 菜单、组合框、选项卡、手风琴和展开式导航必须遵循预期的键盘操作模式。
• 主任务不要仅依赖图标导航，除非提供了无障碍文本标签，且图标含义经过验证。
• 为搜索输入提供程序化标签。适当时使用 type="search"。
• 页面不重新加载时，应通过适当的实时区域播报动态结果更新、筛选条件变更、加载状态和错误。
• 标签和说明不能仅依赖颜色、位置或形状。
• 在触屏设备上保持易于阅读的目标尺寸和间距。
• 支持本地化：避免使用翻译后可能产生问题的标签，并考虑不同区域设置可能会改变分类顺序、字母索引和排序逻辑。

前端实现指南

语义结构

• 主导航：使用包含链接列表的 <nav aria-label="Primary">。
• 面包屑：使用 <nav aria-label="Breadcrumb"><ol>...，并通过 aria-current="page" 标识当前页面。
• 搜索：使用 <form role="search"> 或带标签的搜索表单，并提供可见标签或无障碍名称。
• 结果：使用标题、列表语义、作为链接的结果标题、有意义的摘要、元数据以及来源／类型指示。
• 筛选器／分面：使用 fieldset／legend 对选项分组；多选分面使用复选框，互斥选项使用单选按钮；根据行为使用按钮／链接来应用或移除筛选条件。
• 分页：使用导航标志，并通过 aria-current 标识当前页。

响应式行为

• 在不同断点下保留概念上的导航结构。
• 不要在移动端抽屉中隐藏关键的主要任务，除非提供同等明显的访问路径。
• 对于复杂的侧边导航，折叠各个分区，同时保留当前位置，并确保可访问搜索／筛选功能。
• 在移动端让筛选状态保持可见，或便于恢复。

状态和 URL

• 除非隐私或安全方面的原因不允许，否则应将搜索查询、所选分面、排序、分页和当前分类编码到 URL 中，以便分享网页状态。
• 在信息架构迁移期间使用规范 URL 和重定向。
• 尽可能保持路由名称和 slug 稳定、易读，并与标签一致。

组件化

创建可复用组件：

• 主导航
• 分区／本地导航
• 面包屑
• 对象子视图标签页
• 搜索表单
• 建议／自动补全
• 结果列表／卡片
• 分面／筛选分组
• 活动筛选条件标签
• 空状态／无结果状态
• 相关内容模块
• 带元数据插槽的内容模板

性能和可维护性

• 不要无上限地渲染庞大的导航树或分面列表；应使用虚拟化、分页、分组，或在长列表中提供搜索。
• 仅在当前位置仍然清晰的情况下，才延迟加载次要导航。
• 谨慎缓存分类法和词汇数据，并确保编辑更新时会使缓存失效。
• 对搜索查询、无结果查询、筛选器使用情况、主要退出位置和导航死路进行埋点。

质量检查清单

最终确定信息架构建议前，请确认：

• 结构至少支持一项已知项目查找任务、一项探索任务和一项恢复任务。
• 主导航体现用户优先事项，而不只是内部部门。
• 标签明确、可预测且一致。
• 当用户的心理模型不同时，内容可以通过不止一种路径找到。
• 直接进入网站的用户无需访问首页即可了解自己所处的位置。
• 搜索的范围、索引字段、结果呈现方式和无结果恢复方案均已定义。
• 分面使用可靠的元数据，且不会产生大量无意义的空状态。
• 无障碍语义和键盘行为均已明确。
• 已考虑前端状态、URL、响应式行为和设计系统复用。
• 已明确维护职责。

请参阅 references/checklists.md 中的完整检查清单。

应避免的常见错误

• 在了解用户任务和内容类型之前就设计站点地图。
• 将首页或主菜单视为整个信息架构。
• 将组织架构图照搬到导航中。
• 将品牌口号或内部项目名称用作标签。
• 用添加搜索来代替修正分类法和标签。
• 在用户需要之前就展示高级搜索控件。
• 创建过多的顶级项目或过多层级。
• 在同一个不加区分的菜单中混用主题、受众、任务、格式和生命周期标签。
• 依赖仅悬停时显示的菜单。
• 未设计无结果和空状态。
• 迁移时忘记重定向、别名和弃用术语。
• 忽视内容模板内部自下而上的信息架构。

完整反模式列表请参阅 references/anti-patterns.md。

• 创建分类法，却没有治理机制。

如何向用户解释建议

使用以任务为中心的语言说明信息架构建议：

• 从用户问题入手：“用户需要按价格和功能比较套餐，但不了解产品内部系列。”
• 说明结构选择：“采用以任务为先的主导航，并在列表页提供分面比较。”
• 说明这样做的好处：“既支持浏览，也便于缩小范围，不会强迫用户沿着单一类别路径查找。”
• 提及权衡：“这需要可靠的套餐类型、受众和功能集元数据。”
• 说明实施要点：“将所选筛选条件保存在 URL 中，并以无障碍复选框组的形式呈现。”
• 指出验证方式：“通过已知项目查找、探索式浏览和无结果后的恢复操作进行测试。”

避免只说“这是最佳实践”，却不结合用户的任务、内容和限制。