为SaaS产品编写故障排除指南的逐步流程

我一直觉得，写故障排除指南是一件特别考验“共情能力”的事。你不仅要理解技术，还得站在用户的角度，想象他们遇到问题时的沮丧和困惑。很多时候，我看到团队花大量精力打磨产品功能，却忽略了使用过程中必然出现的“意外”。其实，真正能让用户感受到产品温度的，往往不是那些炫酷的特性，而是当他卡住时，能不能快速找到解决方案。这就是为什么我在做Baklib时，特别强调在线帮助中心建设——它不只是一堆文档的堆砌，而是一个能主动响应用户需求的智能入口。当你把常见问题、解决方案、甚至AI搜索整合在一起，用户就能在几秒钟内得到答案，而不是排队等客服回复。这背后其实是工作流的减负：用户省心，客服省力，产品团队也能从重复的答疑中解放出来，专注于更重要的优化。

不管你、你的团队花了多少时间、精力和资源来打造一款SaaS产品，它永远不可能是完美的。

它可能非常优秀——但绝不完美。

我们强调这一点，是因为接受这个现实，对于创建一份产品必备文档——故障排除指南——至关重要。

写一份出色的故障排除指南很有挑战性。就像它所服务的产品一样，它很可能永远无法做到完全无瑕。

不过，如果你在撰写时遵循一些关键步骤，它就能成为用户会心存感激的资源。

让我们从流程的第一步开始。

软件产品由许多元素、功能以及底层成千上万行代码组成。

这么多组件相互交互，出现问题也就不足为奇了。

同样，我们也不能指望故障排除指南能涵盖所有可能出现的问题及其解决方案。

原因之一是软件产品会随时间变化、演进和更新，因此问题列表不可能是一成不变的。

所以，你应该列出用户最常遇到的问题，并以此为基础编写故障排除指南。

当你这样做时，最终会得到像Slack那样的指南。

Slack的连接问题故障排除指南本质上就是一个最常见连接问题的列表。

准备常见问题列表时需要注意的一个重要因素是，你应该对它们进行分类并按逻辑组织。

例如，在上面的例子中，Slack通过将连接问题分组做到了这一点。

另一方面，Amazon Web Services 将其故障排除指南组织成17个不同的类别。

无论你的常见问题列表有五项还是55项，你首先需要知道最常见的问题是什么，才能制作出列表，并创建出像我们上面展示的那样的故障排除指南。

你可以通过分析错误日志来收集SaaS产品中重复出现问题的数据。

正如员工培训专家Jonathan DeVore所指出的，一个好的错误日志会提供关于问题的以下信息：

因此，分析错误日志不仅能提供关于问题的宝贵数据，还能为你正在创建的列表提供最有用的信息——哪些问题出现得最频繁。

编写故障排除指南的下一个基本步骤是找出列表中问题的原因。

不言而喻，一份故障排除指南应该为用户提供解决SaaS产品问题的方案。

换句话说，它不仅仅是问题列表，也是解决方案列表。而要找到特定问题的解决方案，你首先需要理解其成因。

找出原因的方法之一是询问用户问题发生时的具体情况。

提问很重要，因为没有激励，用户不太可能主动来找你。

根据客户体验专家Esteban Kolsky的说法，每26个客户中只有1个会向公司反映他们的问题。其他人则会直接离开。

你可以通过几种方式询问客户他们遇到的问题。

例如，你可以使用Typeform或SurveyMonkey等工具进行客户调查。

它们通常有许多免费模板可供选择，你甚至能找到符合需求的预制调查问卷。

无论你是使用客户调查、自己的分析工具还是其他方式来确定问题起因，你始终要考虑SaaS产品的复杂性。

为什么？因为它们的复杂特性意味着问题可能有多个原因，这在创建故障排除指南时至关重要。

例如，当你使用Canva这款流行的图形设计工具时，可能会遇到设计丢失的问题。

幸运的是，Canva故障排除指南背后的团队找到了该问题的多个可能原因，并提供了相应的解决方案。

下面你可以看到其中一些。

总共有六种可能导致设计丢失的原因，每种原因在故障排除指南中都有对应的解决方案。

无论是单一原因还是多个原因，找出它们对于解决问题和创建全面的故障排除指南至关重要。

在你找出SaaS产品问题的原因后，就该向用户提供一些解决方案了。

解决问题通常意味着用户需要执行特定操作才能使产品按预期工作。

在创建故障排除指南的这个阶段，如何表述这些操作的指令至关重要。

因此，你应该将解决方案编写为逐步说明。

它们是一种耐心而渐进地引导用户从解决问题的初期阶段一直到最终解决方案的方式。

经验丰富的SaaS内容营销人员Levi Olmstead也大力推崇逐步方法。

逐步说明的有效性取决于你如何编写它们。

具体来说，如果你希望它们能简化任务完成、清晰明了并稳步引导客户找到解决方案，那么你的说明应该简洁且结构良好。

例如，让我们回到Slack的故障排除指南。

看看他们处理浏览器错误的故障排除步骤。

这里有六个步骤来解决该问题，看起来可能有点多。

然而，这些说明简洁明了。大多数步骤只用一句话描述；最长的是第四步，由三个句子组成。

这是一份高效结构且清晰的指南，尽管简短，但仍提供了足够的细节。

除了长度和结构，语言对于说明的成功也至关重要。

简而言之，用户应该能够理解他们需要做什么。

使用通俗语言并避免技术术语是最大程度覆盖最广泛受众的好方法。

Discord理解语言的重要性，因此他们的故障排除指南使用日常语言编写。

如上所示，他们的说明非常描述性和精确。

无论用户的技术背景如何，每个人都应该理解“带斜杠的麦克风或耳机图标”的含义。

带有简洁措辞、精确结构的逐步说明在引导用户找到任何解决方案时都非常高效。

但你还可以通过视觉元素使指南更有帮助。让我们在下一节进一步探讨。

如果你想让故障排除指南更有帮助，不应跳过添加视觉元素这一步骤。

这一步可以提高帮助资源的品质。

写作是每份故障排除指南的基石；然而，视觉元素可以使每一条书面说明更加清晰。

这是因为视觉元素通常能比文字更有效地传达信息。

正如《Technical Writing at LBCC》的作者Will Fleming指出的，视觉元素可以将抽象的东西变成具体的东西。

在编写故障排除指南时，你可以利用这一点。

例如，如果你在描述如何清除浏览器或桌面应用缓存，用截图展示比仅用文字描述要容易得多。

Airtable的故障排除指南背后的团队就是这么做的。

他们结合文字和截图向用户描述如何执行该故障排除步骤。

这样，他们使说明尽可能清晰，并最大限度地减少关于指令的任何混淆或误解。

用户只需要查看视觉元素，看看自己屏幕上的情况是否与指南中的截图匹配。

更进阶的做法是使用带注释的截图。你可以通过箭头、圆圈或高亮等注释将用户的注意力吸引到截图中的特定细节上。

以下是Airtable使用带注释截图的另一个例子。

---

Baklib通过知识访问技术、创新的用户界面提供支持，汇集了业界最广泛的知识访问方法、联合搜索、流程智能、多语言功能和灵活的外观的强大功能，所有这些都在一个搜索框后面，以实现独特的在线自助服务。