帮助

注意

此设计指南是为 Windows 7 创建的,尚未针对较新版本的 Windows 进行更新。 大部分指南原则上仍然适用,但演示和示例并不反映我们 当前的设计指南

将“帮助”用作辅助机制,帮助用户完成并更好地了解主要机制是 UI 本身的任务。 应用这些指南,使内容真正有用且易于查找。

帮助系统由各种类型的内容组成,旨在当用户无法完成任务、想要更详细地了解概念或需要比 UI 中更多的技术详细信息时提供帮助。

在本文中,我们将帮助称为 UI 的辅助功能。 UI 是主要 UI,因为这是用户首先尝试解决其问题的地方。 仅当无法使用 UI 完成任务时,他们才会咨询帮助系统。

Windows 帮助和支持页面的屏幕截图

Windows 帮助和支持主页,可从“开始”菜单获取。

注意:风格和语气 相关的指南在单独的文章中提供。

这是正确的用户界面吗?

在决定之前,请考虑以下问题:

  • 目标用户的动机如何? 他们发现程序功能的积极性越高,并成为该计划的中级甚至高级用户,他们就越愿意通过咨询帮助主题来研究其问题的答案。
  • 是否使用“帮助”来修复错误的 UI? UI 越好,用户寻求更多帮助的用户就越少。 如果你的程序具有非常清晰、有用的主 UI ((如无行话的错误消息、精心编写的向导和) 明确的对话框),则可能根本不需要辅助帮助系统。
  • 程序相对简单吗? 如果是这样,请考虑将所有必要的帮助内容合并到主要 UI 图面中。 用户更有可能在执行复杂任务的程序中寻求其他帮助。
  • 应用程序是否面向开发人员、IT 专业人员或其他软件专家? 这些用户往往需要有关编程语言约定的参考帮助,以及有关掌握功能的深入概念帮助。

设计概念

如果决定在程序中包括“帮助”,请将其集成到整体设计中。 帮助界面应简单、高效且相关;它应使用户能够轻松获取帮助,然后返回到其任务。 根据用户的时间考虑帮助系统:首先通过预测用户在程序中遇到问题的位置来最大程度地减少中断,然后通过将基本帮助直接合并到 UI 中来解决这些问题,并在更详细的帮助中创建清晰且一致的入口点。

Windows 协助是根据这些原则设计的。 下面是 Windows 帮助用户体验的一些设计更改:

  • 从主 UI 到帮助的更多可发现入口点 (尤其是 UI 图面(如对话框、错误消息和向导) )的新帮助链接。 帮助链接会将你直接转到“帮助”中的相关主题。
  • 大多数控制面板中心页以及 shell 文件夹的右上角都提供了“帮助”按钮图标。
  • 用户可以选择在联机时从 Windows Online 帮助和支持获取最新的帮助内容。
  • 帮助主题现在基于任务而不是以功能为重点,以便用户可以快速高效地完成任务。
  • 现在,帮助主题主要基于已知的热门用户方案。
  • 帮助主题的 语气更轻松、更非正式,使用现实世界的语言。
  • 帮助主题旨在有效扫描,因为用户很少一字一字地阅读内容。

帮助的类比

若要更深入地思考如何设计帮助系统,请考虑日常生活的类比。 你在一个陌生的城市迷路了。 要怎么做? 许多人会做出如下反应:

  • 定向;查找地标、路标 (名称和指向) 地点的指针。
  • 查找地图。
  • 最后,作为最后的手段,询问指示或打电话给朋友。

城市“界面”的设计会影响你的帮助需求。 精心标记的街道、明确的指示 (指向医院、机场、博物馆和邮局的指针) ,以及清晰的地标(如突出的地理特征或建筑物)可帮助你找到自己的路。

你寻求帮助是万不得已的。 这表明,城市的“界面”已经失败,因为设计不善和混乱。 你更有可能在具有建议帮助的特定标签的位置寻求帮助。 例如,你更有可能在标有“路线”或“信息”的地方寻求帮助,而不是像市政厅这样的一般地点,即使市政厅的几乎任何人都可以给你指示。

当你寻求帮助时,你很可能感到沮丧,只是想到达你预期的目的地。 你可能没有心情花时间参观城市或了解其历史。 此外,你的动机取决于任务的重要性。 如果您试图找到您的酒店房间,您将不惜一切代价。 但是,如果你的目标是找到一个次要的地方,你很可能只是放弃后,一个适度的努力。

在实际空间中查找方式的所有这些方面都与用户通常在程序的虚拟空间中找到自己的方式相对应。 在主要 UI 之外寻求帮助本质上是迷失方向的;尽最大努力通过精心设计的 UI 和智能“路标”来缓解此类体验,以引导用户找到他们需要的答案。

设计 UI 以便不需要帮助

首先尝试使帮助成为不必要的,方法是:

  • 使常见任务易于发现和执行。
  • 提供清晰的main说明
  • 提供面向目标和任务的清晰、简洁的控件标签。
  • 根据需要提供补充说明和说明。
  • 通过使用受有效选项约束的控件、提供合适的默认值、处理所有输入格式以及防止错误,来预测可避免的问题。
  • 编写错误消息,为用户提供明确的解决方案或操作。
  • 避免混淆 UI 设计,例如流差的任务或使用无明显原因禁用的控件。
  • 在开发周期的早期与编写者和编辑人员协作,在整个程序中创建高质量、一致的 UI 文本

用户无需前往其他位置来了解如何使用 UI。 将基本信息直接添加到主 UI,而不是强制用户离开其即时上下文并进入“帮助”窗格。 如果重要信息仅存在于帮助主题中,则用户很可能看不到它。 有关可选且更解释性的信息,请使用主要 UI 中的帮助链接,指向相关帮助主题以获取补充帮助。

考虑用户动机

对于大多数用户来说,速度和效率是良好程序的首要优点之一。 用户希望完成工作。 一般来说,他们无意为了自己的原因而学习该计划和技术:他们的耐心只延伸到该计划符合他们自己的利益和解决手头的问题。

设计帮助系统以匹配用户的动机。 例如,假设某个用户漫步到博物馆的展台。 如果她不能弄清楚如何快速完成任务,她很可能只是放弃,走开。 她不太可能花时间使用帮助。 或者,高度激励的用户对花费在研究帮助系统获取答案的时间具有更高的容忍度。 例如,必须平衡账簿的业务用户可能愿意查阅帮助内容,以充分利用新的会计应用程序。

编写要扫描的内容

编写帮助主题,知道它们将被扫描以查找特定信息,而不是一字一字地阅读。 简明扼要,快速了解要点,并提供用户可以操作的信息。

  • 以一致的格式使用编号步骤编写“操作方法”主题,以便用户能够识别他们正在获得过程帮助。
  • 编写参考主题时考虑到易于扫描,例如使用表来呈现 UI 选项或语言语法。
  • 编写按副标题逻辑组织的概念主题,以便用户可以跳过不太感兴趣的整个部分。

在所有帮助内容中,扫描项目符号列表比标准段落文本块更容易;不过,请谨慎使用项目符号列表,而不是作为无组织材料的拐杖。

创建重要的内容

鉴于没有帮助系统可以预测每个用户可能提出的每一个问题,请将大部分内容集中在回答目标用户的热门方案中的首要问题上。 例如,有效搜索以及如何建立网络连接 () 的其他任务可能是备受追捧的主题。 此外,请专注于顶级用户方案中的任务,而不是为了自身原因而详尽地记录功能或技术。

提示: 技术支持是帮助内容的良好来源。 帮助台通常会记录有关用户尝试 (的特定程序或任务的常见问题,) 无法完成这些问题。

无需为 UI 中的每个功能提供帮助。 尝试为一切创建帮助时,常常会产生无益的帮助。 如果 UI 设计良好,这些帮助主题中的大多数都不太有用;他们只会重述显而易见的。

如果有多种方法可以执行任务,在大多数情况下,只需记录经验不足的用户使用的最常见方式。 例外情况包括辅助功能注意事项 (记录鼠标操作的键盘等效项(例如) ),以及平台注意事项 (记录平板电脑外形规格(例如),或者对于命令行可以取代图形用户界面) 的服务器环境。

请记住,用户通常不会以与你完全相同的术语来思考他们遇到的问题。 例如,用户可能会发现将自己视为“帐户”感到奇怪。然后,请务必设计搜索和索引功能,以考虑可能的术语变体和同义词。

不过,在主 UI 和帮助系统之间,如果术语不相同,则应非常相似。 当用户的帮助系统语言与他们在屏幕上看到的内容没有非常密切关联时,用户可能会感到困惑。

从主要 UI 链接到帮助主题时,请务必编写引人注目的帮助链接文本。 清晰而具体的语言激发了信心。 用户倾向于认为,一般帮助链接 (按钮上带有“帮助”或“了解详细信息”一词,) 不会在不投入大量时间的情况下获得正确的信息。

如果你只做五件事...

  1. 设计 UI,使用户无需帮助。
  2. 通过将内容集中在目标用户的热门方案中的热门问题上,使“帮助”有所帮助。
  3. 提供帮助内容,使其易于扫描。
  4. 了解无需为 UI 中的每个功能提供帮助。
  5. 使帮助入口点易于发现且引人注目。

使用模式

不同类型的内容有不同的用途。

内容类型 示例
过程帮助
提供执行任务的步骤。
过程帮助应侧重于“如何”信息,而不是“什么”或“为什么”。
“删除临时文件”帮助页的屏幕截图
在此示例中,帮助主题介绍如何使用磁盘清理实用工具的功能,并提供按顺序执行的步骤。
概念帮助
提供背景信息、功能概述或流程。
概念性帮助应提供完成任务所需的“内容”或“原因”信息。
“桌面 (概述) ”帮助页的屏幕截图
在此示例中,帮助主题定义了桌面是什么,并提供了有关桌面包含的内容以及用户与之交互的其他详细信息。
参考帮助
用作联机参考书。
可以使用参考帮助来记录编程语言或编程语言接口。
“表示约定”帮助页的屏幕截图
在此示例中,帮助主题列出了用于此特定语言或应用程序的版式约定,并在易于扫描的表中提供信息。

准则

入口点

  • 指向特定相关帮助主题的链接。 请勿链接到帮助主页、目录、搜索结果列表或仅链接到其他页面的页面。 避免链接到结构为大量常见问题的页面,因为它会强制用户搜索与其单击的链接匹配的页面。 不要链接到与手头任务不相关且有帮助的特定帮助主题。 永远不要链接到空页面。

  • 为了保持一致性,不要在每个窗口或页面上放置帮助链接。 在一个位置提供帮助链接并不意味着必须随时随地提供它们。

  • 使用对话框、错误消息、向导和属性表的帮助链接。 如果“帮助”链接适用于特定控件,请将其放在它们下方,左对齐。 如果“帮助”链接应用于整个窗口,请将其放在窗口内容区域的左下角。

    带有组框的属性表的屏幕截图

    在此示例中,第二个帮助链接适用于一组控件。

    属性表和帮助链接的屏幕截图

    在此示例中,“帮助”链接应用于整个窗口。

  • 在技术上尽可能使用帮助链接而不是对帮助的一般文本引用。

    正确:

    如何修复磁盘错误?

    不正确:

    有关修复磁盘错误的详细信息,请参阅帮助和支持。

  • 将“帮助”按钮与“帮助”图标用于控制面板项的中心页面。 将其放在右上角。 这些按钮没有标签,但有一个显示“帮助”的工具提示。

    带有帮助按钮的控制面板项的屏幕截图

    带有“帮助”按钮的控制面板项。

  • F1 帮助是可选的。 用户已习惯于通过按 F1 键(在标准键盘上标记为“帮助”)来查找与屏幕上 UI 直接上下文相关的帮助信息。 例如,如果可用性研究表明用户希望找到它,或者程序 UI 足够复杂,可以从上下文帮助中受益,则可以包含 F1 帮助。

  • 具有菜单栏的程序可以具有“帮助”菜单类别。 有关“帮助”菜单指南,请参阅 菜单

    从菜单栏访问的帮助的屏幕截图

    在此示例中,Windows 画图附件具有“帮助”菜单类别。

  • 对于键盘辅助功能,请为“帮助”按钮和链接提供制表位。

  • “帮助”按钮和链接行为应如下所示:“帮助”窗格随即打开,并显示专用的“帮助”主题;调用“帮助”窗格的 UI 应保持打开状态,以保留上下文体验。

  • 请勿使用以下过时的帮助入口点样式:“了解详细信息”或“了解详细信息...”标题栏上的链接、通用帮助按钮和上下文相关帮助按钮。 尽管它们过去曾使用过,但可用性研究已确定用户倾向于忽略它们。 请改用指向特定帮助主题的链接。 有关编写良好帮助链接的指南,请参阅 帮助链接

    不正确:

    带有“了解详细信息”链接的对话框的屏幕截图

    不要使用“了解详细信息”或“了解详细信息...”。链接。

    不正确:

    提交按钮旁边的帮助按钮的屏幕截图

    请勿使用通用的“帮助”按钮。

    不正确:

    标题栏上问号图标的屏幕截图

    请勿使用标题栏上的上下文相关帮助按钮。

Content

  • 不要创建明显的内容。 重复主 UI 中的内容的帮助主题不会增加值。
  • 不要创建用户无法以某种方式执行操作的内容。
    • 例外: 某些概念性内容提供重要的背景信息,不一定会导致用户操作。
  • 避免对问题进行模糊解决方法。 例如,“联系系统管理员”或“重新安装应用程序”往往会让用户感到沮丧。
    • 例外: 如果这是唯一可行的解决方案,并且系统管理员希望就此问题联系,建议与系统管理员联系。
  • 避免处理极不可能的用户方案的内容。 根据预期正常使用情况开发main帮助内容;请注意预期使用情况的重要异常,但将此内容视为较低优先级。
  • 从用户那里收集有关帮助主题的帮助的反馈。 允许用户对单个主题进行评分。 对文档进行 可用性研究 ,以确定涉及内容质量和可发现性的问题。
    • 提示: 用户反馈也是生成更多基于任务的内容的好方法,侧重于用户实际使用程序执行的操作,而不是基于功能的内容,仅关注技术的描述。
  • 提供多种访问内容的方法。 目录、索引和 搜索 机制是提高可发现性的三种最常见方法。
  • 如果有多种方法可以执行任务,在大多数情况下,只需记录经验不足的用户使用的最常见方式。

图标

  • 仅对“资源管理器”窗口和控制面板项的中心页面使用“帮助”图标。 不要将“帮助”图标与“帮助”链接一起使用。

正确:

带有问号图标的窗口的屏幕截图

在此示例中,Windows 资源管理器窗口使用“帮助”图标来提供对“帮助”的访问权限。

不正确:

左侧面板中带有帮助图标的窗口屏幕截图

在此示例中,左下角的“帮助”图标与“帮助”链接一起使用不正确。

文本

“帮助”链接

  • 根据需要使用尽可能多的相关、简洁的文本,提供有关帮助主题内容的具体信息。 用户通常会忽略一般帮助链接。 确保链接的结果是可预测的,用户不应对结果感到惊讶。

    • 例外: 可以使用“更多信息”来补充直接在 UI 中的说明,尤其是在帮助链接中提供特定信息会导致不必要的重复或使链接不那么引人注目时。

    不正确:

    强密码至少有六个混合大小写的字母、数字和符号。 什么是强密码?

    正确:

    强密码至少有六个混合大小写的字母、数字和符号。 详细信息

    在不正确的示例中,“帮助”链接是重复的。 它提出了一个真正已经回答的问题。

  • 只要可能,短语“帮助”会根据帮助内容回答的主要问题链接文本。 请勿使用“了解详细信息”、“告诉我更多相关信息”或“获取有关此的帮助”的措辞。

    不正确:

    详细了解如何添加异常

    正确:

    允许例外有什么风险?

    如何实现添加异常?

    在正确的示例中,链接是按照帮助主题回答的主要问题来表述的。

  • 如果可以简洁地汇总最相关的信息,请将摘要直接放在 UI 中,而不是使用帮助链接。 但是,可以使用帮助链接提供补充信息。

    不正确:

    指向什么是强密码的链接的屏幕截图?

    正确:

    有关密码的补充文本的屏幕截图

    良好:

    包含详细信息链接的文本屏幕截图

    正确的示例简洁地总结了帮助信息,大大提高了用户读取它的可能性。 更好的示例提供了有关此复杂主题的详细信息的帮助链接。

  • 用于明确指示帮助的短语帮助链接。 帮助链接不应像操作链接一样阅读。

  • 将整个“帮助”链接用于链接文本,而不仅仅是关键字。

    正确:

    允许例外有什么风险?

    不正确:

    允许例外有什么风险?

    在正确的示例中,整个帮助链接句子用于链接文本。

    • 例外: 指向外部网站的帮助链接应仅使用网站或页面的名称作为链接。 任何介绍网站名称的文本都不需要包含在链接本身中。
  • 帮助链接不必完全匹配帮助主题标题,但两者之间应该有牢固而明显的联系。 因此,将链接和标题成对设计。

    正确:

    如何提高此功能的性能? (链接文本)

    配置此功能以实现最佳性能 (主题标题)

    不正确:

    如何提高此功能的性能? (链接文本)

    此功能的完整概述 (主题标题)

    在不正确的示例中,帮助主题标题的范围与帮助链接文本存在重大差异,并且可能迷失方向。

  • 如果帮助内容处于联机状态,请在链接文本中明确说明。 这样做有助于使链接的结果可预测。

    正确:

    有关其他格式和工具,请转到 Microsoft 网站。

    不正确:

    在哪里可以找到其他格式和工具?

  • 使用完整句子。

  • 请勿使用结尾标点符号(问号除外)。

  • 请勿将省略号用于帮助链接或命令。

帮助内容

  • 使用粗体设置 UI 元素的格式,使其易于识别。 这对于过程帮助主题特别有用,使用户能够浏览过程并快速查看相关的 UI 元素。
  • 使用斜体设置字幕格式。 这适用于表格、艺术、屏幕截图和其他受益于简短文本说明的图形元素。
  • 将“帮助”简单地称为“帮助”。 通常,请勿使用“联机帮助”短语,除非你实际指的是网站上的内容。