我们希望如果你按照 Android Design 的每一句话来设计你的应用，那么每个人都能够学会使用你的应用。但是事实上不是这样的。
你的一些用户可能会遇到问题或者困难。他们希望在你的应用中找到解答，如果不能很快的找到答案，那么他们有可能就离你而去了。
本节将会指导你如何在应用中设计帮助和提示，提供给那些急需指导的用户。
在应用中设计帮助
除了几种情况，不要使用独立的帮助
你自然希望用户能快速的学会使用你的应用，发现应用中的亮点，了解应用的大部分功能。所以你可以在用户第一次打开应用时，提供一个一次性的功能展示、视频或者启动画面。或者你也可以在用户第一次使用某些功能时，展示文字帮助或者提示对话框。
大多数情况下，我们希望你不要这样设计，因为:
-
它们会打断用户。用户急切的希望使用你的应用，任何横在面前的内容都可能成为障碍，尽管你是出于好意。因为用户不希望看到提示，他们会忽略这些内容。
-
一般也不需要。如果你比较关注应用的某个方面，不要仅仅提供一个帮助。应当通过合理设计的 UI 来解决问题。通过应用 Android 模式、风格和控件，能够降低用户的学习成本。
只有一种情况需要为新用户提供独立的帮助:
教导用户如何使用仅仅能通过手势来启用的特殊功能。
例如我们指导用户如何将应用图标放到主屏幕上，因为这个操作:
-
很有用
不进行这个操作，用户不能根据自己的喜好和常用的应用来自定义 Android 主屏幕。 -
只能通过手势完成
因为没有按钮或者菜单来完成这个操作，用户也许不能发现这个手势操作。
也不是所有的手势操作都要教给用户。例如滚动操作，用户已经知道怎么做了，这个操作是最基本和全系统通用的。
当用户第一次进入“全部应用”屏幕时，半透明的帮助会指导用户如何进行重要的手势操作。
底线: 当在应用中提供帮助时，最好让用户在需要的时候来找你。
标准的帮助导航模式
在应用的每个屏幕上，通过 操作栏的“更多操作”菜单 提供帮助。总是把“帮助”放在菜单的最下面。
即使“更多操作”菜单上没有别的要显示的内容，也请将“帮助”放在菜单里，而不要放在操作栏上。
这个设计标准使得用户在需要帮助时能很快的找到 (阅读 告诉哥适用于各处的小技巧)。
假设每次请求帮助都是很紧急的
显示帮助的时候，你也许会展示其他信息，例如版权信息、开发者名单、服务条款或者隐私政策。
让用户在帮助视图中通过菜单访问这些内容，并且优先展示用户急切需要解决的问题。那些比较希望看到法律内容或者开发者名单的用户不会在乎多按两下的。
这个设计指导也适用于交流选项，例如技术支持或者反馈。在用户看到帮助之前，不要增加额外的步骤来提供这些选项。让用户自己找到解决方法也能降低你的技术支持成本。
当用户触摸“帮助”时:
不要这么做
显示一个对话框，让用户选择帮助或者其他选项。
这样比较好
立即打开浏览器显示帮助页面，将其他选项放在页面底部。
这样更好
在你的应用中设计一个帮助视图，将其他选项放在操作栏中。例如你可以让用户通过按钮向你提问或者提交反馈。“更多操作”菜单则放置一些不常用的信息。
这样比打开浏览器展示帮助页面需要更多的开发工作，但是这样做的用户体验更好，因为这样不需要离开你的应用，也不需要连接网络。
帮助内容的撰写原则
帮助也是 UI 的一部分
帮助是应用 UI 的扩展，而不是对 UI 的描述。无论是应用还是帮助，每一句文字都应该符合 写作风格 中的指导，以保持一贯的体验。
仔细考虑每一个像素
不需要对应用中的每一个功能都做详细的说明，尤其是那些一眼就能看出来的功能，或者是全平台通用的操作。仅仅展示重要的信息，而不要仔细描述，这样布局也可以比较简单。
图片比文字更容易理解
在描述关键 UI 或者提供一步步指导时，请结合文字和图标还有带有标注的截图等。这样你就可以少用些文字来描述，用户也能更快的理解。
浏览而不是阅读
用户不会从头到尾仔细阅读帮助。他们一般就浏览一下，看看有没有需要寻找的答案。请在排版上更加友好，使用大字体的标题、列表、表格和留白。如果有很多内容要显示，分割成多个屏幕，让用户滚动浏览。
直接提供答案
比浏览更简单的是什么？就是直接提供答案。可以考虑在每个能够导航到帮助的屏幕中，进入帮助后只显示与进入屏幕有关的信息。我们称之为上下文帮助，这种做法最有利于协助用户。如果你能提供这种帮助，请记住提供一个方法给用户浏览帮助的其他内容。