元素数量不等于认知负荷
别名: cognitive task analysis · 认知任务分析 · 界面元素计数
概念解释
认知负荷取决于完成任务需要做多少判断、记多少信息、检索多费力,屏幕上可数的元素个数只是可能影响负荷的一个因素,经常还不是主导因素。一个仪表盘上摆着十几个各自独立、一眼就能读懂的小卡片,用户几乎不需要额外思考;一个只有三四个输入框的表单,如果字段之间存在复杂的相互依赖关系(填了 A 会改变 B 的可选范围,还要参照 C 才能判断该填什么),后者的负荷可能远高于前者。数出来的元素个数和用户实际要调动的心理资源,是两个不必然同向变化的量。
机制
负荷的大小由完成任务所需的加工步骤决定:要不要比较、要不要在头脑里保留中间结果、要不要从记忆或界面别处检索信息来做判断。元素数量只在这些加工步骤恰好和元素数量成正比时才会和负荷同向变化——比如逐项核对一份清单,元素越多确实要多看几眼。但一旦任务要求的是综合判断而不是逐项核对,负荷取决于综合判断本身牵涉多少变量、多少条件分支,与呈现了几个视觉元素关系不大:三个互相牵制的字段可以比十五个互不相关的独立字段更费脑子,因为后者的十五次判断彼此独立、互不干扰,前者的三次判断却要来回参照。
怎么研究
判断负荷高低不能只靠数元素或凭直觉判断"看起来简不简单",需要用能反映实际加工投入的方法:让用户在完成主任务的同时执行一个不相关的次要任务(次任务法),主任务负荷越高,次任务的表现下降得越明显;也可以直接对任务本身做认知任务分析,拆解出完成任务实际需要多少个判断步骤、每步要参照几处信息,用步骤数与信息依赖关系作为负荷的操作化指标,而不是数视觉元素。
常见自变量:任务要求的判断步骤数与信息依赖关系、界面上呈现的元素数量(作为对照变量)。 常见因变量:次任务表现下降幅度、主任务完成时间与错误率。
这套方法在人机交互里常用来纠正"看起来复杂等于难用、看起来简单等于好用"的评审惯性,用实际测量代替视觉观感的直接推断。
方法论注意点:元素数量本身仍然值得记录,但只能作为负荷的众多输入之一,不能单独当作负荷的替代指标来下结论,混淆两者会让"删减几个元素"被误当成"降低了负荷"的证据。
边界
- 当任务本身就是逐项独立核对(清单式检查),元素数量与负荷的相关性会比较高,这时数元素作为负荷的粗略估计是可以接受的近似。
- 一旦任务涉及跨元素的比较、依赖或推理,元素数量与负荷会明显脱钩,此时不能再用元素计数来估计负荷。
- 这条讲的是数量这一个维度失效的情形,不涉及视觉呈现方式(分组、层级、一致性)如何影响负荷,那些是复杂度的其他维度,需要分别处理。
怎么落地
- 评审界面时,不要用"这一版元素更少所以负荷更低"作为通过标准,先做任务分析,确认改动是减少了完成任务所需的判断步骤,还是只是减少了看得见的元素数量。
- 对涉及多字段相互依赖的任务(表单、配置项),优先降低字段之间的依赖关系数量或把依赖关系显式呈现出来,而不是简单删减字段数量。
- 验证办法:用次任务表现或任务完成时间比较改动前后的实际负荷,而不是只统计元素数量的增减;如果元素变少但次任务表现没有改善甚至变差,说明这次精简并没有真正降低负荷。
延伸
- 同组:A9.05.2 结构清晰的密集界面可能低于稀疏但混乱的界面 · A9.05.3 简化外观而隐藏结构会提高负荷 · A9.05.4 客观结构复杂度与用户主观感知复杂度并不总是一致,会各自独立变化 · A9.05.5 视觉复杂度指标与实际认知负荷的相关性较弱 · A9.05.6 跨屏幕的不一致会叠加复杂度,超出单屏幕内部复杂度的简单加总 · A9.05.7 视觉上更美观的界面常被误判为更易用,掩盖了实际负荷的差异
- 相邻:A2.12 简约与最小化倾向 · A9.02 负荷的测量
- 站内检索:
cognitive load·cognitive task analysis·dual-task method·element count