市場調査ホームニールセン博士のAlertboxエラーメッセージガイドラインよいエラーメッセージとは、礼儀正しく、正確で、建設的なものであることは、すでに広く知られている。ウェブでは、これに加えて若干の新しいガイドラインが必要となる。エラーメッセージをはっきり見やすくしておくこと、問題の解決に必要な手間を減らすこと、さらに、その過程でユーザを教育すること。2001効果的なエラーメッセージのガイドラインは、ここ20年間まったく変わっていない。よいエラーメッセージとは、以下のような条件を満たすものだ。異常の発生を表示すること。最悪のエラーメッセージとは、エラーメッセージの不在である。ユーザがミスをしても、フィードバックがなければ路頭に迷うだけだ。電子メールには、はっきりした表示を出した方が有益と思われる状況がいくつかある。メッセージを送信したのに、システムに吸い込まれてしまって、受取人には絶対に届かない場合。電子メールの本文に添付ファイルがあると書いておきながら、添付するのを忘れている場合。「このメッセージにはファイルを添付するつもりだったのではありませんか?でも、添付ファイルはありません。人間が読んでわかる言葉で書いてあること。意味不明なコードや略語、例えば「タイプ2のエラーが起きました」といったものではいけない。礼儀正しい言葉づかいであること。ユーザを責めたり、馬鹿にしたり、ヘマをやったなどというニュアンスを感じさせてはならない。「不正なコマンドです」などというのがこれにあたる。正確に問題点を記述すること。「文法エラー」などという、一般的であいまいな表現は避ける。建設的なアドバイスで問題の解決に資するものであること。「在庫切れ」と言うのではなく、いつごろ入手可能になるのかがわかるようなエラーメッセージにしておくべきだ。製品在庫ができたらユーザに通知するという仕組みを用意しておくのも一法だ。ウェブでもっとも多いエラーメッセージ、404は、これらガイドラインのほとんどに違反している。found」メッセージに頼るのではなく、専用の404エラーメッセージを作成しておくことをお薦めする。新ガイドラインウェブページは複雑なので、従来は必要のなかった新たなガイドラインが求められるようになった。DOSのインターフェイスでは、ユーザがコマンドを入力すれば、エラーメッセージはTTYの次の行に表示された。現代のGUIでは、ユーザがコマンドをクリックすると、エラーメッセージは、画面中央の大きなダイアログボックスに表示され、ユーザがOKを出さないかぎり画面から消えない。ウェブでは、エラーメッセージはごちゃごちゃしたページ内のテキストの中に埋もれていることが多い。そこで、新たなガイドラインが必要になる。エラーメッセージには、以下の条件が求められる。視認性が高く、すぐに気が付くようになっていること。メッセージそのものもそうだが、ユーザが修正しなければならないのが、どのダイアログ要素かがわかりやすくなっていること。ウェブのフォームでミスをするユーザをたくさん観察してきたが、サーバから返ってくるフォームはまったく同じもので、どこが悪いのか見てわかるようにはなっていない。ページ上部に小さなエラーメッセージがあるだけ、ということが多かった。ユーザは何らかの行動を起こせる部分(すなわち、フォームのフィールドがある部分)に目を向けるので、普通、エラーに気付かない。これと関連するデザインミスに、エラー状態を表示するのに、フィールドのラベルを赤くすることだけで対処しようとするものがある。これは、障碍を持つユーザにもテクノロジーをアクセシブルにするための法則、その中でももっとも古く、もっとも単純な法則に反するものだ。色覚障碍のあるユーザにもわかるように、同様の指示を別の形で入れておくこと。以下の2つのガイドラインで、エラー状況にともなうユーザの不快感を和らげることができるだろう。ユーザの成果をできるだけ保存すること。すべてを一からやり直させるのではなく、もともとのアクションに手を加えてエラーを修正できるようにしておく。検索結果を表示する際に、あわせて、ユーザが入力した検索条件の入った検索窓も表示しておけば、簡単に修正ができる。検索結果がゼロなら、ワンクリックで検索対象を広げられるようにしておこう。エラー修正の手間を減らす。可能なら、正しいアクションを推測し、修正案をいくつか示したリストから選択できるようにしておく。「都市名と郵便番号が合致しません」というだけでなく、ユーザが入力した郵便番号に該当する都市名のボタンをクリックできるようにしておく。最後に、すでにご承知であろうが、コンピュータ文書に関するNielsenの第1法則をご紹介しておく。誰も読まない、である。この知見は、ウェブサイトではますます重みを増している。ユーザは、自分のタスクに不可欠な文章以外は、本当に読まないのだ。ヘルプをクリック?そんなこと、絶対にありえない。ユーザがシステム文書を読むのは、何かトラブルがあったときに限られる(これが第2法則だ)。エラーから抜け出ようとするときは、特に気持ちが集中している。このため、エラーメッセージは、少量の知識を伝達するための教育用資源として利用できる。エラーメッセージは、あらゆるウェブコンテンツと同様、簡潔にして要を得たものでなくてはならない。エラーメッセージを通じて、システムの仕組みとか、うまい使い方といったものについてユーザを少し教育することはできる。この目的をさらに追求する上で、ウェブの基盤テクノロジーを利用した次のガイドラインが生まれる。ハイパーテキストリンクを利用して、簡潔なエラーメッセージを、背景知識のページや問題点の解説ページに結び付けておくこと。(だが、やりすぎは禁物だ)。アプリケーションイードが提供する「ユーザビリティ評価」サービスイードは、スマートフォンアプリやサイトのUI品質をユーザー視点で評価・改善提案し、ユーザー側とビジネス側、双方の目的達成をサポートします。アプリケーションオンライン・フォームも2画面を超える分量になると、機能を滞りなく支援するには、よりインタラクティブなユーザ・エクスペリエンスを提供するアプリケーションに切り替えた方が良い場合が多くなる。コマンドリンクアプリケーションで用いるコマンド(命令)は、ボタンでもリンクでも表現できるようになってきたので、どちらが適しているかを決めるには、昔よりも多くの説明が必要とされる。重要なコマンドにはやはりボタンを用いるのが一番だ。Financeがある。AJAXの使い過ぎや改善の余地が残るカスタマイゼーションのページなどを見る限り、ユーザビリティはまだ上げられる。求められるスピード1994年以来、私が手がけてきたウェブユーザビリティ調査すべてに共通することがある。ユーザは、ページのダウンロードがもっと早くならないものかと心底から願っているのだ。