应用帮助指南

应用程序可能会很复杂，而为用户提供有效的帮助可大幅改善他们的体验。并非所有应用程序都需要为其用户提供帮助，并且应提供哪种类型的帮助可能有很大的不同，具体取决于应用程序。

如果你决定提供帮助，请在创建它时遵循以下指南。无用的帮助可能比完全不帮助更糟。

直观设计

即使帮助内容再有用，你的应用也无法依靠它来为用户提供良好的体验。如果用户无法立即发现并使用应用的关键功能，用户将不会使用你的应用。帮助数量再多或质量再高都无法改变这一第一印象。

直观和用户友好的设计是编写有用帮助的第一步。它不但可使用户保持长时间的参与以使他们使用更高级的功能，它还为用户提供应用核心功能的知识，以便他们在继续使用应用的过程中依靠这些知识进行学习。

除非用户已经遇到问题，否则他们不会查看帮助内容，因此帮助需要为该问题提供简短且有效的解答。如果帮助不是立即有用，或者帮助过于复杂，则用户更有可能忽略它。

无论类型如何，所有帮助都应遵循以下原则：

易于理解：使用户迷惑的帮助比完全没有帮助更糟。
简单明了：查找帮助的用户希望向他们直接呈现明确的解答。
相关：用户不希望必须搜索他们的特定问题。他们希望最相关的帮助直接呈现给他们（这称为“上下文帮助”），或者他们希望有轻松导航的界面。
直接：当用户查找帮助时，他们希望看到帮助。当你的应用包含用于报告 bug、提供反馈、查看服务条款或类似功能的页面时，如果你的帮助链接到这些页面，则没有问题。但它们应作为补充包含在主帮助页面上，而不是作为同等重要或更重要的项目。
一致：无论类型如何，帮助仍然是应用的一部分，其处理方式应与 UI 的任何其他部分相同。在应用其余部分中通用的可用性、可访问性和样式的相同设计原则也应呈现在你所提供的帮助中。

帮助内容有三个主要类别，每种类别都具有不同的优势，并且适用于不同的用途。在应用中根据需求使用它们的任意组合。

正常情况下，用户应能够使用应用的所有核心功能，而无需说明。但有时，你的应用将依赖于使用特定手势，或者可能存在不太明显的应用辅助功能。在此情况下，应使用说明性 UI 来向用户提供有关如何执行特定任务的说明。

显示帮助的标准方法是在用户请求时在应用程序内显示它。可使用多种方法实现此目的，如通过帮助页面或信息说明。此方法非常适合通用帮助，可毫不复杂地直接回答用户的问题。

对于由于太大而无法容纳在应用程序中的详细教程、高级功能或帮助主题库，指向外部网页的链接是理想之选。应尽量慎用这些链接，因为它们会使用户离开应用程序体验。