破坏性操作不应放在通知内
别名: 通知里的删除 · 栏内危险操作 · shade destructive
概念解释
通知上的按钮处于低上下文、易误触的位置：锁屏、通知栏、手表小面。破坏性操作——删除、永久拒绝、转出资金、把会议从别人日历抹掉、发一条不可撤回的回复给全员——不应放在这里。可逆、局部、失败了还能补的动作才适合快捷；破坏性的要进应用，让对象、后果和撤销条件同时在场。
这条是什么不该放。它不否认快捷动作能省切换，也不谈点了之后卡片如何承认。
机制
通知动作被设计成一眼能按。一眼意味着：手指目标小、相邻卡片近、设备可能在口袋或单手握持、注意力还在别的任务上。误触概率高于应用内的主按钮。应用内至少还有对象全文、二次确认或撤销窗。通知上这些防护要么没有，要么被压成与主动作同样大的第二个按钮，防护失效。
破坏性还常超出卡片可见的范围：删除的是整条线程还是这一则、拒绝的是这次邀请还是以后所有、钱转到哪。卡片给不出范围，人按的是对「眼前这行字」的反应，不是对后果的决定。
怎么研究
把同一破坏性动作放在通知上与应用内深层，比较误操作率、事后撤销、以及人能否说出动作的范围。
自变量：按钮是否在锁屏、是否与「归档」等安全动作并排、破坏范围是否写在按钮上、有无短撤销窗。 因变量：误触率、意识到范围错误的比例、撤销使用率、把误操作归咎于「没看清」的报告。
实验室里人知道要小心，会低估误触。更硬的做法是在真实持握和走动中点相邻的安全动作，看破坏性按钮被擦到的次数。不要把「加了确认」当成已经安全——确认若与主动作同等轻，只是多一次误触。
边界
有些角色的工作就是在通知上做高风险决策（交易员、调度）。那是专用工作台，不是消费级通知栏，应有自己的防护与审计。不可逆但法律要求「一键确认收到」的签收，破坏性在于法律责任而非数据删除，仍应进到能展示全文的表面。若系统提供真正能挽回的短窗口（误删进回收站且通知上能撤销），「删除」可以降级为可逆，但永久清除仍须离开通知。
怎么落地
- 通知上只放可逆动作；删除、付款、全局拒绝、群发不可撤回回复全部改为点进对象页。
- 不要用滑一下或与归档并排的红按钮承担破坏性。
- 若业务坚持要「栏内拒绝」，范围必须写在按钮上，并给数秒撤销，撤销失败则不当成已完成。
- 验证：把归档和删除并排放在测试卡上，在走动中让人去归档。删除被点到，或人说不清删的是一则还是整线程，这个动作就不该在通知上。