2018年1月13日，周六，夏威夷群岛的居民和游客在他们的移动设备上收到了非常可怕的紧急警报。夏威夷紧急警报指挥中心发出的警报是“弹道导弹威胁进入夏威夷”。立即寻求庇护。这不是演习。”
值得庆幸的是，这实际上是一场演习:并没有导弹飞向这些岛屿。然而，这条信息无意中被实时发送到岛上的手机上，而不是发送到它原本计划的测试网络上。自从这一事件发生以来，关于造成这一错误警报的操作员的新闻报道铺天盖地。许多头条新闻都集中在人为错误上，有些甚至要求追究责任人的责任:
- 夏威夷导弹警报:一名员工“按错了按钮”，引发了一波恐慌- 华盛顿邮报
- “错误的按钮”向夏威夷发送了错误的导弹警报——每日野兽
- 夏威夷“不可原谅”的假弹道导弹警报是由人为错误造成的- - - - - - TechCrunch
显然，这个人犯了两次错误:
- 通过选择错误的选择（真正的警报而不是测试）
- 通过确认前面的选择
我不喜欢这个故事的这个角度。当我听到这个不幸的消息时，我的第一个问题是:“界面出了什么问题，导致操作人员无意中做出了错误的选择?”
卡瓦和错误预防
我认为我们都可以通过意外推动错误的按钮。推动后我在商店结账和气泵取消了交易不而不是是的．我无意中选择了网站上的附加服务接受而不是衰退．幸运的是，这些错误都没有让整个国家陷入恐慌，但它们都是例子滑倒．
滑倒当用户想要执行一个动作但无意中拍摄另一个（通常是相似的）动作时发生。他们经常发生在用户在自动驾驶仪上的情况下，并且不会将注意力资源完全投入到手头的任务。意外地将液体手肥皂放在一个人的牙刷上而不是牙膏是一种无意识的滑动。但是当两个选择看起来太相似或者彼此太紧密地放置时，也会发生滑倒。
通常情况下，当你停止评估出现错误的界面设计时，就会发现存在潜在的UI问题。
有一些常见的系统设计问题会导致无意识的失误:
- 误入歧途:当设计给用户错误的提示时——例如，违反设计惯例
- 低分化选择:当接口提供多种选择时，它使用类似的名称或类似的视觉样式
- 有问题的演示文稿或互动设计：当布局，演示文稿或工作流不包括适当的保障 - 例如，通过将两个按钮彼此贴近
- 对破坏性行为缺乏确认:当设计不要求用户时用重大后果确认行动
所有这些问题都说明了错误预防的不足。错误预防是Jakob Nielsen的研究之一用户界面设计的10个启发式;对于像夏威夷紧急警报系统或医院系统这样的关键系统尤为重要，在那里推动错误按钮可能是生死之间的区别。
在错误的导弹警报的情况下，一些新闻媒体提供了有关界面的例子。同一系统屏幕用于向公众发送几种不同类型的紧急警报，包括琥珀警报、道路封闭和高浪警报。有9个独特的选项，既包括面向公众的实时警报，也包括用于测试和故障排除的警报演练版本。(后来又增加了第10个选项，发送一条“这是假警报”的撤销信息，以防今后再发生错误。)
这一事故涉及的两种选择如下:
- PACOM（CDW） - 仅限状态：操作员错误地选择的选项
- DRILL- PACOM (CDW) - STATE ONLY:操作员应该选择的选项
操作员应该选择仅选择第二个选项钻孔（CDW） - 状态，而是选择另一个。
接口设计问题
这个导弹警报UI包括几个设计问题:
- 低分化选项：页面上列出的选项具有隐秘标签，需要太多的心理努力来区分。此外，这些标签中的一些（例如，与此事件相关的两个标签）是相当相似的。这些选项不能用更简单的选择替换，如下所示？
- 测试警报:“太平洋司令部”
- 生活提醒:“太平洋司令部”
有人可能会说，在一个包含许多不同类型的警报并没有按特定顺序列出的屏幕上，这些标签的描述性不够。为什么不以一种有意义的方式对它们进行分组——例如，把所有的琥珀警报放在一个标题下，以区分它们呢?
- 有问题的表现或交互设计：也许问题的根源完全来到这个屏幕之前。我们是否真的拥有在同一环境中呈现的实时与测试选项，并在同一屏幕上用于这样的关键系统？通过这种设计，如所示，手指的滑动可能会导致一个主要问题。为什么没有两个单独的工作流或模式？一用于测试工作的模式，它应该是默认值，另一个用于实时系统命令，其中必须采取显式操作来输入和提交命令。在我作为开发人员的日子里，我们有这样的结构性保障措施，活动环境与测试环境完全分离，并且在视觉上完全不同。
- 可能是糟糕的确认屏幕请看《中国日报》的报道:新闻报道指出，在操作员选择了错误的网络后，她会看到一个确认屏幕——这表明系统的设计者可能试图创建一些防止意外行为的防护措施。但是屏幕是什么样的呢?通常情况下，当人们一天去类似的确认屏幕10次，或者当每个操作都有一个确认屏幕时，他们就不再关注这些对话框了——这些对话框就像是他们流程中的路障。
有助于一个更具侵入性的现场警报的确认是否有帮助？也许它可能需要用户重新输入他们的密码 - 不要为入侵者添加安全性，但要使用户清楚，他们即将与严重后果做出不寻常的事情。许多银行在发起不可逆转的行动之前使用这种侵入性确认步骤，例如电汇。
缺乏撤消能力
夏威夷警告系统违反的另一个应用程序设计启发式是撤销错误命令的能力。消息的发送不能完全撤消，这就是为什么在系统开始发送之前需要执行确认步骤的原因。但至少可以发出第二条信息，说明第一次警报是错误的。这确实做到了，但只是在延迟了38分钟之后。
据新闻媒体报道，延迟是由不同级别政府之间的官僚分歧造成的，因为发出(错误)警报的夏威夷州机构没有授权发送除警报以外的任何东西。该机构必须获得额外级别的批准，才能发出第二种不同类型的信息。然而，任何被授权采取某项行动的人，如果该行动被证明是错误的，也应该被授权撤销该行动。除了这个官僚问题之外，系统不支持发送消息来撤销先前的警报，而且这种功能必须由非现场开发人员在系统中实时创建。
将制作错误，所以计划他们。（当然，可能不会发生完全相同的错误，但其他错误将会发生。这就是为什么系统需要旨在减轻错误的原因。）
结论
人为错误归咎于并且用户在选择错误选项时出现故障是错误的。共一个设计不良的系统是罪魁祸首．一个好的UI可以让人们避免犯错，并且更容易从任何剩余的错误中恢复过来。
解决方案不是责骂用户，要求他们努力尝试，或者给他们更广泛的培训。答案是重新设计系统以易于出错。
让我们庆幸我们现在发现了这个设计问题。想象一下，如果存在真正的威胁，用户意外地将消息发送到测试网络而不是实时网络。
分享此文章：