发送邮件
确认订单
发布帖子、启事、公告
银行交易、付款
签署法律文件
永久拉黑用户
授权或撤销权限
预防误操作的方法
防止丢失数据，或者预防无意中采取不可逆操作，惯用方法是让用户二次确认操作。
实现二次确认的方法有很多，各有利弊。
01 模态对话框
首先，请区别模态对话框与非模态对话框。建议把“模态”视为一种状态，因为对话框、弹窗、警告框可能是模态的，也可能是非模态的。建议参考《对话框(Dialog) 一定是模态弹窗吗？》
模态对话框强制要求用户立即操作。也就是说：如果不确认，就无法做其他的事情。
另一方面，非模态对话框不强制用户立即操作，比如 Toast消息 ，并不影响用户做其他的事情。
模态对话框是防止意外点击危险操作的有效方法。
模态对话框有时候也用来进行常规操作的确认（比如完成某个任务），所以用户很容易[手滑]，不假思索的点击确认，同样会触发危险操作，引起懊恼和愤怒。
即便如此，模态对话框是一种最流行的基础方法，可以产生其他变化，防止误操作。
▼何时使用模态对话框？
误操作后果很严重，特别是结果不可逆的情况下，请使用模态对话框。典型场景包括：删除帖子或项目，确认交易等。
▼模态对话框的注意事项
(1) 避免含糊不清的文案
比如，只说“你确定吗？”，然后就让用户决策。具体确定什么东西，用户可能并不清楚。
(2) 标题中要明确具体影响
比如，项目名称、用户名、金额等等，防止操作错误的目标。
(3) 提供一个惊叹号图标
这样减少了用户[手滑]的可能性，并且提升可访问性(即便是色盲，也能感受到惊叹号)。
(4) 突出必要信息
比如，加粗关键提示，甚至给出专门介绍危险性和不可逆原理的帮助链接。
(5) 描述具体的行动召唤按钮
比如，“删除文章”、“支付97美元”、“继续当前交易”、“发送消息”等，这要比通用文案“是/确认”更明确！特别是包含受影响的项目名称或具体金额。
避免使用通用文案，描述应该尽量具体
02 增强版模态对话框
尽管模态对话框能预防误操作，但是如果增加一些额外操作，效果更好。
典型的设计是要求用户键入一些特殊内容(比如项目名称)，才能激活行动召唤按钮。
convertkit.com 的特殊确认，要求用户键盘输入 DO IT，才会执行危险操作。
专业提示：请注意，上图例子中的确认按钮放在了取消按钮的左侧。这是根据格式塔心理学中的“贴近原则”，保证输入框和按钮更贴近(虽然只有一个输入框）。
resend.com 的特殊确认，要求用户键盘输入 DELETE，才执行删除数据。
▼加强版模态对话框的最佳实践：
(1) 对话框标题说明了操作
比如，图中的“Delete API Key”。
(2) 加粗目标项目名称
比如，图中的“Onboarding”是具体的 API Key 的名称。
(3) 警示色强调危害
比如，图中“This can not undone”的红色字体。
(4) 要求用户执行额外确认
比如，图中要求用户键入 DELETE
(5) 明确的行动召唤按钮
比如，图中“Delete API Key”按钮，使用了警示色，并且避免了“确认”或“删除”这样的通用文案。
请注意，Resend 也把主要按钮放在了取消按钮的左侧。
专业提示：虽然《按钮不应该置灰》，但在“加强版确认对话框”中可以例外（比如上面两个例子）。
03 输入密码的对话框
除了键入特殊文本，还可以要求用户输入密码：
OTP (一次性密码/验证码)
PIN (个人密码)
2FA (双重身份认证)
此时，甚至可以去掉行动召唤按钮，直接提交确认。
银行系统要求提供密码确认操作
▼无障碍隐患
输入4~6位数字组成的简单验证码，去掉提交按钮是否影响无障碍使用，一直存在争议。
虽然作者不是信息无障碍专家，但是他觉得去掉提交按钮，并不算重大缺陷。
首先，输入验证码属于中间步骤，界面载入就自动聚焦第一位数字输入框，完全依赖键盘的残障人士可以按下Tab切换到下一个输入框。
最关键的是，由于验证码只有很少的4~6位，在末尾输入后立即提交校验，即便提醒错误，也是可以接受的。
一方面，如果大家非常在意信息无障碍设计，那么必然会涌现出更好的辅助残障技术(译注：作者的意思是不要纠结于输入框)；另一方面，去掉按钮自动提交，简化了操作，即便极少数情况下出现错误，也允许重新输入。
04 专属的“危险操作区”
应该为最危险的操作集中管理，可以称其为“危险操作区”交互模式。
Github 专门开辟的危险操作区
危险操作区可以拥有独立界面，或者放在设置/个人中心的底部。该区域包含一个或多个操作，并且通常与模态对话框等方法配合使用；如果系统中包含大量危险操作，建议设置独立界面来管理它们。
Plausible.io 设置的危险操作区独立界面
▼何时使用危险操作区？
使用危险操作区对不可逆、丢失数据、极有可能造成灾难性后果的操作进行分组管理，通常包括账户自毁、数据擦除、身份变更等可以影响权限或数据读写的操作。
▼危险操作区的注意事项
(1)视觉的警示
使用红色、叹号图标、特殊边框危险区与其他界面元素进行分隔。
(2)描述潜在危险
每个操作都应该清晰描述如果用户误操作会发生什么样的后果。
(3) 故意制造阻碍
用户需要付出额外的操作成本，才能执行不可逆的关键操作。比如要求输入密码、验证码或双重身份认证，防止窥屏或被其他用户滥用。
(4)隔离真正危险的操作
不要为了设置危险区而设置危险区，不要把没什么危险的操作也包括进来。
05 内联防护
已经有很多APP采用内敛确认，也就是当用户执行危险操作时，会变更文案并且要求用户再次点击确认。
Zapier 和 Typefully 等APP 率先使用了这种设计，在社交媒体上引起热议。
Typefully 删除的操作要求再次确认
▼何时使用内联确认？
适用于可能误操作而意外执行的非关键操作。
设计师们提出了异议：如果遇到喜欢双击的用户，还是会产生误操作。
尽管存在争议，内联确认依然要考虑三个要点：
(1)中间地带
需要用户额外操作，但又非常便捷，适合危险性不高的操作。
(2)配合撤销
理想情况下应该提供撤销操作，以便恢复存档。比如“带有内联确认的删除”和“撤销删除”形成组合。
(3)目标差异
内联确认的目标仅仅是防止误操作，并不包括提醒用户执行后果的严重性，这与刚才介绍的其他手段形成了鲜明对比。
用户大部分时间都在浏览其他网站，这意味着用户希望你的网站也与他们熟知的产品有类似的工作方式。
这并不意味着设计师不能引入新设计手段来促进使用，否则，行业就没办法发展了。
模式的逐渐变化，无论设计(从拟物到极简扁平)，还是可用性(从推送通知到实时同步)都是一系列微创新的结果。
Zapier 删除操作的要求再次确认
作者见到某些用户在意外双击之后，试图在第一点击之后策划内联确认来撤销操作。
这种暴力操作，除了产生布局偏移，并不能撤销操作。如果用户每天都遇到这种情况，这种设计手段就不是提供帮助，而是损害用户。
建议给切换确认文案增加100~200毫秒的延迟，防止用户意外双击。
用户群体的专业程度也很重要，大家是否还记得？初学电脑的年代，因为不会鼠标双击，不得不点击IE图标十余下，才最终启动浏览器。
当然，对于 Zapier 和 Typefully 这样的产品，假设用户群体都是专业用户，内联验证就可以让用户受益。
06 双重授权确认
此方法将确认请求发送到另外一个位置，比如：
短信
电子邮件
移动设备上的认证功能
推送系统通知
站内信的
专业提醒：此处并不是身份验证(登录过程)，而是针对危险操作的确认。
作者经常使用发送加密货币的功能，在网站上提交申请之后，必须通过电子邮件批准，才能执行操作。
通过电子邮件验证才能操作的交易
▼何时使用双重授权确认？
汇款、所有权变更和账户销毁等功能，虽然已经位于危险操作区，依然应该附加双重授权确认。大多数用户遇到的情况是银行发送OTP验证码，确认转账或支付交易。
双重授权确认往往会伴随模态对话框出现，本文介绍的所有方法不是孤胆英雄，需要因地制宜的配合使用。
07 审批确认
当流程中涉及两类用户，就可以采用这种机制，形成“申请人”和“审批者”。
申请人想要执行某些危险操作，需要审批者同意。两类用户都会使用模态对话框或本文中的其他手段，核心思想是分离责任降低决策风险。
实际上，读者们肯定多次遇到过此类方法，例如设计师申请修改某个组件的外观，需要得到产品经理的确认，才能生效。
Github合并拉取代码的请求确认
▼何时使用审批确认？
具有一定的严重性，但是需要少数人参与决策的操作。
类比医疗工作场景：
图片来源 https://unsplash.com/photos/a-man-showing-something-on-the-computer-5VkNa1LrS8A
在医学诊断中，寻求第二意见至关重要，两个医生合作碰撞检查不同观点会带来更明智的决策和治疗方案。这是第二意见或审批者必不可少的例证。
很多产品都采用审批确认：
读者们应该把审批验证看成一种单独的方法，或者一种业务逻辑。即便审批者确认了申请，也无法排除申请本身就是危险操作，风险依然存在，只是分担给了多个用户而已。
因此，站在界面体验的角度，审批确认的案例并不是避免用户做出错误的决策。审批只是帮助设计者减少系统中的致命错误。（译注：让它们变得不那么有危害，不那么致命）
思考：真的需要询问用户嘛？
要求用户确认，读者们应该知道这样做的根本目的：
实际上，用户操作并不意味着经过了深思熟虑。
用户的行为，可能是不自觉的心理学现象：
(1)认知惯性
https://en.wikipedia.org/wiki/Cognitive_inertia
一个人倾向于坚持曾经做过的决定，虽然已经时过境迁。例如，绝大多数用户都不会阅读用户协议，无脑点击同意，因为他们只是想尽快使用产品，并不想仔细理解冗长但又重要的文本。
(2)可用性偏差
https://en.wikipedia.org/wiki/Availability_heuristic
人们经常根据习惯或熟悉的场景做出决定，懒得仔细想。当用户看到相同的对话框，他们会根据以前类似的成功经验直接操作。当然，这种对话框迟早失去避免误操作的职能，导致各种不良后果。
(3)认知的守财奴
https://en.wikipedia.org/wiki/Cognitive_miser
人类的大脑都是认知上的守财奴，倾向于更简单轻松的方式解决问题，避免复杂费力的思考方式，这可以节约能量，也是人类进化中获得天性。所以，许多用户看见“是”和“同意”就不假思索点击，根本就不去仔细阅读说明。
(4)有选择的忽略
https://en.wikipedia.org/wiki/Banner_blindness
比如很多用户会自动忽略掉banner广告和类似的形式，只看自己熟悉的界面和曾经喜欢的形式。
此时读者会问：面对这些心理学现象，应该如何应对？
尽管我们无法完全左右用户的心智，但可以采取本文接下来介绍的方法。
08 延迟
有时候，可以故意设计“优雅的拖延”，让用户推迟执行操作。
作者提供的例子是一个叫做Glovo的手机APP，它是一个食品配送电商，在用户下单的时候，会看经历三个界面。
利用进度错觉的送餐操作流程
第一个截图是购物车，是用户选中的商品（还有一个烦人的订阅促销，占据了顶部1/3屏幕）。
点击“确认订单”按钮，跳转到第二个截图，向用户询问地址和货物是否正确，商品清单会以动画逐渐展示，并且还出现了一个“假装载入”的进度条。
几秒钟之后，全部商品展示完成，显示APP尝试从信用卡扣款，这时候的进度条才是“真正载入”。扣款完成后，用户将看到订单状态和大致送达时间。
专业提示：点击“确认订单”按钮出现的动画，扣款完成展示订单动态的动画，会让用户感觉订单即将完成。这个技巧叫 “目标渐变效果”。https://lawsofux.com/goal-gradient-effect/
“我付款了~系统已经开始运作了~他们开始准备我的订单了~太好了！”这就是用户的感受。
购买之后，故意设置延迟的另一个案例
带有“假装载入”的进度条，目的是让用户验证订单信息并确认他们。
这是一种精妙的设计方式：
在早期版本中，用户甚至无法跳过载入的过程，只能取消订单。现在的版本中，添加了“继续”按钮，相当于“确认无误”。
回顾经典的模态对话框确认，其缺点是用户会习惯性的误操作。延迟确认的方法就不一样了：它结合了反馈闭环和忽略流程，让用户至少会注意到地址、订单、价格，给了用户思考的时间和机会，避免无脑点击“是”或“否”。
09 撤销重做
允许用户撤销刚刚执行的操作，从而提供一个安全保障，减少犯错的焦虑。
模态对话框确认是中断工作流，撤销模式则完全不同，它允许继续完成操作，并在需要时选择撤销，提供流畅的体验。
▼何时使用撤销选项？
非常适合非破坏性的、可逆的数据操作，它们不会产生重大和直接的后果：
编辑文档的撤销重做(Ctrl+Z)；
把文件拖进回收站；
更改任务状态（比如不小心标记为“已完成”）；
删除聊天中的消息；
将滤镜用于照片；
结合限时撤销，可以扩展更多应用，因为发送邮件可以在对方没有打开邮件之前撤销；转账也可以在对方没有确认入账之前撤销。
带有倒计时撤销的Toast提示
▼何时不能使用撤销选项？
具有严重后果的危害性操作，无法撤销：
删除账户；
提交法律文件
购买商品(退款并不是撤销)
请求第三方API(多数情况下)
▼何如实现撤销选项？
(1)热键
多数用户习惯的方式是使用Ctrl+Z，但是仅限于某些情况，比如文本编辑器、文件夹操作等。
(2)操作提醒
Toast 可能是在网页和移动应用中实现撤销选项提示的最佳方法。唯一需要注意的是，Toast必须足够引起注意，如果宽屏环境藏在角落里，或者颜色不明显，就完全没人注意。
(3)撤销按钮
提供撤销重做按钮，是更简单的设计方案。
撤销选项与“软删除”息息相关，现在已经很少从物理上销毁数据。
这意味着，当用户通过界面操作删除数据，其实数据并没有消失，只是被标识为“删除”。这就是为什么可以设计出撤销选项的底层逻辑。
虽然，软删除是保留数据的好方法，但并非所有的数据都会这样设计。
比如，法律规定注销账户就必须从物理上销毁数据，那么就没办法撤销。产品应该尽量提供“软删除”机制，这样即便界面上没有撤销按钮，也能手工恢复数据。
结论
作者奉劝各位读者：具体问题具体分析。
现实的复杂，可能会让文本提到的各种手段都失去保护作用。看起来是经过深思熟虑的设计细节，实际上是根据真实用户的各种奇葩反馈不断修改打磨的结果。
用户行为可能受到国家/地区、年龄、文化、教育程度的影响。
管理危险操作的关键是控制好数据，在用户出现问题的时候做好响应。遵循“最佳实践”固然重要，但也不能墨守成规，好似下棋：棋谱只是参考，还要靠临场发挥。
(原文完)
译者的话：
原文中介绍Passkeys的部分没有翻译，中国用户根本无需此类产品，因为我们已经普及“人脸识别”！
- END -
注：交互设计学堂公众号接受投稿啦，如果你有好的原创设计类文章，可联系客服。别让灵感溜走，快来投稿吧~~
