如何构建文档导航结构

导航决定了用户如何构建对产品的心智模型。精心设计的导航帮助用户快速找到答案，理解产品各部分之间的关系，并确信自己在正确的位置。糟糕的导航会将用户推向搜索引擎、支持工单或竞争对手的文档。

本指南介绍如何设计、验证和维护适用于真实用户的文档导航。

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

在做出结构决策之前，与创始人、产品经理和工程负责人交流。目标是了解产品的实际运作方式，而不仅仅是它的营销方式。

需要提出的问题：

• 解释产品如何运作的最简单方式是什么？
• 产品的核心构建模块是什么？
• 用户通常如何采用该产品？他们最常在哪里遇到困难？
• 最重要的集成或依赖项是什么？
• 如果将产品分为不同的层次，会是什么样的？是按人们执行的任务组织，还是按他们使用的功能组织？

这些对话揭示了产品的自然结构，并且常常显示文档导航在哪些方面偏离了用户的实际思维方式。

导航决策取决于你的受众。集成 API 的开发者与配置设置的管理员或遵循引导流程的新用户，导航方式各不相同。

如果你有多个不同的受众群体，请考虑他们是否需要独立的导航结构，还是一个统一的结构就能满足所有人的需求。参阅了解你的受众以获取更多关于定义文档用户画像的信息。

最常见的导航错误是按照产品团队对产品的思考方式来组织文档，而不是按照用户实现目标的方式。

比较一个 API 产品的两种方法：

以旅程为中心的导航告诉用户他们在流程中的位置。以功能为中心的导航要求用户已经知道他们在寻找什么。

导航深度指用户需要点击多少层才能到达内容。广度指每一层显示多少个项目。

一些原则：

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

导航标签应与用户描述目标的方式一致，而不是与工程师描述功能的方式一致。

• 对面向任务的部分使用动词（“身份验证”、“部署”、“监控”）
• 对参考部分使用名词（“API 参考”、“SDKs”、“更新日志”）
• 避免使用用户不认识的内部术语
• 保持标签简短——最好不超过 4 个词

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

使用会话回放工具如 FullStory 或 Hotjar，以及分析工具如 Mixpanel 来研究用户在文档中的实际移动方式。关注以下方面：

• 入口点： 用户从哪里开始？他们来自搜索、支持工单还是直接来自你的产品？
• 导航模式： 用户是否遵循预期的结构，还是走了意想不到的路径？
• 摩擦点： 用户在哪里停顿、回退或放弃会话？
• 搜索行为： 用户是否搜索了导航标签中没有出现的术语？这表明存在术语不匹配。

分析揭示模式，但直接对话提供模式背后的上下文。

请用户仅使用文档完成一项特定任务，同时叙述他们的思考过程。他们首先点击的位置和他们遇到困难的位置，揭示了你的导航是否直观。

你自己团队的新员工是用户的良好替代者。在他们对产品过于熟悉之前，请他们仅使用文档找到特定问题的答案。他们的直觉揭示了你的导航所做的那些对新手来说并不明显的假设。

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

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

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

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

导航应该随着产品和用户一起演进。你不需要在第一次就做到完美。

一个实用的节奏：

• 每当产品发布重大变更时审查导航。 新功能通常会暴露结构性缺口。
• 每季度检查搜索分析，找出用户搜索但未反映在导航标签中的术语。
• 每年重新审视顶级结构。 随着文档的增长，在 20 个页面时有效的方式在 200 个页面时可能不再适用。

要在 Mintlify 中配置导航——选项卡、分组、锚点和页面排序——请参阅导航参考。