H3.04.1undo without interrupting the happy path设计研究
撤销不打断正常流程
别名: 撤销优于确认 · undo vs confirm · 不打断
概念解释
可逆操作的默认恢复策略是先做、再给撤销，而不是先问「确定吗」。撤销把纠正放在动作之后，正常路径保持一条直线。确认把每一次动作变成两次决策，成功路径也被征税。这条只谈「可逆动作不该被确认打断」，不谈撤销按钮摆在哪、窗口还剩几秒、也不谈确认框为什么会被点穿。
机制
熟练操作是一条被编译好的动作链。确认插在链中间，等于每完成一步都要出栈做一次元决策，链就不再流畅。撤销则让链跑完，纠错发生在结果已经可见之后：人看见「已归档」再决定要不要拉回来，判断的是结果而不是对未来的想象。失误（意图对、手滑了）在动作当时无法被第二下点击接住，因为第二下仍是同一套自动化；等结果出现，失误才变得可发现。所以对可逆动作，打断成功路径去防手滑，防不住，只是让所有人都变慢。
怎么研究
同一删除任务做成「确认后删除」与「删除后若干秒内可撤销」，对象是被试刚组织好的内容。
自变量：恢复策略是事前确认还是事后撤销、任务中该动作的重复次数。 因变量：误操作率、完成时间、主任务被插入决策打断的次数、事后对「我刚才做了什么」的复述。
实验室损失不够真时，确认组会更快点掉对话框，撤销组的优势会被低估。用「自己刚写的东西」比用实验者提供的假文件更接近真实犹豫。
边界
不可逆且高后果的动作不能靠这条改成先做后撤——没有等价的撤销时，成功路径被打断是故意的。法律要求事前同意的场景，撤销不能替代同意。协作中别人已经基于结果采取了下一步（已通知、已付款），撤销会伤及第三方，需要另一套范围规则。专家在高重复的可逆动作上最受益；新手第一次做破坏性动作时，可见的结果加撤销仍然比空确认更有教益。
怎么落地
- 列出所有带「确定吗」的可逆动作（归档、移出视图、取消星标、退回草稿），改成立即执行并在结果处提供撤销。
- 成功路径上不再插入模态问句；需要防手滑时，靠结果可见和事后纠正，而不是事前再点一次。
- 把确认预算留给确实没有对等撤销的动作，避免可逆与不可逆共用同一套打断。
- 验证：走一遍主任务，数成功路径上被对话框拦住的次数。拦下的若是可逆动作，这条策略就还没换过来。