エラーメッセージガイドライン

よいエラーメッセージとは、礼儀正しく、正確で、建設的なものであることは、すでに広く知られている。ウェブでは、これに加えて若干の新しいガイドラインが必要となる。すなわち、エラーメッセージをはっきり見やすくしておくこと、問題の解決に必要な手間を減らすこと、さらに、その過程でユーザを教育すること。

  • by Jakob Nielsen
  • on June 24, 2001

効果的なエラーメッセージのガイドラインは、ここ20年間まったく変わっていない。よいエラーメッセージとは、以下のような条件を満たすものだ。

  • はっきりと異常の発生を表示すること。最悪のエラーメッセージとは、エラーメッセージの不在である。ユーザがミスをしても、フィードバックがなければ路頭に迷うだけだ。例えば、電子メールには、はっきりした表示を出した方が有益と思われる状況がいくつかある。メッセージを送信したのに、システムに吸い込まれてしまって、受取人には絶対に届かない場合。あるいは、電子メールの本文に添付ファイルがあると書いておきながら、添付するのを忘れている場合。こういうときこそ、まさにペーパークリップ [訳注:Microsoft Officeに搭載されたガイド役キャラクタ「Office アシスタント」のひとつ] の出番だ。「このメッセージにはファイルを添付するつもりだったのではありませんか?でも、添付ファイルはありません。今、添付しますか?」
  • 人間が読んでわかる言葉で書いてあること。意味不明なコードや略語、例えば「タイプ2のエラーが起きました」といったものではいけない。
  • 礼儀正しい言葉づかいであること。ユーザを責めたり、馬鹿にしたり、ヘマをやったなどというニュアンスを感じさせてはならない。「不正なコマンドです」などというのがこれにあたる。
  • 正確に問題点を記述すること。「文法エラー」などという、一般的であいまいな表現は避ける。
  • 建設的なアドバイスで問題の解決に資するものであること。例えば、単に「在庫切れ」と言うのではなく、いつごろ入手可能になるのかがわかるようなエラーメッセージにしておくべきだ。製品在庫ができたらユーザに通知するという仕組みを用意しておくのも一法だ。

ウェブでもっとも多いエラーメッセージ、404は、これらガイドラインのほとんどに違反している。サーバに組み込まれている「page not found」メッセージに頼るのではなく、専用の404エラーメッセージを作成しておくことをお薦めする。

新ガイドライン

ウェブページは複雑なので、従来は必要のなかった新たなガイドラインが求められるようになった。DOSのインターフェイスでは、ユーザがコマンドを入力すれば、エラーメッセージはTTYの次の行に表示された。現代のGUIでは、ユーザがコマンドをクリックすると、エラーメッセージは、画面中央の大きなダイアログボックスに表示され、ユーザがOKを出さないかぎり画面から消えない。しかしながら、ウェブでは、エラーメッセージはごちゃごちゃしたページ内のテキストの中に埋もれていることが多い。そこで、新たなガイドラインが必要になる。エラーメッセージには、以下の条件が求められる。

  • 視認性が高く、すぐに気が付くようになっていること。メッセージそのものもそうだが、ユーザが修正しなければならないのが、どのダイアログ要素かがわかりやすくなっていること。

ウェブのフォームでミスをするユーザをたくさん観察してきたが、サーバから返ってくるフォームはまったく同じもので、どこが悪いのか見てわかるようにはなっていない。ページ上部に小さなエラーメッセージがあるだけ、ということが多かった。ユーザは何らかの行動を起こせる部分(すなわち、フォームのフィールドがある部分)に目を向けるので、普通、エラーに気付かない。

これと関連するデザインミスに、エラー状態を表示するのに、フィールドのラベルを赤くすることだけで対処しようとするものがある。これは、障碍を持つユーザにもテクノロジーをアクセシブルにするための法則、その中でももっとも古く、もっとも単純な法則に反するものだ。すなわち、色覚障碍のあるユーザにもわかるように、同様の指示を別の形で入れておくこと。

以下の2つのガイドラインで、エラー状況にともなうユーザの不快感を和らげることができるだろう。

  • ユーザの成果をできるだけ保存すること。すべてを一からやり直させるのではなく、もともとのアクションに手を加えてエラーを修正できるようにしておく。例えば、検索結果を表示する際に、あわせて、ユーザが入力した検索条件の入った検索窓も表示しておけば、簡単に修正ができる。検索結果がゼロなら、ワンクリックで検索対象を広げられるようにしておこう。
  • エラー修正の手間を減らす。可能なら、正しいアクションを推測し、修正案をいくつか示したリストから選択できるようにしておく。例えば、「都市名と郵便番号が合致しません」というだけでなく、ユーザが入力した郵便番号に該当する都市名のボタンをクリックできるようにしておく。

ユーザ教育の機会

最後に、すでにご承知であろうが、コンピュータ文書に関するNielsenの第1法則をご紹介しておく。すなわち、誰も読まない、である。この知見は、ウェブサイトではますます重みを増している。ユーザは、自分のタスクに不可欠な文章以外は、本当に読まないのだ。ヘルプをクリック?そんなこと、絶対にありえない。

ユーザがシステム文書を読むのは、何かトラブルがあったときに限られる(これが第2法則だ)。エラーから抜け出ようとするときは、特に気持ちが集中している。このため、エラーメッセージは、少量の知識を伝達するための教育用資源として利用できる。もちろん、エラーメッセージは、あらゆるウェブコンテンツと同様、簡潔にして要を得たものでなくてはならない。だが、エラーメッセージを通じて、システムの仕組みとか、うまい使い方といったものについてユーザを少し教育することはできる。この目的をさらに追求する上で、ウェブの基盤テクノロジーを利用した次のガイドラインが生まれる。

  • ハイパーテキストリンクを利用して、簡潔なエラーメッセージを、背景知識のページや問題点の解説ページに結び付けておくこと。(だが、やりすぎは禁物だ)。

2001年6月24日