A6.10.7Before invoking memory capacity, confirm the task is genuine unprompted recall设计

判别设计限制是否该援引记忆容量,需先确认用户是否真在做无提示回忆

别名: 记忆容量援引诊断 · 无提示回忆判定 · unaided recall test

概念解释

前面几种误用各有各的表现——把数字套到可见选项上、忽略搜索成本、忽略原始任务类型、忽略科普失真、忽略密码和颜色各自的真实决定因素——但它们能被一次性排除掉,靠的是同一个问题:这个场景里,用户是不是真的在没有任何外部提示的情况下,凭内部记忆生成这段信息?只要答案是否定的,援引记忆容量数字就是错的,不用再逐条排查上面那些具体误用形式。

机制

记忆容量数字描述的是一套特定机制的上限:内容不在眼前、也没有外部记录可查,全靠维持在内部表征里等待被提取。只有当任务真的要求走这套机制,容量数字才谈得上相关;一旦选项可见、允许翻看、可以查阅外部记录,用户走的就是完全不同的路径——识别、搜索、比对——这条路径根本不经过那个受容量限制的维持环节,容量数字自然无从谈起。这一条诊断之所以能一次性覆盖前面所有误用形式,是因为那些误用无论具体表现如何,共同的错误起点都是没有先确认"用户到底有没有被要求做那件事"。

边界

这条诊断不是说记忆容量数字在设计里毫无用武之地——确实存在用户必须在没有任何外部提示的情况下凭记忆使用信息的场景,比如只学过一次、之后再也不会被系统提示的操作口令,或者需要凭空想起某个不常用功能的确切名称再去搜索。这类场景才是记忆容量研究真正对应的对象,这条诊断的作用是把大量并不属于这一类的场景提前筛掉,而不是否定记忆容量研究本身的相关性。

怎么落地

  • 遇到任何援引记忆容量为设计限制找理由的场景,先问三个问题:目标信息在用户做决定的当下是否可见?用户是否被允许查看历史记录、滚动查阅或使用外部工具?这个"限制"讨论的到底是用户能不能同时记住这些内容,还是这些内容能不能被一眼扫描完——只要其中任何一个答案指向"信息可见""允许查阅""其实是扫描问题",就应该放弃援引记忆容量,转去找与该场景真正相关的证据(视觉可辨识度、搜索效率、材料熟悉度等)。
  • 只有当信息确实完全不可见、用户没有任何外部核对渠道、必须纯粹从内部记忆里生成答案时,援引记忆容量数字才有意义——即便到了这一步,还要继续核对被引用数字对应的原始任务类型是否与当前场景匹配,而不是拿到"可以援引"的结论就直接套用具体数字。
  • 验证办法:设计一次简单的对照测试——一组条件下把待记内容持续展示给用户,另一组条件下移除展示、要求用户凭记忆作答,比较两组表现差异。如果两组表现几乎没有差别,说明这个任务本来就没有真正考验记忆,援引记忆容量从一开始就不成立;只有当移除展示后表现明显下降,才说明这确实是一个受记忆容量约束的场景。

延伸

  • 同组A6.10.1 记忆容量的经典数字不适用于视觉选项数 · A6.10.2 菜单项数量的限制来自搜索成本而非记忆 · A6.10.3 引用容量结论时须核对原始任务类型 · A6.10.4 经典容量数字源于一维刺激的绝对判断任务,与多数界面场景结构不同 · A6.10.5 该数字在科普传播中被简化为万能设计法则,脱离了原始实验条件 · A6.10.6 密码长度、颜色种类等设计限制若照搬该数字,缺乏实证依据
  • 相邻A6.05 再认优于回忆 · A6.02 工作记忆容量
  • 站内检索unaided recall test · recognition versus recall diagnostic · design rule audit

同组卡片

快捷操作

分享

分享当前页面

ios_share

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