E6.12.2action-required notice设计
需要用户操作的提示不得自动消失
别名: 需操作提示 · sticky notice · 带按钮的提示
概念解释
提示上如果挂着「撤销」「查看冲突」「授权」这类必须由用户完成的动作，这条提示就升级成需操作提示。它不得按计时器离开。动作还在，载体却消失，等于把按钮从人手里抽走。重要性策略可以决定一条纯告知走自动还是手动；一旦有必须完成的动作，结束权就被动作锁死，只剩「做完」或「明确放弃」两种。
机制
带动作的提示把「阅读」和「执行」绑在同一块表面上。计时器切断的是执行窗口：人可能刚读完按钮文案，手还没落到目标上，表面已经没了。撤销尤其苛刻，因为动作的意义就是在短窗口里反悔；窗口由系统单方面收起，反悔权变成抽奖。即使用户看见了动作，消失后也往往没有第二入口——冲突清单只活在那条提示里，授权弹层的触发器随提示一起走。自动消失把需操作提示降级成了告知，但按钮的存在又在说它不是告知，两种语义打架。人会要么慌着去点，要么点空之后以为自己错过了不可恢复的一步。
边界
「了解更多」链到一篇文档，通常不是必须完成的动作，提示仍可按告知来结束。撤销若在历史记录、回收站里另有入口，提示上的按钮是快捷方式，计时器结束不再等于抽走反悔权——但仍应在提示里写明另一入口，否则用户不知道快捷方式不是唯一窗口。动作需要很长时间（去另一应用完成授权）时，提示更不能自己走，而应变成事态，直到授权回来。批量里每一项都「撤销」会把需操作提示堆成队列，应改成一条带「撤销全部」的，而不是让十条各自与计时器赛跑。
怎么落地
- 扫描所有带按钮的提示：按钮若是撤销、修复、授权、查看必须处理的对象，关掉自动消失。
- 结束条件写成动作完成或用户关掉；关掉若等于放弃动作，要在按钮之外提供以后还能找到的入口，或在关掉前说清后果。
- 不要给需操作提示做「看过即消失」；看见不等于完成。
- 验证：让提示出现后不要立刻点，等它自己走。走了而动作无处可去，这条提示就在回收执行权。