A6.10.1Classic capacity numbers don't govern visible option counts研究设计

记忆容量的经典数字不适用于视觉选项数

别名: 菜单长度误用记忆数字 · 视觉选项数上限 · recall versus display

概念解释

一种常见的说法是"界面上的选项不该超过某个记忆容量数字,否则用户记不住",然后据此给菜单项数、图标个数、色板颜色种类设一个上限。这个推理把两件结构完全不同的事混为一谈:记忆容量数字衡量的是人在看不到刺激本身的情况下,能凭空维持并复述多少独立项目;而一份摆在屏幕上的菜单,从用户打开它到做出选择的整个过程里,所有选项一直可见。用户做的不是"回想有哪些选项",而是"扫视已经呈现的选项",这两件事用的不是同一套受容量限制的机制。

机制

记忆容量的限制作用在于维持不可见内容的可提取状态,是维持机制本身容量有限;而当选项持续可见时,屏幕本身就充当了外部存储,用户不需要在心里主动维持任何一个选项——需要哪个就直接去看哪个,找不到就重新扫视一遍,整个过程都不依赖把选项"装进脑子里"这一步。既然用户根本没有被要求执行那个受容量限制的心理动作,用衡量那个动作上限的数字去限制一份始终可见的选项列表长度,两者在因果链条上就没有搭上。

怎么研究

判断某个容量数字能不能用来限制一份可见选项列表,先要核对原始研究的任务设计:被试是在刺激消失后凭记忆作答,还是在刺激持续呈现的情况下做选择或判断。前者是回忆类范式,后者是识别或视觉搜索类范式,两类范式给出的"上限"数字含义完全不同——识别类任务通常能在远高于经典记忆容量数字的选项数量下依然保持很高的正确率,出现困难时的原因也不是记不住,而是扫视和比较耗时变长。

边界

一份始终可见的列表并非在任何情况下都与记忆无关:如果界面要求用户先看一屏选项、翻页或跳转后凭记忆在下一屏做出对应选择,或者要求用户记住自己在多层级菜单里已经选过的路径以便日后无提示地回到同一处,这时才重新引入了真正的回忆负担,值得单独评估;但那已经是另一种任务结构,不能反过来证明"选项数量本身"受记忆容量数字约束。

怎么落地

  • 停止用任何版本的记忆容量数字去论证菜单项数、图标数量或色板颜色种类的上限——只要选项在用户做选择的整个过程里持续可见,这类引用就是把回忆类实验的结论套用到识别类任务上,站不住脚。
  • 如果确实需要为一份可见列表设定合理的长度上限,改用直接测量的方式:记录不同选项数量下用户找到目标项所需的时间和出错率,用这份数据而不是记忆研究的数字来定上限。
  • 验证办法:对同一份界面做几种选项数量的版本,测量用户完成选择任务的时间与错误率曲线,只有当曲线在某个数量之后明显变差,才说明存在需要处理的问题,而这个问题该归为搜索效率而不是记忆容量。

延伸

  • 同组A6.10.2 菜单项数量的限制来自搜索成本而非记忆 · A6.10.3 引用容量结论时须核对原始任务类型 · A6.10.4 经典容量数字源于一维刺激的绝对判断任务,与多数界面场景结构不同 · A6.10.5 该数字在科普传播中被简化为万能设计法则,脱离了原始实验条件 · A6.10.6 密码长度、颜色种类等设计限制若照搬该数字,缺乏实证依据 · A6.10.7 判别设计限制是否该援引记忆容量,需先确认用户是否真在做无提示回忆
  • 相邻A6.02 工作记忆容量 · A6.05 再认优于回忆
  • 站内检索magical number seven misuse · recognition versus recall · menu length

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/A6.10.1