ユーザーにエラーメッセージを読ませるにはどうすればよいですか？
対象読者が技術者でない場合、ユーザーは注意深く書かれたエラーメッセージを無視するという重大なリスクに直面します。つまり、彼らにショックを注視したり、サポートスタッフに電話したり叫んだり、単に無視したり閉じたりします。
エラーメッセージを破棄するのではなく、実際にユーザーに読んでもらうための推奨事項を教えてください。今、私は次のようないくつかの基本を知っています：
- 詳細な説明へのリンクまたはボタンを含む、短い正確な表現。
- エラーを修正する方法の例を提供します（例：「サーバーに接続できません。インターネット接続を確認してください。」）。
本 Face 3について はいくつかの良いアドバイスを持っています。その最優先事項はエラーダイアログの必要性を排除するようにソフトウェアを設計するです。それが不可能な場合、著者は以下を推奨します。
- エラーダイアログを礼儀正しく、わかりやすく、役立つものにします。 （エラーメッセージは、実際には、ユーザーが有効なデータを入力できないなどではなく、実行できないことを報告するソフトウェアであることを思い出してください）
- 問題を明らかにし、ユーザーがプログラムの問題を解決するための計画を立てるために必要な関連情報を提供する
- 提案されたソリューションを少なくとも1つ実装することを申し出てください（私の見解：Windowsでは、組み込み Windowsトラブルシューティングプラットフォーム を利用しますが、実装は厄介ですが:)）
断然、最大の注意点は、エラーメッセージを完全に回避するために非常に懸命に取り組むことです。それが元に戻す機能の実装によるものか、エラー条件が発生したときの代替のUIまたは入力の提供によるものか、それ以外の何かによるものか。
多くのまたはすべてのエラーメッセージを無視するユーザーのかなりの割合が常に存在します。彼らがサポートに連絡し、その前にエラーメッセージを表示し、それを読んだと主張する場合でも、メッセージの内容を理解していない可能性があります。したがって、エラーダイアログを表示する必要がないように、一生懸命努力する必要があります。
フェイス3について（Aaron Lerchの回答を参照）で提供されるアドバイスに加えて、すべてのメッセージを後で検査できるようにログに記録することをお勧めします。エラーメッセージの内容や、ダイアログボックスを閉じるために押したボタンをユーザーが知っているとは限りません。
ユーザーが技術者でない場合は、次の2つの方法のいずれかをお勧めします。
誰かと話すための連絡先情報のみを提供します。基本的に、彼らが問題を解決しようとする機会さえも取り除きます。なぜなら、彼らが指示に従うのに十分なスキルがない場合は、たとえどれほど簡単にしても、それらを与えられても気にしないでください。 1から800のヘルプ番号またはクリック可能なメールなどを伝えます。
あなたが本当に彼らに指示を与えなければならないなら、彼らは非技術的である必要があります（あなたの母が非技術的であると仮定して、あなたの母によって書かれました）。 「サーバーに接続できません。インターネット接続を確認してください」という例でも、カジュアルなホームユーザーには技術的すぎるかもしれません。インターネット接続を確認するにはどうすればよいですか？私のインターネット接続とは何ですか？これらはコンピュータを「マシン」と呼び、モニターを「テレビ」と呼ぶ人々です。写真を見せたり、簡単な言葉で説明したりします。コンピュータについて何も知らない人に、この方法を使用する場合は、サンプルドキュメントまたは提示する予定のエラー情報を提示して、理解しているかどうかを確認するのが最善です。それ（私はこれを義母のテストと呼んでいます、彼女がそれを理解できれば、誰でもできます）。
心に留めておくべき重要なメッセージを他の人に読んでもらうには、まずアプリケーションを検索して、「管理者に連絡してください（実際には存在しない）！」それらを削除するか、正直な情報で置き換えます。ノイズがメッセージストリームから削除されると、ノイズ対メッセージの比率が改善されてメッセージを再度読み取ることができるようになるまでユーザーベースが気付くまでに数か月かかります。
場所、場所、場所！
エラーメッセージが、ワークフローの妨げにはならないが、簡単に気付く場所にあることを確認してください。
メッセージが画面の中央にあり、メインフォームへのアクセスをブロックしている場合、ユーザーはおそらくそれを読まずにすぐに閉じます。
（ここで私が言わなければならないことのいくつかは、投稿する前に他の人から回答されたようです-上記のいくつかの良い情報、特にレルチ氏）
残念ながら簡単な答えは「彼らはしない」だと思います。ユーザーが製品マニュアルを所有しているが開封を拒否する現象と同様に、突然、意外で、コンテキスト外のメッセージ（少なくとも、基本ユーザーにとって）は、突然、意外で、コンテキスト外のメッセージになります。 。
私の悲観主義はさておき、あなたの提案の精神で逸話的な成功を収めました。 WRTの最初のポイント、私は「短い」には同意しますが、「正確」には同意しません。技術者以外のユーザーは、エラーメッセージで問題が発生します。技術者ではないユーザーが必要な情報は少ないのではなく、実際に何が起こったのかを理解するために多くの（つまり、少しの教育が必要）ため、「正確な」メッセージはさらに正確になります。
例として、2番目の箇条書きで、技術者以外のユーザーがサンプルメッセージの最初の部分で問題を抱えることになります。
- それは何に接続していますか？
- どのサーバー？
- なぜそれができないのですか？
- 私は何か間違ったことをしましたか？
- ソフトウェアは何か間違ったことをしましたか？
これらの質問の一部またはすべては、提案された回答を実際に理解する前に頭を駆け巡ります。彼らが落ち着きを取り戻し、第2部を読むとき、彼らはインターネット接続を確認する方法について別のたくさんの質問をするでしょう。モデムまたはルーターの問題として解釈し、スタック全体の電源を入れ直す（冗談ではない）人もいます。
これの多くは、エラーメッセージでは実際には解決できません。人々にはある程度のコンピュータリテラシーがあり、アプリケーションはおそらくそれに対して大きな影響を与えません。しかし、もしそうなら
- 最初に、メッセージが表示される理由を説明できる簡単な文を提供します。 5〜7語。
- 簡単な会話型言語を使用して、もう少し詳しく説明します。
- （サイトの責任である場合）謝罪を提供する
- パニックにならないように伝えるための賢い方法を見つける
- それらが物事が良くなることを確認してください
あなたは経験をもう少し楽しいものにするかもしれません。
最後のいくつかは間違えやすく、最終的にはひいきに聞こえることに注意してください。最初は注意して、何人かの友人に対してテストしてください。
関連性があり、簡潔でわかりやすい英語にし、ユーザーが見ている場所からそれほど遠くない場所に配置します。何が起こったのか、なぜ起こったのかを説明します。最後に、アプリケーションだけでなく他の部分のエラー状態をテストまたはプロトタイプ化します。すべてのエラー処理を組み込む前に、ユーザーが忘れてプロセスをウォークスルーすることがよくあります。これにより、エクスペリエンスの重要な、場合によっては苛立たしい部分の検証が省略されます。
視覚的には、インターフェイスの他の要素から目立つようにします。アニメーションは意識を高めるのに役立ちます。 イエローフェードテクニック はその良い例です。
最高のアドバイスの多くはすでに提出されています。エラーメッセージングは、残りのインターフェイスコンテンツのトーンと一致している必要があることを追加します。 http://www.visual-ii.com/ は、非常に会話的で少しオタクな雰囲気で、ホームページのバナーに「Uncomplexification」と表示されており、少しオタクな404エラーページを作成しています。ベース： http://www.visual-ii.com/404 。
まれですが、アプリケーションの実行時に致命的な未処理の例外タイプのエラーの場合、3つのボタンがあるエラーダイアログが表示されます。
- 'クリップボードにコピー'。これにより、エラーの詳細がテキストとしてクリップボードにコピーされます。ユーザーがこれを使用して、テクニカルサポートに電子メールを送信するか、メモ帳に貼り付けることが想定されています。
- 'エラーレポートを送信する'。エラーの詳細をテクニカルサポートに電子メールで送信します。これがデフォルトのボタンです。
- '閉じる'。ダイアログを閉じます。このボタンは、10秒間、またはユーザーが上記のアクションのいずれかをクリックするまで、意図的に無効にされています。カウントダウンはボタンのラベルに表示されます。
安全対策として、ユーザーがアクションを実行しなかった場合に備えて、エラーメッセージをローカルのテキストファイルに記録します。このアクションは、後でテクニカルサポートが検査できます。
アプリケーションが問題を解決するのに役立つエラーメッセージを表示するとき、それらを読みました。アプリケーション（またはベンダー）が役に立たないエラーメッセージを持つという評判がある場合、私はそれらを読むのをやめました。
エラーメッセージのように見えないようにします。
アラートなど、ボタンで閉じる必要があるものは使用しないでください。その目的のために予約された静的スペースでのエラーの表示（webapps、CMS管理パネルなどを参照）
シンプルで面白い言葉を使う。
「internal server error 500」の代わりに「Oops。その入力を予期していなかったようです。戻って、フォームに異常があるかどうか確認してください。」
「デバイスの初期化中にエラーが発生しました」の代わりに、「[GPRSモデムなどの[デバイス]を使用できませんでした。問題はありませんか？それを確認して、設定内容を確認してください。」
エラーメッセージに注意を向けるアニメーションの縮小ライトボックス効果を、表示の関連部分とともに使用します。ボタンの代わりに「ここをクリックしてエラーメッセージを削除するにはここをクリックしてください」というテキストを使用します。
彼らがあなたにエラーに関するデータを送って欲しいなら、彼らの入力があっても、そう言います。 「必要」という言葉を使用します。 「ここに、必要なこのエラーに関するデータがあります。一部は個人的に参照する場合があります。-->ここ<-をクリックして、エラーを送信してください。」
多くの非技術的なエンドユーザーが問題を自分で解決しようとするのではなく、彼らの隣にいる誰か、または技術サポートに助けを求めることを示す多くの研究があります。それは人間の本質であり、私はそうではありません。しかし、エラーメッセージは、技術者ではないユーザーの間で評判が良くありません。
上記のポイントに加えて、エラーメッセージが次のことを確認してください。
- はっきりと見える。重要である場合、ユーザーはアプリケーションとの対話を再開する前にメッセージと対話する必要があります。
- 技術的な言葉ではない、フレンドリーでカジュアルな口調で書かれています。例：Firefoxのメッセージを確認してください。
- 問題の簡潔で明確な説明と、それが発生した理由を説明してください。
- 問題を修正するための明確な指示と、開始場所へのリンク（可能な場合）を提供します。
- 避けられない。効果的なエラーメッセージを書き込もうとするよりも、ユーザーエラーの発生を防ぐ方が優れています。
エラーアラートを表示する最も効果的な方法の1つは、次のとおりです。
- ユーザーが操作して修正を実行できる要素の横にエラーノートを配置します。
- ページをスクロールして、要素とエラーのメモに焦点を当てます
- 短いアニメーション（エラーノートボックスの動き）を提供して、ページが既に問題領域の中央にある場合にユーザーの注意を引きます（たとえば、短いフォーム）。
これにより、ユーザーは修正可能なアクションに対して、有益で脅迫的ではないがしつこい方法で方向付けられます。