导航
导航决定了结构的哪些部分会永久保留在屏幕界面上，哪些部分通过其他方式访问。屏幕上的位置是稀缺的，每个导航表面都有自己的一套规则来决定谁能占据一席之地。
首先需要什么
| 输入 | 来源 | 如果缺失怎么办 |
|---|---|---|
| 当前每个导航表面的状态 | 在代码库中，首先读取路由和导航组件（页眉、页脚、应用切换器、侧边栏、标签栏）。永远不要只从首页开始重新设计。 | 请求提供截图或每个表面项目的类型化列表。 |
| 背后的结构树 | 站点地图或路由 | 自行绘制当前的树结构，并明确说明。如果结构本身有问题，停止操作并使用 sitemaps。 |
| 核心任务、用户失败的任务以及使用情况 | 用户、分析数据、搜索日志、重复出现的支持问题 | 提出询问，或在开头说明你的假设。切勿估算使用情况；说明如果有使用数据，哪些决策会改变。 |
如果以上信息都无法获取，说明你需要什么，并基于 references/spec-template.md 生成一个空的规范文件，并填入准入规则。
方法
-
映射每个表面。 表面、项目、目标地址、数量。标记同一目标地址的两个不同名称、指向空白的项目，以及偶然存在于单一表面的内容。
-
区分全局导航与局部导航。
全局 局部 职责 展示整个产品的功能 展示当前页面周边的功能 显示 在每个页面上相同 仅在其所属的板块内显示 表面 主导航、实用工具栏、页脚 侧边栏、页面内目录、面包屑导航、相关链接 问题表现 列出了某个板块的子级 重复了全局项目 一个需要超过两级导航的板块，通常需要自己的侧边栏或独立的主页。
-
为每个表面定义准入规则，并对每个项目应用该规则。
表面 什么属于这里 什么不属于这里 准入规则 主导航 对用户和业务最重要的 3 到 6 个目标 任何未赢得此位置的项目 服务于核心任务或明确的业务目标，对新用户有意义，并且比现有最弱的项目更重要 实用工具栏 登录、账户、搜索、语言、设置 市场营销相关的项目 与用户的会话或当前工具相关，而非内容相关 页脚 更完整的站点地图、法律信息、联系信息、辅助号召性用语 杂物抽屉（用户和爬虫仍然会读它） 有人需要从任何页面访问它，或者法律要求如此；它适合一个指定的分组 上下文导航 侧边栏、页面内目录、面包屑导航、相关链接 任何全局项目 仅在此处有意义，并且根据书面规则放置 应用标签栏 最多 5 个标签；第 6 个标签变成“更多”或被删除 很少使用的目标 产品中一个重复出现的高级任务 -
分配安置。 如果主导航项目超过七个，则表明有些项目没有发挥其作用：合并它们或将其移至页脚。将相近的项目合并为一个。为每个用户失败的任务指定一个规范的主页，并说明其他入口点都应导向此处。
-
提供两到三种布局方案（按任务、按对象、按目标受众），每种方案说明其成本和潜在问题。推荐一种并说明原因。
-
选择布局模式。
情况 使用 备注 一个项目下有三个或更多有子级的子组 巨型菜单 将其键盘焦点和移动端版本的设计作为单独的工作 一个简短扁平的子级列表 普通下拉菜单，或链接到中心页面 通常中心页面更好 三层或更深的结构 面包屑导航 每一级都是真实页面。每个页面只有一个面包屑路径，遵循规范主页，而不是用户访问的路径。 内容很长的参考页面 页面内目录 仅限局部 不同角色需要不同的起始点 个性化快捷方式 个性化的是快捷方式，而不是地图。如果每个人看到的菜单都不同，人们将无法指路，支持团队无法描述位置，分析数据也会失去意义。 -
现在设计移动端和键盘操作。 在移动端，说明主导航如何折叠、哪些内容保持可见以及每个巨型菜单如何处理。在键盘操作上，每个项目都应能按视觉顺序到达，焦点可见，Escape 键关闭 Enter 键打开的菜单，且没有任何操作仅依赖悬停。详情见
references/mobile-and-keyboard.md；对于任何可打开的菜单，请阅读该文件。 -
将线索放在决策点。 一个好的线索能在用户做出选择的关键时刻、在他们已经注视的地方，安静且低成本地回答他们已有的问题。汽车燃油表旁指示油箱盖方向的箭头就是典范。使用激活状态显示当前位置。
-
规划项目如何移除。 移除一个链接不等于移除一个页面。
步骤 做什么 决定其命运 合并、移至页脚或实用工具栏、仅可通过搜索访问、或删除 如果页面被删除 将其添加到重定向映射 如果页面保留 确认有其他路径仍可到达 告知用户 在登录产品中，在原来的位置保留一到两个版本的提示，并修复提及旧路径的帮助文章、教程和邮件 保留关键词 保留旧的标签作为搜索同义词，然后监测搜索和支持数据 -
将验证交给
tree-tests。 它负责编写测试计划和任务。向其提供触发本次工作的每个问题、你感到不确定的每个安置以及提议的答案。目标：总体成功率至少 70%，核心任务至少 80%，路径比（path ratio）最多 1.5。
交付物
navigation-spec.md，按以下顺序：
- 推荐方案： 两到三句话和主要原因。
- 当前状态： 每个表面、其项目数量及其问题。
- 可选方案： 每种布局一行，附带其成本。
- 规范： 每个表面的标签和目标地址，以及每个主导航项目赢得其位置的原因。然后是面包屑模式、移动端、键盘操作和激活状态。
- 规范主页： 每个问题任务、其唯一主页以及指向该主页的入口点。
- 前后对比： 每个当前项目及其新位置，包括哪些被弃用及如何处理。
- 准入规则： 新的顶级项目必须通过的测试。
- 假设与待解决的问题。
- 移交给
tree-tests： 问题任务、不确定的安置和提议的答案。
缩减规模。一个菜单重新思考的工作，需要的是诊断、新的结构树、每个问题任务的一个主页以及移交给 tree-tests；它不需要内容模型或 URL 策略。更长的文档并不意味更周全。如果要求为每个项目指定位置，那么每个项目都必须有归处。
检查清单
没有脚本。这些检查简短且需要阅读规范，因此请手动完成并修复失败项：
- 统计主导航项目（最多 7 个，最好 3 到 6 个）和标签栏（最多 5 个）。
- 每个当前项目都出现在“前后对比”表中，并带有新位置或明确说明已弃用。
- 每个目标地址都存在于结构树或路由中，每个面包屑父级都是真实页面，且侧边栏、面包屑和 URL 讲述同一个故事。
- 每个问题任务只有一个规范主页，并出现在
tree-tests的移交信息中，附带提议的答案。 - 没有未被授予的使用声明。频率词被标记为假设。
Claude 在此无法做到的事
- 除非告知，否则无法了解组织的战略或内部政治。哪个项目赢得某个位置部分属于商业决策，因此需提供草稿并说明由谁决定。
- 编造流量、使用情况或研究数据，或使用真实用户运行树测试。
- 说明框架的菜单组件是什么。说明你的期望并让用户确认，因为平台支持的功能各不相同。
与其他技能的交界
information-architecture：当工作跨度涉及多个领域时，作为入口。sitemaps：当底层结构树需要更改时。labeling：为项目措辞。taxonomies：当过滤器或分面筛选是真正需求时。url-structure和redirect-maps：当目标地址变更时。content-models：当上下文规则需要后台字段时。tree-tests：运行研究。findability：当问题是搜索或信息线索时。content-inventory和card-sort：当没人知道有什么内容或人们如何分组时。