UX探訪記

UIデザインやUXデザインに関する記事を集めたり書いたりしています。

トップ > UI > ハワイのミサイル誤報について考えてみる

ハワイのミサイル誤報について考えてみる

UI UX

先日も記事紹介で少し触れましたが、1/13に発生したハワイのミサイル誤報がイマイチなUIに起因するものということで、たくさんの記事が出ていました。
今回はそれを少しまとめてみたいと思います。

状況

この問題について詳細は私が記載するより以下の記事を見ていただくのが早いと思います。

で、イマイチなUIと言われているのがこの画像です。
（画像は Honolulu Civil Beat のサイトより拝借しています。） f:id:junichiirokawa:20180201010829j:plain f:id:junichiirokawa:20180201010811j:plain

2パターン出回っていて、どちらも本当の画面でない（カスタマイズして使っている）とのことですが、2つ目のほうが実際に近いという話です。
確かに1つ目のほうは、90年代の香りがします。
2つ目のほうは、これもモックアップっぽいですが、ドロップダウンで選択されるUIになっています。

今回の原因について、当局は担当者の誤認識が原因、と言っていますが、おいおい本当かよ、と言いたくなるくらいイマイチなUIです。
ユーザビリティにフォーカスすると、以下の点が考えられると思います。

  • 文言の問題
  • 表現の問題
  • UIコントロールの問題（主にドロップダウンメニュー）
  • フィードバックの問題

文言の問題

UI上の文言がどれが本番でどれがテストかわかりにくい、という問題です。
英語だからというわけでもなく、日本語でも双方の区別はつきにくいと思います。
これではとっさのときにテストメッセージとして送信してしまう恐れもあるわけです。

表現の問題

したがって、文言をもっとわかりやすくすればいい、という解決策も考えられますが、そもそも両方が同じ露出度で並んでいることがそもそもの問題ともいえます。
私たちが普段エレベーターの「開」と「閉」を間違えてしまうのに似ています。
この場合、本番の選択肢の色を変えたり、場所を変えたりするなど、きちんと表現の重みづけをすべきだと思います。

UIコントロールの問題

2つ目の画像のUIコントロールはドロップダウンメニューになっていますが、こういった重要度の異なる選択肢を一緒に入れるのは避ける必要がありそうです。
というのも、Aを選択しようとしてそのすぐ下のBを選択してしまう、というように選択肢を間違えるケースがあるためです。
これはスリップと呼ばれています。
詳しく知りたい人は以下をご参照ください。

また、選択した項目が合っていたとしても、そのあとマウスホイールを動かして画面をスクロールしようとしたときにドロップダウンメニューにフォーカスが残っていて、別の選択肢に切り替わってしまうという問題もあります。
こちらはアニメーションでそれを再現した記事がありました。

フィードバックの問題

情報では、画面上に本番のアラートであることを示す確認メッセージが表示されたものの、担当者にはスルーされたという話がありました。
実際のところ、普段確認メッセージに慣れっこになっていて、あまり読んでいない人は多いのではないでしょうか。
CBCラジオのサイトでは、以下のように確認メッセージをわかりやすくする案が示されていました。

これも解の一つだと思いますが、テストメッセージ送信には確認メッセージを出さない（そもそも送信UIを開いている時点でアクションを取ろうというモチベーションがあるわけで、クリティカルでないものは確認するまでもない）という方法も考えられます。
フィードバックはフィードバックとしてきちんと機能するように考慮する必要がありそうです。

それ以外の問題

UI上の問題ではない、それ以外の問題を提示している記事もありました。 http://www.uxbooth.com/articles/three-takeaways-from-the-hawaii-missile-false-alarm/

こちらはUIの問題ではなく、ヒューマンエラーの問題でもなく、プロセスの問題だといっています。
システム導入の意思決定者と実利用者の意思疎通や、全体の予算のために見落とされる部分などについてフォーカスしています。
ただ、その文脈であれば、プロセスというより体制の問題といったほうがしっくり来ますね。
この場合、システム検討時にUXやUIの知見を持った人が関わっていなかったから起こった、ということが言えると思います。

改善案について

以上の話の中で、解決策についてもいくつかアイデアを入れてみましたが、それ以外にも多くの記事で解決策について述べられています。
大方が確認メッセージをリッチにする報告になっていたのですが、ひとつ良い解決策を示していた記事がありました。

こちらの案は、先にテストか本番かを聞くパターン。
つまり、一回で選択されるわけではなく、タスクを分けるということです。
見た目がウィザード (今風にいうとステッパー) になっていますが、これらは1ステップで1タスクが基本なので、より親和性が高いように思います。
緊急時にウィザードで指示がもたもた、という場面も出てきそうですが、まぁそこまで遅くならないでしょうし、ヒューマンエラーは格段に減ると思います。

避難訓練

ということで、ハワイの人たちは大変だったと思いますが、あえて良い意味でとらえれば、避難訓練の練習にはなったのでは、と思います。 テストメッセージ送信では、必死に避難することもなかったでしょうし、今回避難してみてわかった課題もあったようです。
それらが明るみに出たという意味では、有益だったのかもしれません。

気を付ける必要があるのは、狼少年みたいに、来る来るといっていつも何も起こらないのに慣れっこになってしまうことです。
ちょうど、今回の画面で確認メッセージに対して慣れっこになってしまい、意味をなさなかったようにならないよう、送信エラーも再発防止していけるといいですね。