C9.13.4No perceptible UI change without a correction path设计研究

无法提供纠正入口的隐式推断不应用于改变用户能感知到的界面行为

别名: 无纠正则不改界面 · 可感知行为 · 隐式写入禁令

概念解释

如果做不到让人看见并反对这条推断,它就不该改用户能察觉的界面:主题、音量、通知策略、锁键、对外可见的状态。推断可以停在内部缓冲、日志或低置信分数,等待一条显式通道。没有纠正路径的隐式,只允许不可感知的预备(预加载缓存),不允许写入体验。

机制

可感知的改变是一次对用户世界的写入。写入一旦发生,缺少反对入口就把错误冻成事实,发现窗口关闭后无法回收。内部预备(把下一首歌放进内存、把灯的驱动预热)不占用这条写入,失败也不可见。分界在「人能否用感官或社交后果察觉」。后台模型更新若会在下次打开时表现为不同的首页,那已经是可感知延迟写入,同样需要纠正或不要做。这条规则把纠正能力当成改变体验的许可证,而不是事后补丁。

怎么研究

列出产品中每一处由隐式推断驱动的可观察变化,检查当时是否存在同屏反对。自变量:有无纠正、变化是否被设计为「微妙」。因变量:未纠正错误的存活时间、用户察觉但无法反对的比例。「微妙」不是豁免:能被察觉就不能豁免。对照组是把同样推断只用于预加载,看任务收益是否仍在、可感知错误是否消失。

边界

法律要求的不可关闭警报可以改变可感知界面且纠正受限,但必须从便利性隐式里划出并单独告知。预加载若通过内容闪现、网络提示变得可感知,就越界了。多人界面上「别人能看见」也是可感知,不能只问佩戴者。完全不可感知的分析(聚合统计、离线训练)不适用这条,但一旦结果回到个人界面,就适用。

怎么落地

  • 发版前把隐式推断画成表:内部预备 / 可感知改变;后者必须有纠正,否则删掉该改变。
  • 做不到同屏纠正的推断,降级为日志或建议收件箱,不直接改当前体验。
  • 延迟显现的改变(次日首页)要在显现时带纠正,不能因为当时「还看不见」就豁免。
  • 验证:关掉所有纠正入口做一次走查,所有仍能被看见的自动改变都是违规写入。

延伸

  • 同组C9.13.1 用户应能查看系统当前依据何种信号做出了何种推断 · C9.13.2 纠正入口需要与推断结果同时出现,而非藏在设置深处 · C9.13.3 一次纠正应能反映到后续同类推断,否则用户会重复纠正同一错误
  • 相邻C9.05 隐式交互 · C9.12 隐式交互与系统主动性
  • 站内检索perceptible UI change · correction as license · preload versus commit

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/C9.13.4