H3.05.2confirms catch mistakes not slips设计研究
确认对失误无效，只对错误有效
别名: 失误与确认 · slip vs mistake · 确认无效
概念解释
失误是意图正确、执行滑了：本想归档，点成了删除。错误是意图本身就不该在这一刻成立：以为这是测试库，其实是生产库。确认对话框多问一次「你要做这个吗」，只能拦下还在思考计划的人，拦不下已经把点击练成技能的手。用确认去防手滑，是认错了恢复对象。这条区分确认能拦什么，不管确认出现得有多勤，也不管撤销入口怎么摆。
机制
确认要起作用，人必须在第二下之前重新评价计划。失误发生在执行层，计划在点下去之前已经通过，第二下只是同一计划的回声，对话框文案与意图匹配，于是被当作流程的下一拍。错误发生在判断层，人若被强迫把对象和后果读进工作记忆，有机会发现「这不是我以为的世界」。所以确认的唯一正当认知工作是核对对象身份与后果预测，而这只对还没自动化的、高代价的判断有用。防手滑要靠让结果可逆、让目标不好误触，而不是再问一句同意。
怎么研究
构造两类失败：邻钮误触（失误）与选错对象（错误），每类交叉有确认 / 无确认。
自变量：差错类型、确认是否出现、确认文案是否点名对象。 因变量：失误是否仍发生、错误是否在确认上被纠正、确认上的注视是否接触对象名。
事后访谈要立刻做，否则人会把结果合理化成「我当时就想删」。眼动上若确认按钮先于对象名被看，这一试次里确认没有在做判断。
边界
极度陌生的任务里，连点击都还没自动化，确认偶尔也能拦住失误，因为人本来就在逐步核对；这测不到熟练路径上的真实情况。时间压力会把错误压成看起来像失误的快点，分类要靠操作前的意图报告，不能只看速度快慢。确认文案若完全不提对象，对错误也无效——没有材料可核对，判断层无事可做。
怎么落地
- 复盘事故时先问「当时想做的是不是这件事」。若是手滑，从可逆性和目标间距上改，不要加确认。
- 若是选错对象或选错环境，才考虑确认，并且确认必须让对象和后果被核对，而不是再要一次同意。
- 同一入口既会产生失误又会产生错误时，优先做可逆；确认只加在不可逆的那一截。
- 验证：把最近的误删日志分成「点错控件」和「删错对象」。前一类在加确认之后若几乎不下降，确认就用在了失误上。