前言
讨论了如何在用户界面中有效管理危险操作，以防止用户误操作。今日前端早读课文章由 @ikoofe 翻译，公号:ikoofe 授权分享。
正文从这开始～～
用户界面是用户与系统之间的交互层，用于实现用户与系统的通信。通常，用户与界面交互时需要执行特定的操作，不同的操作会产生不同的结果。
良好的用户界面设计至关重要，它应尽可能防止用户犯错。我们要时刻牢记 尼尔森十大设计原则 ，其中在 “错误预防” 原则中提到：好的错误消息很重要，但是最好的设计首先要防止问题发生。要么消除容易出错的条件，要么检查它们并向用户提供确认选项，然后再执行该操作。
【第82期】产品中的错误预防机制–“细节：别让我出错”
什么是危险行为？
“危险行为” 指的是对用户可能产生重大且关键后果的操作行为，并不一定是指删除某些内容的操作。例如在银行应用中，意外点击 “获取资金” 按钮可能导致在非本意的情况下获得贷款，这就是一种危险行为。以下是银行应用程序中的危险操作示例：
下面列了一些常见的危险行为：
发送电子邮件
下订单
发布帖子
进行银行交易
签署法律文件
永久阻止用户
授予或撤销权限
本文旨在探讨和明确在特定场景下哪些操作可以被定义为危险行为。
危险行为的确认操作
在界面设计中，为了防止用户无意中进行危险操作，需要对此采取一些策略。其中的一种方法是要求用户明确确认他们的操作。
模态对话框
首先，我们介绍一下模态对话框和非模态对话框之间的区别：
如果使用得当，模态对话框是防止意外点击危险操作的有效方法。模态对话框的主要问题在于，如果被用于确认日常操作（比如将任务标记为已完成），可能会引起用户的厌烦，并让用户养成在无意识状态下自动确认的习惯。
然而，这是当下最流行的方法之一。此外，它可以与其他方法结合使用，所以让我们更深入地研究它。
【早阅】仅使用CSS和Popover API开发模态框
何时使用模态对话框
当用户操作将产生严重后果时，尤其是在操作的结果是不可逆的情况下，请使用模态对话框。典型情况包括删除帖子或项目、确认交易等。这取决于用户想要采取什么样的行动，但最关键的是后果是否严重以及行动是否可逆。
注意事项
避免使用含糊不清的语言。当向用户提出 “您确定吗” 这样的问题时，这样的问题比较模糊和笼统，没有提供具体的信息让用户去思考和产生疑问。在很多情况下，用户可能会习惯性地直接回答 “确定”，而没有真正仔细考虑他们即将进行的操作可能带来的后果。
在标题中，指定具体将发生的情况或将受影响的内容（例如，项目名称、用户名、金额）。
提供一个图标，指示操作是危险的。图标既增加了用户不自动确认它的可能性，又有利于可访问性（即使色盲人士会注意到该图标，即使它对他们来说是灰色的，这表明它的重要性）。
在描述中，要具体并突出显示必要的信息
号召性用语按钮（CTA button）还应包含反映操作的词语。不要使用 “是” 或 “确认”，而是使用更具描述性的选项，例如 “删除”，“支付 97 美元”，“进行交易”，“发送消息” 等。按钮中的实体名称或金额也很有帮助。与 “确认” 相比，“支付 97 美元” 要具体得多。
在特定情况下，可能需要用户进行额外的操作。一种常见的解决办法是让用户输入特定内容（比如项目名称），以便解除对 CTA（号召性用语）按钮的阻止状态。
额外的用户操作
在某些场景中，用户仅进行常规操作可能无法触发 CTA 按钮，只有当用户输入了要求的内容后，才能使 CTA 按钮变为可点击状态，从而执行相应的关键操作。例如在某些软件中，当用户想要进行一些重要操作如删除项目时，可能会被要求输入项目名称来确认操作意图，确保操作的准确性和安全性。
【早阅】使用CSS @starting-style为对话框和弹出框元素添加动画效果
比如，ConvertKit 要求用户在删除订阅者时键入 “DO IT”。请注意，它们将按钮放在了左侧！这是应用邻近法的一个很好的示例。这样是很合理的，因为提交按钮更靠近表单（即使它只包含一个输入）。
如果用户想删除 API 密钥，Resend 会要求用户键入 “DELETE”。API 密钥可能用于许多应用程序，删除操作可能会产生非常严重的后果。
上面这个例子是一个最佳实践：
标题说明了操作是什么 （“Delete API Key”） 。
在文本中，他们以粗体和不同的颜色（“Onboarding”）提到了 API 密钥的名称。
操作无法撤消的红色标签更清楚地表明这是一项严重的操作。
需要执行额外的操作（键入 “DELETE”）。
CTA 按钮有一个颜色提示（红色通常用于破坏性操作）和一个适当的标签 — “删除 API 密钥”。不是通用词，例如 “确认” 或 “删除”。
另外，Resend 也将按钮放在左侧，与 ConvertKit 一样。
通常禁用提交按钮被认为是不好的做法，但这是可以接受的情况之一。对话框的请求在 ConvertKit 和 Resend 示例中都清晰明了。
省略提交按钮除了禁用提交按钮之外，我们甚至可以完全跳过提交按钮。这适用于要求用户输入 OTP、PIN 或 2FA 代码的情况。例如，我使用的银行应用程序甚至没有登录按钮。一方面，我们仍然要求用户执行额外的操作 （输入代码）。另一方面，它消除了额外点击的需要。比如，银行应用要求用户可以使用验证码登陆，这里并没有提交按钮：
关于在输入简单的 OTP 时是否包含提交按钮，一直存在争议。这里所说的 “简单” 是指由 4-6 位数字组成的数字。虽然我不是无障碍专家，但我不认为在像这样简单的情况下省略提交按钮有什么重大缺点。
首先，OTP 步骤通常是用户流的中间部分，这意味着在某个过程中会出现具有 4 个输入的表单。第一个输入会自动聚焦，用户可以使用 Tab 键浏览它们。关键是，由于所需的信息量很少（四位数），因此在输入数字后立即自动提交表格通常是可以接受的，即使出现错误。一方面，如果我们关心可访问性，那么没有什么能阻止我们为用户提供对输入的控制。另一方面，在大多数情况下，自动提交简化了流程，并且在极少数情况下出现错误，用户可以轻松地重新输入数字。
【第2603期】Web 可访问性与无障碍最佳实践
危险区域
对于最关键的操作，您可以使用所谓的 “危险区域” 模式。
比如，上面的截图中是 Github 存储库危险区域设置。实现此目的的常见方法是拥有一个专用页面，或将操作集中放在 settings/account 页面的底部。它可能包含一个或多个操作，并且通常与其他方法结合使用，例如模态对话框。执行的操作越多，就越有可能需要一个专用页面。比如，Plausible 有一个专门的 Danger 区域页面。
何时使用危险区域
使用 Danger Zone 对不可逆或极有可能丢失数据或对用户造成重大后果的操作进行分组。这些操作通常包括帐户删除、数据擦除或权限更改等可能影响用户访问权限或数据的操作。
注意事项
使用红色、警告图标或边框等颜色在视觉上将 Danger Zone （危险区域） 与页面的其余部分区分开来。
危险区域中的每个操作都应该清楚地描述如果用户继续操作会发生什么，以便用户了解潜在的后果。
要求用户付出额外的成本。通常，这些操作是不可逆且关键的。在这种情况下，您可以要求用户重复他们的密码或使用 2FA，因为如果其他人可以访问该页面，那么执行有害操作将不是那么容易。
只保留真正关键的操作。避免为了拥有危险区域而设立危险区域。
內联守卫
最近，我发现一些 App 已经开始使用内联确认了。这意味着当您单击危险操作时，它会更改其标签并要求您再次单击。Zapier 和 Typefully 等应用程序使用这种模式。虽然乍一看似乎很方便，但它在 X 和 LinkedIn 上引发了很多讨论和问题。
何时使用内联守卫
內联守卫适用于可能由于误点击而意外执行的非关键操作。设计人员社区提到了一个问题，即用户仍然能够通过双击来执行操作。但是，需要考虑三件事：
这种确认对于不危险的操作很方便，但同时，最好要求额外的行动。
理想情况下，我们应该提供一个选项来撤销操作或将已删除的项目推送到存档页面（以防我们删除了某些内容）。这是确保用户安全的良好组合。
內联确认的目的是防止意外点击，这与我们提醒用户其操作的严重后果的情况形成鲜明对比。
尽管雅各布定律说，“用户大部分时间都花在其他网站上。这意味着用户希望您的网站的工作方式与他们已经知道的所有其他网站相同。” 这并不意味着您不能通过引入新模式来促进应用程序的使用。否则，Web 根本不会发展。下面是 Zapier 在删除操作时要求确认操作：
当然，也有人试图通过更改第一次单击后出现的内联确认标签的位置来修复意外双击。但这会产生布局偏移。当用户每天使用该应用程序时，它可能会引起更多的干扰而不是帮助。
在特定情况下，为了解决可能出现的双击问题，可以选择添加一个 100 到 200 毫秒的微小延迟。这样做的目的是防止用户在进行某些操作时，由于快速双击而意外触发不期望的结果。
了解用户群体也很重要。不同的用户可能有不同的行为习惯，因此在设计产品或考虑交互方式时，需要充分考虑目标用户是谁，他们的行为特点和习惯可能会对产品的使用产生影响。
对于內联守卫模式，如果目标受众容易出现误操作，那么该确认模式可能就无法发挥应有的作用。但是，对于像 Zapier 或 Typefully 这样的应用程序，我的假设是目标受众可能会从这种模式中受益。
双因素认证（2FA）确认
此方法涉及将确认请求（无论是否包含某种验证码）发送到另一个位置，例如：
推送通知（例如，您可以选择发送推送通知，而不是发送 SMS）
用户在使用发送加密货币的应用程序时的一种情况。因为发送加密货币是敏感请求，所以除了在网站上提交申请外，还需要通过电子邮件进行批准。
何时使用双因素认证确认
它可用于汇款、所有权转让和账户删除等操作（即使您有危险区域）。我们大多数人在网上支付时经常使用这种方法，我们的银行会向我们发送 OTP（一次性密码或一次性代码）。它可能会在第一个初始保护方法之后，例如确认对话框。
这些方法经常被组合使用。我们不应该孤立地考虑它们中的每一个，而应该在整个业务流程的背景下考虑它们。
密钥
密钥是一种现代的无密码身份验证方法，旨在增强安全性和用户体验。在双因素认证（2FA）上使用密钥在安全性和用户体验方面具有一些优点。具体如下：
与 2FA 通常需要从其他设备或应用（如短信或身份验证器应用）输入代码不同，密钥简化了确认过程，无需在设备之间切换或等待代码到达，可提供即时身份验证。
2FA 虽提供额外保护，但易受网络钓鱼、SIM 卡交换或拦截攻击，而密钥因使用公钥 - 私钥加密，对这类攻击抵抗力更强，且不会通过网络发送密码，使其能抵御网络钓鱼，不依赖可能被泄露的短信或电子邮件。
密钥需要用户付出较少脑力劳动，无需记住密码或输入代码，只需用指纹、面部识别或设备特定 PIN 进行身份验证，可减少认知负荷。
使用密钥时身份验证过程几乎是即时的，不像 2FA 用户可能需等待代码或切换设备，密钥让用户在不切换上下文的情况下确认操作。
密钥受到广泛支持，越来越多的公司采用它，passkeys.io 的屏幕截图显示了一些已经采用 Passkeys 技术的公司：
第二人确认
“第二人确认” 是一种机制，当流程中涉及两个用户时使用。其中一个用户作为发起者提出执行某些操作的请求，另一个用户作为审批者决定是否确认该请求。
在两个角色中可以使用确认对话框或其他用户界面模式。其主要目的是分离责任，降低错误决策的概率。例如开发人员提交代码，代码审阅者决定是否合并代码：
何时使用第二人确认
它最适合需要几个人参与的决策的情况。不过，它也可以看作是一种实现业务逻辑的方法，因为即使有另一个人确认操作，该操作仍可能是危险操作，只是现在由另一个人进行批准。下面是一些使用该模式的示例：
GitHub，如前所述，用于合并拉取请求。
Jira 和其他类似应用程序。例如，当您在某个工作流阶段移动问题时，可能需要经理批准。
银行应用程序。当您进行高价值交易时，可能需要验证它是否存在法律问题。
Deel，这是一个全球招聘和工资单。一部分（例如，雇主）起草了一份合同并将其发送给另一部分（例如，自由职业者），自由职业者接受了它。
从用户界面角度来看，它不是一种完全独立的保护用户不做出错误决策的特定方法，而是一种有助于减少严重错误数量的方法。
我们真的需要询问用户吗？
当你让用户去执行某个操作的时候，你必须要清楚这个操作的原本目的是什么。用户在进行某种操作或行动时，并不一定是经过深思熟虑、有意识地去做的。有许多行为现象来自心理学，仅举几例：
惯性思维：一个人常常会倾向于坚持自己熟悉的决定，即便这些决定在当前的实际情况下并不合适。例如，在很多场景下，绝大多数人不会去仔细阅读用户协议，只是因为从法律层面考虑，必须同意这些冗长的文本，所以就直接选择同意，而没有真正思考协议内容是否符合自己当前的具体情况。
可得性捷思法：人们在做决定时，往往倾向于依据容易获取或熟悉的信息，而不是花费精力去深入思考。对于用户来说，当他们多次看到相同的确认弹出窗口时，由于之前有过成功点击确认的经验，所以很可能会不假思索地自动接受这些弹出窗口。然而，这种行为方式迟早可能会出现问题，因为盲目接受确认可能会导致不良后果，比如进行了错误的操作、造成数据丢失等。
认知的吝啬者：人类的大脑被认为是认知的吝啬者，因为人类倾向于以更简单、更轻松的方式思考和解决问题，而不是以更复杂和费力的方式思考和解决问题，而不管智力如何。这就解释了为什么许多用户只是点击 “是” 或 “同意” 而没有仔细阅读文本。
一个有代表性的例子是 “Banner 广告盲区”。虽然 Banner 广告盲区与确认操作没有直接关系，但是它所涉及的现象与确认相关情况围绕着相同的人类行为特质展开，这些特质包括惯性思维、可得性捷思法、认知的吝啬者等，表现出人类在面对信息时倾向于以简单、不费力的方式思考和解决问题，容易忽略一些信息，例如人们不阅读用户协议而直接同意等行为特点。
尽管我们无法完全影响用户的行为，但我们可以使用一些策略。
延迟
在某些情况下，我们可以人为地以优雅的方式延迟任务的执行。我最喜欢的一个例子是一个名为 Glovo 的应用程序，它是一个食品配送应用程序，它在送餐应用的工作流程中使用了进度错觉。让我们看一下在订购商品时会看到的三个屏幕截图。
第一个屏幕是一个购物车，里面有用户选择购买的商品（还有一个烦人的订阅促销活动，占据了屏幕的 1/3）
点击 “确认订单” 按钮后，您将看到第二个屏幕，询问用户是否一切正确。但是，信息会随着淡入动画逐渐显示。此外，您还可以看到有一个进度条，这是一个假的。
几秒钟后，您将看到另一个屏幕，显示该应用程序正在尝试为您的卡充值；这一次，这是一个真实的过程。交易完成后，您将看到订单状态和大致送达时间。
专业提示：当用户显示订单状态并直观地突出显示或动画化第一步时，它会使用户更有信心订单将完成。这里使用了一个叫做 「目标梯度假说」 的技巧。
用户刚刚付款，“有些事情开始发生”（至少在视觉上），这是一个信号 “哦，他们应该已经开始准备我的订单了。太好了！
在人为延迟之后，则开始真实购买行为：
带有虚假进度条页面的目的是让用户验证订单详细信息并确认它们。但这是以一种非常精妙的方式完成的：
在该应用程序的早期版本中，用户甚至无法跳过该过程；你只能取消它。现在他们添加了 “Continue” 按钮，这基本上是 “Yes， I'm sure” 确认。
经典确认模式的缺点是，用户可以跳过该过程。但这里的方法不同：它是来自应用程序的反馈循环和跳过该过程的组合。
这种组合使用户至少有时会关注地址、订单和价格，并让他们有时间取消订单，而在经典方法中，确认是 “yes or no？”，这更有可能立即得到确认。
撤消
撤消模式允许用户撤消他们刚刚执行的操作，从而提供一个安全网，减少对犯错的焦虑。与中断工作流以请求用户确认的确认模式不同，撤消模式通过允许完成操作并在需要时选择撤消操作，从而提供更流畅的体验。
何时使用撤消模式
它非常适合非破坏性、可逆的 action 和 mdashl action ，这些操作不会产生重大和直接的后果：
与计时器一起使用，可以让撤消适用于更多的场景，因为发送电子邮件或进行汇款等任务可以撤消。
何时不能使用撤消
它不适用于具有严重后果的操作，例如：
删除帐户；
提交法律文件；
购买商品（退款与撤消选项不同）;
请求第三方 API（在大多数情况下）。
如何实现撤消
大多数人每天使用的最常见方式是提供快捷方式 （ctrl + z）。但是，它仅限于某些情况，例如文本编辑器、在文件夹之间移动文件等。
Toast 可能是实现这些 Web 和移动应用程序的最常用方法。唯一应该记住的是，它应该足够突出以引起注意。将它们隐藏在角落里，并带有不明显的微小信息和颜色可能不起作用，尤其是在宽屏幕上。
一个简单的解决方案是简单地有一个执行撤消选项的按钮。最好靠近唤起您要撤消的操作的按钮。
undo 选项与软删除的概念密切相关，软删除在 Laravel 等后端框架中被广泛使用。这个概念意味着，当用户通过 UI 删除某些内容时，它看起来似乎已被删除，但在数据库中，我们保留了数据，但将其标记为已删除。数据不会丢失，这就是为什么可以使用撤消选项的原因，因为我们实际上并没有删除任何内容，而是将其标记为已删除。
这是确保数据永远不会丢失的好方法。但是，并非每个场景都需要这个。例如，如果您删除了一个帐户并且不希望用户恢复它（可能是由于法律规定），那么您应该完全擦除数据。但在许多情况下，考虑软删除可能是一个好主意。在最坏的情况下，如果由于某种原因无法通过 UI 手动恢复用户数据，您将能够手动恢复用户数据。
结论
每种场景都是独特的，本文提到的这些方法可能因各种原因有效或失败。用户行为受很多因素影响，关键是要控制好数据和用户，在出现问题时能及时响应。遵循最佳实践很重要，但必须验证其在特定情况下是否适用，就像国际象棋有很多规则也有更多例外。
关于本文
译者：@ikoofe
译文：https://mp.weixin.qq.com/s/_0U4X0oIrBIU_zzEofD3zA
作者：@Victor
原文：https://www.smashingmagazine.com/2024/09/how-manage-dangerous-actions-user-interfaces/
这期前端早读课
对你有帮助，帮” 赞 “一下，
期待下一期，帮” 在看” 一下 。
