伝わらないメッセージに意味はない
正しくなんと呼べばいいのかわかりませんが，ここでは警告ダイアログとは，何か操作をしたときに表示される「この作業，本当に実行していいですか？」というダイアログのことと定義します。例えば，設定を変更したときに出す，「本当によろしいですか？」といったようなダイアログです（図1）。
図1：警告ダイアログの例
このダイアログは，JavaScriptを使えば簡単に出すことができます。例えば，以下のような感じになるでしょう。
<form action="/add" method="post" onSubmit=
"return confirm('データを保存します。よろしいですか？');">
:
:
<input type="submit"value="保存">
</form>
こうしたダイアログは簡単に表示できるため，利用者に注意を促すための手軽な方法として，よく利用されているのではないかと思います。今回はウェブサイトを使いやすくするために，こうしたダイアログをどう使えばいいのか，というか，そもそもこうしたダイアログって使いやすさに貢献しているのか，ということを考えていきたいと思います。
こうしたダイアログについて，使いやすさの観点から考えたときに，常に取り上げられるのは，そこに書かれているメッセージがわかりやすくなっているのか，という問題です。せっかくメッセージを表示しているのですから，それが利用者に伝わらなければ意味がありません。そのダイアログがなぜ表示されているのか，そしてそれに対してどう判断し，どう行動すればいいのか，それをきちんと利用者が理解できる必要があるのです。
まずはエンジニアが表示させる警告ダイアログにおいて，よく言われている問題点を見ていきましょう。
最初の問題点として，メッセージの意味がわからない，というものがあります。メッセージの中で，技術的な単語を使ってしまったり，そもそも何が言いたいのかよくわからない文章になっていたり，という問題です。例えば，「入力した情報でサーバーを書き換えます。よろしいですか？」とか「名まえは16バイトまでです」みたいな感じでしょうか。
いきなり「サーバー」とか「バイト」といわれても，コンピュータに詳しくない人にはよくわからないでしょう。こうした「専門用語」は，それを使うと文章を非常に簡潔に表現できて便利なので，油断するとついつい使ってしまいがちなんですよね。まずはここに気をつけたいです。
で，続いてはやはり文言の話で，警告の中に「なぜ警告を出しているか」は書いてあっても，「じゃあどうすればいいのか」とか「なぜそれが問題なのか」が書いてない警告ダイアログも問題です。利用者の側からすると，そのような警告を出されても困ってしまいます。
例えば「状態を変更します。よろしいですか？」というメッセージが出たとします。そもそも「状態を変更する」というメッセージにも問題がある気がしますが，それ以上に問題なのは，状態を変更するとどんなトラブルが発生しがちなのかを，はたして利用者はわかっているのか，ということです。もしわかっていないとしたら，よろしいかどうかなんて判断できません。
もしこのメッセージを出すのが何らかの情報をウェブ上で共有するかどうかを設定する際に出るのであれば，一言付け加えて，「状態を『公開』に変更します。このデータはほかのメンバーも閲覧可能になります。よろしいですか？」といった具合に，具体的にどういう状況で，どうなるのかを書いてあげたほうが親切ですよね。この場合，どういう風に設定が変更されるのかを調べてダイアログの内容を変化させたりする必要が出てくるので，処理はちょっと複雑になりますが，意味不明の警告を出すよりはずっとましです。
独りよがりなエラー・メッセージ
サービスを開発している人は，そのサービスのすべてを知っていたりするわけで，「『公開』に設定したらみんなに見えて当たり前じゃん」などと，意識していなくても心のどこかで思ってしまっていたりします。人間当たり前のことが書いてあると「くどい」と考えてしまいますから，ついつい自分にとってくどくないメッセージを書いてしまいがちなんですよね。利用者の気持ちになって考える，という考え方は，この連載では何度も書いていて，もはや常套句になっちゃっていて，またかという感じもしますが，ここでもその考え方が重要になってくると思っています。これは，処理がうまくいかなかったときのエラー・メッセージなんかにも共通に言えます。しかもエラーの処理って，プログラムをするのが結構面倒な部分でもあるので，手を抜いたメッセージになりがちです。例えば「処理に失敗しました」とかっていう，利用者からしてみれば何の手助けにもならないメッセージを出してしまったこと，ありませんか。
エンジニアをやっていると，「処理に失敗しました」だけが出ても，データベースの書き込みに失敗したのかな，とかAPIがうまくたたけなかったのかな，とかいろいろ想像できてしまうこともあります。自分で作ったサービスならなおさら，あそこの処理で失敗したのか，とわかることもあります。しかし，利用者にとっては，単なる謎のメッセージです。この場合も，せめてもう少し何が起こったのかをわかりやすく書いて，さらにそれを克服する方法もきちんと書いてあげたほうが使いやすくなるでしょう。
ちなみに，だめなエラー・メッセージの例がたくさん公開されている「Interface Hall of Shame」というサイトをご存じでしょうか。かなり古いサイト（最終更新日が2000年です）ではあり，紹介されているのも古いエラー・メッセージではありますが，だめな間違いを犯さないために，今でも参考になるサンプルがたくさん掲載されています。例えば，「このデータを削除していいですか？」という確認メッセージなのに「OK」しかないとか，「オブジェクトが見つかりません」という意味不明なエラー，中には「エラーはありませんでした」というエラー・メッセージなんていうものもあります。
そもそも警告ダイアログを出すべきか？
さて，警告ダイアログを出すうえで，もう一つ大きな問題があるので，後半はそれについて考えたいと思います。それは「ユーザーがダイアログの内容を読んでくれない問題」です。
