跳转到主要内容
导航决定了用户如何构建对产品的心智模型。精心设计的导航帮助用户快速找到答案，理解产品各部分之间的关系，并确信自己在正确的位置。糟糕的导航会将用户推向搜索引擎、支持工单或竞争对手的文档。 本指南介绍如何设计、验证和维护适用于真实用户的文档导航。

​
从了解用户和产品开始

在组织页面之前，先与最了解产品和用户的人保持一致。

​
与利益相关者建立基础

在做出结构决策之前，与创始人、产品经理和工程负责人交流。目标是了解产品的实际运作方式，而不仅仅是它的营销方式。 需要提出的问题：
  • 解释产品如何运作的最简单方式是什么？
  • 产品的核心构建模块是什么？
  • 用户通常如何采用该产品？他们最常在哪里遇到困难？
  • 最重要的集成或依赖项是什么？
  • 如果将产品分为不同的层次，会是什么样的？是按人们执行的任务组织，还是按他们使用的功能组织？
这些对话揭示了产品的自然结构，并且常常显示文档导航在哪些方面偏离了用户的实际思维方式。

​
了解你的写作对象

导航决策取决于你的受众。集成 API 的开发者与配置设置的管理员或遵循引导流程的新用户，导航方式各不相同。 如果你有多个不同的受众群体，请考虑他们是否需要独立的导航结构，还是一个统一的结构就能满足所有人的需求。参阅了解你的受众以获取更多关于定义文档用户画像的信息。

​
选择导航结构

​
按用户旅程组织，而非按产品功能

最常见的导航错误是按照产品团队对产品的思考方式来组织文档，而不是按照用户实现目标的方式。 比较一个 API 产品的两种方法：
以功能为中心（应避免）以旅程为中心（更好）
核心 API开始使用
身份验证进行身份验证
Webhooks发送你的第一个请求
速率限制处理错误
SDKs投入生产
以旅程为中心的导航告诉用户他们在流程中的位置。以功能为中心的导航要求用户已经知道他们在寻找什么。

​
管理深度和广度

导航深度指用户需要点击多少层才能到达内容。广度指每一层显示多少个项目。 一些原则：
  • 将顶级部分控制在七个或更少。 当用户需要扫视和评估更多选项时，认知负荷会增加。
  • 优先选择深度而非广度。 一个包含五个子部分的顶级部分比 20 个顶级项目更容易浏览。
  • 不要将关键内容隐藏在两层以下。 如果用户必须点击三层才能到达经常需要的页面，请考虑提升该内容的层级。

​
清晰地命名导航项目

导航标签应与用户描述目标的方式一致，而不是与工程师描述功能的方式一致。
  • 对面向任务的部分使用动词（“身份验证”、“部署”、“监控”）
  • 对参考部分使用名词（“API 参考”、“SDKs”、“更新日志”）
  • 避免使用用户不认识的内部术语
  • 保持标签简短——最好不超过 4 个词

​
验证你的假设

你的第一个导航结构是一个假设。在将其视为永久方案之前，先进行验证。

​
追踪真实的用户旅程

使用会话回放工具如 FullStory 或 Hotjar，以及分析工具如 Mixpanel 来研究用户在文档中的实际移动方式。关注以下方面：
  • 入口点： 用户从哪里开始？他们来自搜索、支持工单还是直接来自你的产品？
  • 导航模式： 用户是否遵循预期的结构，还是走了意想不到的路径？
  • 摩擦点： 用户在哪里停顿、回退或放弃会话？
  • 搜索行为： 用户是否搜索了导航标签中没有出现的术语？这表明存在术语不匹配。

​
用真实用户进行测试

分析揭示模式，但直接对话提供模式背后的上下文。 请用户仅使用文档完成一项特定任务，同时叙述他们的思考过程。他们首先点击的位置和他们遇到困难的位置，揭示了你的导航是否直观。 你自己团队的新员工是用户的良好替代者。在他们对产品过于熟悉之前，请他们仅使用文档找到特定问题的答案。他们的直觉揭示了你的导航所做的那些对新手来说并不明显的假设。

​
识别和修复常见问题

​
顶级部分过载

如果你的顶级导航超过 7 或 8 个项目，用户花在评估选项上的时间会多于查找内容的时间。将相关主题分组到具有有意义名称的部分中。

​
重要内容被埋没

如果用户最需要的页面位于两到三层深处，请提升它们。高流量页面应该能够从顶层轻松到达，或者在任何相关部分的第一层可见。

​
部分名称不清晰

如果用户在点击导航项目之前犹豫不决，说明标签没有发挥作用。通过描述里面的内容来测试用户是否能在点击之前预测他们会找到什么。

​
页面缺失与导航问题

有时看起来像导航问题的实际上是内容缺口。如果用户搜索的术语与任何页面都不匹配，你可能缺少内容而不是标签错误。在重组之前区分这两种情况。

​
随时间迭代

导航应该随着产品和用户一起演进。你不需要在第一次就做到完美。 一个实用的节奏：
  • 每当产品发布重大变更时审查导航。 新功能通常会暴露结构性缺口。
  • 每季度检查搜索分析，找出用户搜索但未反映在导航标签中的术语。
  • 每年重新审视顶级结构。 随着文档的增长，在 20 个页面时有效的方式在 200 个页面时可能不再适用。
使用 workflows 来自动化定期检查，例如识别反馈评分低的页面或标记很少被点击的导航项目。
要在 Mintlify 中配置导航——选项卡、分组、锚点和页面排序——请参阅导航参考。

​
常见问题

在大多数情况下，按用户目标。基于功能的导航对于已经理解架构的产品团队来说有意义，但用户来到文档是为了完成某件事——而不是浏览功能。围绕用户试图做的事情进行组织，并将功能归类到它们所支持的任务下。
目标是 5 到 7 个。关于认知负荷的研究表明，用户在决策疲劳出现之前可以舒适地评估大约 7 个项目。如果你有更多，寻找可以合并为一个包含子部分的单一部分的自然分组。
首先，判断你的受众是否足够不同以至于需要独立的结构。如果管理员和开发者都需要入门，一个共享的”开始使用”部分可以很好地配合针对特定受众的子部分。如果他们的旅程根本不同——不同的产品、不同的用户画像——考虑独立的文档站点或基于选项卡的导航，以清晰地分隔两条路径。
当用户数据显示持续的导航失败时进行重组——索引页面的高跳出率、频繁搜索你期望用户直接导航到的术语，或者支持工单表明用户找不到明显的内容。避免仅凭直觉重组。重组的成本（书签失效、重新学习、重写内部链接）是真实的，因此确保数据支持这一决定。
在你的内容工作流中建立审查环节。添加新页面时，在开始编写之前就要求确定它们在导航中的位置。通过提前做出位置决策来维护连贯的结构，比在数十个页面积累在错误位置后再重组要容易得多。