mirror of
https://github.com/mintlify/docs.git
synced 2026-09-14 13:35:46 +08:00
mintlify[bot]
27b3820350
Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
182 lines
9.1 KiB
Plaintext
182 lines
9.1 KiB
Plaintext
---
|
||
title: "如何构建文档导航结构"
|
||
sidebarTitle: "导航"
|
||
description: "设计文档导航，通过清晰的信息架构、逻辑分组和经过验证的结构，帮助用户找到所需内容。"
|
||
keywords: ["文档导航", "信息架构", "文档结构", "侧边栏导航", "导航设计"]
|
||
---
|
||
|
||
导航决定了用户如何构建对产品的心智模型。精心设计的导航帮助用户快速找到答案，理解产品各部分之间的关系，并确信自己在正确的位置。糟糕的导航会将用户推向搜索引擎、支持工单或竞争对手的文档。
|
||
|
||
本指南介绍如何设计、验证和维护适用于真实用户的文档导航。
|
||
|
||
<div id="start-by-understanding-your-users-and-product">
|
||
## 从了解用户和产品开始
|
||
</div>
|
||
|
||
在组织页面之前，先与最了解产品和用户的人保持一致。
|
||
|
||
<div id="map-the-foundation-with-stakeholders">
|
||
### 与利益相关者建立基础
|
||
</div>
|
||
|
||
在做出结构决策之前，与创始人、产品经理和工程负责人交流。目标是了解产品的实际运作方式，而不仅仅是它的营销方式。
|
||
|
||
需要提出的问题：
|
||
- 解释产品如何运作的最简单方式是什么？
|
||
- 产品的核心构建模块是什么？
|
||
- 用户通常如何采用该产品？他们最常在哪里遇到困难？
|
||
- 最重要的集成或依赖项是什么？
|
||
- 如果将产品分为不同的层次，会是什么样的？是按人们执行的任务组织，还是按他们使用的功能组织？
|
||
|
||
这些对话揭示了产品的自然结构，并且常常显示文档导航在哪些方面偏离了用户的实际思维方式。
|
||
|
||
<div id="know-who-youre-writing-for">
|
||
### 了解你的写作对象
|
||
</div>
|
||
|
||
导航决策取决于你的受众。集成 API 的开发者与配置设置的管理员或遵循引导流程的新用户，导航方式各不相同。
|
||
|
||
如果你有多个不同的受众群体，请考虑他们是否需要独立的导航结构，还是一个统一的结构就能满足所有人的需求。参阅[了解你的受众](/zh/guides/understand-your-audience)以获取更多关于定义文档用户画像的信息。
|
||
|
||
<div id="choose-a-navigation-structure">
|
||
## 选择导航结构
|
||
</div>
|
||
|
||
<div id="organize-by-user-journey-not-product-features">
|
||
### 按用户旅程组织，而非按产品功能
|
||
</div>
|
||
|
||
最常见的导航错误是按照产品团队对产品的思考方式来组织文档，而不是按照用户实现目标的方式。
|
||
|
||
比较一个 API 产品的两种方法：
|
||
|
||
| 以功能为中心（应避免） | 以旅程为中心（更好） |
|
||
|---|---|
|
||
| 核心 API | 开始使用 |
|
||
| 身份验证 | 进行身份验证 |
|
||
| Webhooks | 发送你的第一个请求 |
|
||
| 速率限制 | 处理错误 |
|
||
| SDKs | 投入生产 |
|
||
|
||
以旅程为中心的导航告诉用户他们在流程中的位置。以功能为中心的导航要求用户已经知道他们在寻找什么。
|
||
|
||
<div id="manage-depth-and-breadth">
|
||
### 管理深度和广度
|
||
</div>
|
||
|
||
导航深度指用户需要点击多少层才能到达内容。广度指每一层显示多少个项目。
|
||
|
||
一些原则：
|
||
- **将顶级部分控制在七个或更少。** 当用户需要扫视和评估更多选项时，认知负荷会增加。
|
||
- **优先选择深度而非广度。** 一个包含五个子部分的顶级部分比 20 个顶级项目更容易浏览。
|
||
- **不要将关键内容隐藏在两层以下。** 如果用户必须点击三层才能到达经常需要的页面，请考虑提升该内容的层级。
|
||
|
||
<div id="name-navigation-items-clearly">
|
||
### 清晰地命名导航项目
|
||
</div>
|
||
|
||
导航标签应与用户描述目标的方式一致，而不是与工程师描述功能的方式一致。
|
||
|
||
- 对面向任务的部分使用动词（"身份验证"、"部署"、"监控"）
|
||
- 对参考部分使用名词（"API 参考"、"SDKs"、"更新日志"）
|
||
- 避免使用用户不认识的内部术语
|
||
- 保持标签简短——最好不超过 4 个词
|
||
|
||
<div id="validate-your-assumptions">
|
||
## 验证你的假设
|
||
</div>
|
||
|
||
你的第一个导航结构是一个假设。在将其视为永久方案之前，先进行验证。
|
||
|
||
<div id="track-real-user-journeys">
|
||
### 追踪真实的用户旅程
|
||
</div>
|
||
|
||
使用会话回放工具如 [FullStory](https://www.fullstory.com) 或 [Hotjar](https://www.hotjar.com)，以及分析工具如 [Mixpanel](https://mixpanel.com) 来研究用户在文档中的实际移动方式。关注以下方面：
|
||
|
||
- **入口点：** 用户从哪里开始？他们来自搜索、支持工单还是直接来自你的产品？
|
||
- **导航模式：** 用户是否遵循预期的结构，还是走了意想不到的路径？
|
||
- **摩擦点：** 用户在哪里停顿、回退或放弃会话？
|
||
- **搜索行为：** 用户是否搜索了导航标签中没有出现的术语？这表明存在术语不匹配。
|
||
|
||
<div id="test-with-real-users">
|
||
### 用真实用户进行测试
|
||
</div>
|
||
|
||
分析揭示模式，但直接对话提供模式背后的上下文。
|
||
|
||
请用户仅使用文档完成一项特定任务，同时叙述他们的思考过程。他们首先点击的位置和他们遇到困难的位置，揭示了你的导航是否直观。
|
||
|
||
你自己团队的新员工是用户的良好替代者。在他们对产品过于熟悉之前，请他们仅使用文档找到特定问题的答案。他们的直觉揭示了你的导航所做的那些对新手来说并不明显的假设。
|
||
|
||
<div id="identify-and-fix-common-problems">
|
||
## 识别和修复常见问题
|
||
</div>
|
||
|
||
<div id="overloaded-top-level-sections">
|
||
### 顶级部分过载
|
||
</div>
|
||
|
||
如果你的顶级导航超过 7 或 8 个项目，用户花在评估选项上的时间会多于查找内容的时间。将相关主题分组到具有有意义名称的部分中。
|
||
|
||
<div id="buried-essential-content">
|
||
### 重要内容被埋没
|
||
</div>
|
||
|
||
如果用户最需要的页面位于两到三层深处，请提升它们。高流量页面应该能够从顶层轻松到达，或者在任何相关部分的第一层可见。
|
||
|
||
<div id="unclear-section-names">
|
||
### 部分名称不清晰
|
||
</div>
|
||
|
||
如果用户在点击导航项目之前犹豫不决，说明标签没有发挥作用。通过描述里面的内容来测试用户是否能在点击之前预测他们会找到什么。
|
||
|
||
<div id="missing-pages-vs-navigation-problems">
|
||
### 页面缺失与导航问题
|
||
</div>
|
||
|
||
有时看起来像导航问题的实际上是内容缺口。如果用户搜索的术语与任何页面都不匹配，你可能缺少内容而不是标签错误。在重组之前区分这两种情况。
|
||
|
||
<div id="iterate-over-time">
|
||
## 随时间迭代
|
||
</div>
|
||
|
||
导航应该随着产品和用户一起演进。你不需要在第一次就做到完美。
|
||
|
||
一个实用的节奏：
|
||
- **每当产品发布重大变更时审查导航。** 新功能通常会暴露结构性缺口。
|
||
- **每季度检查搜索分析**，找出用户搜索但未反映在导航标签中的术语。
|
||
- **每年重新审视顶级结构。** 随着文档的增长，在 20 个页面时有效的方式在 200 个页面时可能不再适用。
|
||
|
||
<Tip>
|
||
使用 [workflows](/automations) 来自动化定期检查，例如识别反馈评分低的页面或标记很少被点击的导航项目。
|
||
</Tip>
|
||
|
||
要在 Mintlify 中配置导航——选项卡、分组、锚点和页面排序——请参阅[导航参考](/zh/organize/navigation)。
|
||
|
||
<div id="frequently-asked-questions">
|
||
## 常见问题
|
||
</div>
|
||
|
||
<AccordionGroup>
|
||
<Accordion title="我应该按产品功能还是按用户目标组织导航？">
|
||
在大多数情况下，按用户目标。基于功能的导航对于已经理解架构的产品团队来说有意义，但用户来到文档是为了完成某件事——而不是浏览功能。围绕用户试图做的事情进行组织，并将功能归类到它们所支持的任务下。
|
||
</Accordion>
|
||
|
||
<Accordion title="我应该有多少个顶级导航部分？">
|
||
目标是 5 到 7 个。关于认知负荷的研究表明，用户在决策疲劳出现之前可以舒适地评估大约 7 个项目。如果你有更多，寻找可以合并为一个包含子部分的单一部分的自然分组。
|
||
</Accordion>
|
||
|
||
<Accordion title="如何处理面向多个受众的文档？">
|
||
首先，判断你的受众是否足够不同以至于需要独立的结构。如果管理员和开发者都需要入门，一个共享的"开始使用"部分可以很好地配合针对特定受众的子部分。如果他们的旅程根本不同——不同的产品、不同的用户画像——考虑独立的文档站点或基于选项卡的导航，以清晰地分隔两条路径。
|
||
</Accordion>
|
||
|
||
<Accordion title="我什么时候应该重组导航？">
|
||
当用户数据显示持续的导航失败时进行重组——索引页面的高跳出率、频繁搜索你期望用户直接导航到的术语，或者支持工单表明用户找不到明显的内容。避免仅凭直觉重组。重组的成本（书签失效、重新学习、重写内部链接）是真实的，因此确保数据支持这一决定。
|
||
</Accordion>
|
||
|
||
<Accordion title="如何防止导航随着文档增长而变得混乱？">
|
||
在你的内容工作流中建立审查环节。添加新页面时，在开始编写之前就要求确定它们在导航中的位置。通过提前做出位置决策来维护连贯的结构，比在数十个页面积累在错误位置后再重组要容易得多。
|
||
</Accordion>
|
||
</AccordionGroup>
|