B3.06.3Contextual Help设计研究

使用说明应在需要时就近可得

别名: 就近帮助 · 上下文帮助 · 内联说明 · 最小化说明

概念解释

说明应出现在用户遇到字段、状态、错误或决策的同一位置,而不是要求离开任务去读手册或记住培训内容。上下文帮助(contextual help)包括占位示例、字段旁解释、错误修正、快捷键提示和可展开详情。它和识别优于回忆同组,但管的是另一层:不是"选项要不要摆出来",而是"解释选项含义的那句话,要不要跟着选项一起出现"——即便所有对象与动作都已可见,用户仍可能看得懂"有什么"却不确定"怎么用",这时候缺的是说明,不是选项。

机制

把这条原则讲透,需要区分两种认知负担:内在负担来自任务本身的复杂度,无法靠界面消除;外在负担来自获取答案这件事本身的成本,是设计能压缩的部分。远端文档制造的正是外在负担——用户要先意识到自己不会、记住问题的准确措辞、离开当前屏幕、在陌生的文档结构里检索、读到答案后再把它映射回刚才卡住的具体字段。这五步里的每一步都可能出错或半途放弃,而且都不产生任务本身的进展。就近说明把这五步压缩成一步:答案与问题共享同一个视觉锚点,映射不需要用户自己做。

这也是为什么"内联说明"优于"帮助按钮":按钮仍然是一次跳转,只是跳转距离短了,用户依然要先判断"我是不是该点这个",而好的内联说明让这次判断都省掉——它在用户尚未意识到需要帮助之前就已经出现在视线里。约翰·卡罗尔(John Carroll)提出的"最小化说明"(minimalist instruction)理论支持这个方向:比起先系统学习后动手,人更倾向于直接动手、遇到问题再查,所以说明应该按需出现在出错或卡住的那一刻,而不是要求用户提前通读。

怎么研究

比较条件通常设为三组:无帮助、远端文档(独立帮助页或手册)、就近的上下文说明,测量任务完成时间、首次尝试正确率、求助次数与放弃率。这类研究可以追溯到卡罗尔关于最小化说明的一系列实验,其共同发现是:把说明拆成小块、按出错点插入,比一次性给完整手册更快让新手完成任务,即便后者信息更全。

在界面研究里还有一个更直接的方法:日志分析。统计用户在哪些字段上高频触发帮助图标、反复修改后仍然出错,或在提交后又返回同一处修改——这些位置就是"当前说明位置不对"或者"说明根本不存在"的候选清单,比事先靠直觉猜测该在哪里加说明可靠。有声思维法也适用于此,用户说出"这里应该填什么"的犹豫时刻,往往就是说明缺位的地方。

一个方法论上的提醒:实验室任务给的说明往往是设计者自己写的,容易高估其有效性;更可靠的检验是拿真实客服工单或搜索日志里的高频问题反推说明内容,而不是先写说明再自证有效。

边界

就近不等于所有说明常驻。过多内联文字会遮蔽工作区,重复说明也难维护;复杂流程仍需要文档、教程和支持,这条原则不能替代它们,只能减少对它们的依赖频率。帮助必须与版本、权限和本地化同步,过期示例比没有帮助更危险——用户按一条过时的说明操作,得到的错误比"不知道"更难排查,因为他们会先怀疑自己操作错了。

对高频专家用户,常驻的内联说明会变成噪音:同一个字段他们已经填过上千次,界面还在旁边解释"这里填订单编号",属于视觉干扰而不是帮助,应默认收起。屏幕阅读器用户也是独立边界:帮助内容必须可聚焦、可展开且阅读顺序合理,不能只靠鼠标悬停触发,否则说明对这部分用户等于不存在。

怎么落地

  • 为字段提供一句必要规则和一个正确/错误示例;错误信息直接给修正动作,而不是复述规则。
  • 空状态、无结果、权限不足和禁用控件旁说明原因与下一步,这些位置往往是用户最困惑、也最容易放弃的地方。
  • 用可展开帮助承载长解释,保留上下文和滚动位置,不强迫用户跳转到另一个页面再跳回来。
  • 对高频重复操作的专家界面,把内联说明设为默认收起、悬停或聚焦时展开,避免常驻遮挡。
  • 验证办法:审核帮助点击位置与客服高频问题日志,把重复出现的问题内容迁回对应界面的就近位置;随版本更新回归测试链接与示例是否仍然正确。

延伸

  • 同组B3.06.1 对象、动作与选项应当可见 · B3.06.2 用户不应被要求记住跨界面的信息
  • 相邻T1 界面文案与内容 · Q3 帮助与文档
  • 站内检索contextual help · inline guidance · minimalist instruction · error message

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/B3.06.3