ユーザーにエラーメッセージを読ませるには？
技術者以外のユーザー向けにプログラムを作成すると、注意深く書かれた啓発的なエラーメッセージがユーザーに読まれず、いらいらしたばかりの最初のボタンをクリックするだけのリスクが高くなります。
そのため、ユーザーが単にエラーメッセージを放棄するのではなく、実際にエラーメッセージを読むのを支援するために推奨できる推奨事項を考えています。私が考えることができるアイデアは、次の線に沿って分類されます。
- もちろんヘルプのフォーマット。おそらく、より長く詳細なエラーメッセージにつながる「詳細」ボタンが付いた、単純で短いメッセージ
- すべてのエラーメッセージをユーザーガイドの一部にリンクさせる（やや難しい）
- エラーメッセージを発行しないでください。単に、タスクの実行を拒否してください（ユーザー入力を処理するための "Apple"の方法）
編集：私が考えているオーディエンスは、ソフトウェアをあまり頻繁に使用せず、拘束されていない（つまり、 -自社ソフトウェアまたは狭いコミュニティ）。この質問のより一般的な形式が slashdot で尋ねられたため、一部の回答について そこにチェック を付けることができます。
それは私からの+1に値する素晴らしい質問です。質問は単純ですが、エンドユーザーの性質の多くの側面をカバーしています。それは、ここであなたとソフトウェア自体、そしてもちろんエンドユーザーに利益をもたらす多くの要因に要約されます。
- エラーメッセージをステータスバーに配置しないでください。色などでジャズアップされていても、メッセージを読むことはありません。どんなに頑張っても...発売前のWin 95 UIテストのある段階で、MSはUIを読み取る実験を行いました（ed-「議長の下を見る」）のコンテキストでメッセージが明示的に述べられていることに注意してください。$ 100ドルの請求書が議題が座っている椅子の下側にテープで貼られていました...ステータスバーにメッセージを見つけた人はいません。
- メッセージを短くし、「アラート：システムで問題が発生しました」などの威圧的な言葉を使用しないでください。エンドユーザーがパニックボタンを押すと、過剰に反応します...
- どんなに頑張っても、メッセージを識別するために色を使用しないでください...心理的には、それは雄牛に赤い旗を振るのと同じです！
- 中立的な言葉で最小限の反応と進め方を伝えましょう！
- ニュートラルなエラーメッセージを一覧表示するダイアログボックスを表示し、「これらのエラーメッセージを今後さらに表示しますか？」というエンドユーザーが最後に望んでいることを示すチェックボックスを含める方が良いかもしれませんポップアップメッセージで攻撃されるソフトウェアの途中で、彼らはイライラし、アプリケーションによってオフになります！チェックボックスがチェックされている場合は、代わりにファイルに記録してください...
- エンドユーザーに、どのエラーメッセージが表示されるかを通知してください...これは、...トレーニングとドキュメントを意味します...これは、理解するのが難しいものです...あると考えてほしくない「問題」または「グリッチ」であり、その場合に何をすべきか...彼らは実際にトリッキーなエラーの可能性があることを知らないはずです。
- 常に、常に、「問題のない番号1304が表示されたとき、どのように対応しましたか？あなたの解釈は何でしたか-そのおまけとして、エンドユーザーは「エラー1304、データベースオブジェクトが失われました！」の代わりに、より一貫した説明を提供できるかもしれません。代わりに、「これをクリックしたので、そのため、誰かが誤ってマシンのネットワークケーブルを引き抜いた場合」、これはそれに対処する必要があることの手がかりとなり、「エラー、ネットワーク接続が切断されました」と表示されるようにエラーを変更する可能性があります...ドリフトが発生します。
- 最後に重要なことですが、海外の対象者を対象とする場合は、エラーメッセージの国際化を考慮に入れてください。それが翻訳をより簡単にし、類義語や俗語などを避けるので、中立に保つ理由です。意味のない翻訳-たとえば、
フィアットフォード、自動車会社は彼らのブランドを売っていましたフィアットフォードピント、しかし南アメリカで販売が行われていないことに気づいた、それは判明した、ピントは「小さなペニス」のためのそこの俗語であり、それゆえ販売はなかった... - （ed）予想されるエラーメッセージのリストを、「エラーメッセージ」または「修正措置」などのタイトルのドキュメントの別のセクションに文書化し、ステートメントを使用してエラー番号を正しい順序でリストします。続行する方法についての1つまたは2つ...
- （ed）Victor Hurdugaciのおかげで、メッセージを丁寧に保ち、終わりにしないでください-ユーザーは愚かだと感じる。 Jack Marchettiによる回答に反します。ユーザーベースが国際的な場合...
編集：特別な感謝の言葉gnibbler他の非常に重要なポイントについても言及してくれました！
- エンドユーザーがエラーメッセージを選択/コピーして、必要に応じてヘルプサポートチームまたは開発チームにメールを送信できるようにします。
編集＃2：悪い！おっと、DanMのおかげで、このクルマについての名前を混同してしまいました。それは、フォードピントでした。 ..
Edit＃3：edで強調表示されており、追加または補遺を示し、他の入力にクレジットされています...
Edit＃4：ケンのコメントへの回答-これが私の見解です...いいえ、そうではありません。ニュートラルな標準のWindowsカラーを使用してください...派手なカラーは避けてください！黒色のテキストを使用した通常の灰色の背景色に固執します。これは、Microsoft仕様の通常の標準GUIガイドラインです。- Xガイドライン （ed）を参照してください。
派手な色を主張する場合は、少なくとも色覚異常の可能性のあるユーザーを考慮に入れてください。つまり、アクセシビリティは、障害を持つ人にとって、画面拡大に適したもう1つの重要な要素ですエラーメッセージ、色覚異常、アルビノに苦しむ人、派手な色、てんかんなどにも敏感かもしれません...発作を引き起こす可能性のある特定の色に苦しむかもしれません...
メッセージを表示します。デューデリジェンスとすべてですが、すべてのエラーをファイルに記録します。ユーザーは自分が何をしていたのか、またはイベントの数秒後にエラーメッセージが何であったのかを思い出すことができません。これは、パータレーターの目撃証言のようなものです。
彼らが問題を調整するのを助けることができるように彼らにあなたに電子メールを送るか、またはログをアップロードすることを許可する良い方法を提供してください。それがWebアプリケーションの場合：さらに良いことに、問題を報告する人よりも先に、状況に関する情報を受け取ることができます。
短い答え：できません。
短い回答：わかりやすく、関連性があり、状況に応じたものにします（混乱したものを強調します）。しかし、それでも、あなたは敗北の戦いを戦っています。人々はコンピューターの画面で読んだり、スキャンしたりせず、ダイアログボックスが消えるまでボタンをクリックするように訓練されています。
アラート/ポップアップは煩わしいため、誰もが最初に表示されるボタンを押します。
less煩わしいにします。例：ユーザーが日付を誤って入力した場合、または数値が期待される場所にテキストを入力した場合、DO N'Tポップアップメッセージが表示され、フィールドを強調表示して、その周りにメッセージを書き込みます。
カスタムメッセージボックスを作成する。システムのデフォルトのメッセージボックスを使用しないでください。たとえば、Windows XPメッセージボックス自体が煩わしいです。システムのデフォルトとは異なる背景色で、新しい色のメッセージボックスを作成してください。
非常に重要：主張しないでください。一部のメッセージボックスはモーダルダイアログを使用し、それを読み上げるように要求しますが、これは非常に煩わしいものです。メッセージボックスを警告メッセージとして表示できる場合は、たとえば、ページの右上にスタックオーバーフローメッセージが表示され、通知はするが不快ではないという方がよいでしょう。
[〜＃〜]更新[〜＃〜]
メッセージを意味があり、役立つものにします。たとえば、「キーボードが見つかりません。続行するにはF1キーを押してください」などのように記述しないでください。
ユーザーベースによっては、おかしい/失礼/個人的なエラーメッセージを書くことがうまく機能します。
たとえば、私は [〜＃〜] hr [〜＃〜] の人々が従業員の雇用/解雇日をよりよく追跡できるようにするアプリケーションを書きました。 [私たちは小さな会社で、とてもくつろいでいました]。
彼らが間違った日付を入力したとき、私は書きます：
お尻、日付の入力方法を学んでください！
編集：もちろん、より役立つメッセージは次のとおりです。「日付をmm/dd/yyyyとして入力してください。しかし、これは私が個人的に知っていた人事担当者にとって非常に小さなアプリケーションでした。したがって、再び人々は、この投稿の最初の行を読みます：ユーザーベースに応じて...
私は最近Art Instituteプロジェクトに取り組んだので、エラーメッセージは次のような聴衆に向けられました。
バロック時代以前のほとんどの芸術は無署名でした。ただし、現在はバロック時代を超えているため、すべてのフィールドに入力する必要があります。
基本的には可能な限り視聴者に向けてください。「メールを入力してください」や「有効なメールを入力してください」などの一般的ではない一般的なエラーを退屈させないでください。
エラーボックスには、アイコンではなく、かなり大きなビットマップで、標準のWindowsメッセージアイコンとは異なり、覚えやすいシンプルなグラフィックを配置しました。メッセージボックスの文言を覚えることはできませんが（メッセージボックスに[OK]ボタンが押されていても、ほとんどの人は読み上げません）、見た写真を覚えている人はほとんどいます。したがって、サポート担当者はお客様に「コーヒーを飲む人を見ましたか」と尋ねることができます。または「空の机を見ましたか？」少なくともそのようにして、何が問題だったかを大まかに知ることができます。
最良のUIデザインは、エラーメッセージを実質的に表示しない場所です。ソフトウェアはユーザーに適応する必要があります。このようなデザインでは、エラーメッセージは目新しいものになり、ユーザーの注意を引くことになります。このような無意味なダイアログでユーザーを駆り立てると、メッセージを無視するように明示的にトレーニングすることになります。
私の意見と経験では、エラーメッセージを読み取らないのはパワーユーザーです。私が知っている技術者以外の読者は、画面上のすべてのメッセージを最も注意深く読み、この時点での問題は、主に次のとおりです。彼らはそれを理解していません。
この時点があなたの経験の原因であるかもしれません、なぜなら彼らはいつかそれらを読むのをやめます、なぜなら彼らは「とにかくそれを理解していない」ので、あなたの仕事は簡単です：
エラーメッセージをできるだけわかりやすくし、技術的な部分は隠しておきます。
たとえば、次のようなメッセージを転送します。
ORA-00237：スナップショット操作は許可されていません：制御ファイルが新しく作成されました原因：CREATE CONTROLFILEで新しく作成された、現在マウントされている制御ファイルを使用してcfileMakeAndUseSnapshotを呼び出そうとしました。処置：現在の制御ファイルをマウントして、操作を再試行してください。
次のようなものに：
データベースの一時的な問題のため、このステップを処理できませんでした。 （あなたの管理者|ヘルプデスク|問題を解決するために開発者または管理者に連絡できる人）に連絡してください。ご不便おかけしてすみません。
エラーメッセージに意味があることをユーザーに示します。これはユーザーに支援を提供する方法であり、ユーザーはそれを読みます。専門用語や一般的なナンセンスメッセージの場合は、すぐに却下する方法を学習します。
詳細な診断情報を（たとえば、電子メールを介して）送信するデフォルトのアクションを備えたエラーダイアログを含めることは非常に良い習慣であることを学びました。貴重な情報または回避策でそれらの電子メールにすばやく応答すると、彼らはあなたを崇拝します。
これは優れた学習ツールでもあります。将来のバージョンでは、既知の問題を解決するか、少なくともインプレースの回避策情報を提供できます。それまでユーザーは、このメッセージはXによって引き起こされ、問題はYによって解決できることを理解します。
もちろん、これは大規模なアプリケーションでは機能しませんが、ユーザー数が数百のエンタープライズアプリケーションや、リーンアジャイルなリリースが頻繁にリリースされる環境では非常にうまく機能します。
編集：
あなたは幅広いユーザーベースを持っているので、ユーザーがしていることをする/期待することができるソフトウェアを提供することをお勧めします。電話番号が適切にフォーマットされていない場合はエラーメッセージを表示せず、正しい場合は再フォーマットします。
私は個人的には 私に考えさせない のソフトウェアが好きです。そして、あなた（開発者）が私の意図を解釈するためにできることが何もないときは、非常によく書かれた（そして実際のユーザーによってレビューされた）メッセージを提供します。
人はドキュメントを読まない（家庭用電化製品を接続したときに、次々に説明を読んだか）ことはよく知られていますが、彼らはすぐに結果を得る方法を試します、失敗したときは、meaningfulおよびhelpful情報を使用して、注意を引く（たとえば、しばらくの間デフォルトボタンを無効にする）必要があります。彼らはあなたのソフトウェアの失敗を気にしません、彼らは今、結果を得たいと思っています。
お楽しみください 。 （私たちがいるサイトを考えると、それは関連しているように見えました:)）
私の経験から：あなたしないでくださいユーザー（特に非技術的なユーザー）にエラーメッセージを読んでもらいます。メッセージがどれほど明確でわかりやすく、太字で赤く点滅している場合でも、ほとんどすべてのユーザーは、「すべてを本当に削除しますか？」であっても、使い慣れていないものをクリックするだけです。ユーザーが「OK」や「キャンセル」の代わりに「ウィンドウを閉じる」アイコンをクリックするのを見たことがあります。そうすることで、どのオプションを選択したかさえ知らなかったのですが...
本当にあなたが表示しているものをユーザーに読ませる必要がある場合は、ボタンがクリック可能になるまでJavaScriptカウントダウンをお勧めします。そうすれば、ユーザーはうまくいけば、待機時間を使用して実際に想定されている内容を読み取ることができます。しかし注意してください：ほとんどのユーザーはそれによってさらにいらいらします:)
私はさらに、「もっと読む」リンクのアイデアが好きですが、それだけでメッセージを取り除きたいユーザーがもっと興味を持つようになるとは思いません...
参考までに、エラーメッセージを読んでも、それを使って何もしないことを恐れているユーザーがいます。以前、お客様からエラーメッセージが表示され、どうすればよいかを尋ねられるサポートコールがありました。 「さて、あなたの選択肢は何ですか？」と私は尋ねました。 「ウィンドウには「OK」ボタンしかありません。」と彼は答えた。 ...うーん、難しいもの:)
ユーザーに簡単な回避策を提供できない限り、ユーザーにエラーメッセージをまったく表示しないでください。ユーザーの90％が何を言っているか気にしないので、意味がありません。
一方、[〜＃〜] can [〜＃〜]が実際にユーザーに役立つ回避策を示す場合、ユーザーに強制的にそれを読み取らせる1つの方法は、ボタンは10秒ほど後に有効になります。新しいプラグインをインストールしようとするときはいつでも、Firefoxがそれをどのように行うかということです。
それが完全なクラッシュであり、正常に回復できない場合は、次のように非常に簡単な言葉でユーザーに通知します。
「ごめんなさい、このクラッシュに関する情報をお送りしたいと思います。よろしいですか？YES/NO」
また、エラーメッセージが文章より長くならないようにしてください。人々（私も含む）がエラーについて話している段落全体を見るとき、私の心はただ止まります。
非常に多くのソーシャルメディアと情報の過負荷により、テキストの壁を見ると人々の心は凍りつきます。
編集：
最近誰かがまた、あなたが見せたいメッセージと一緒に漫画を使うことを提案しました。 Dilbert のようなもので、エラーの種類に近い可能性があります。
Slashdotのユーザー応答 here も参照してください。
追加したいことが1つあります。
アクションボタンに動詞を使用して、感嘆符ではなくエラーメッセージを閉じます。たとえば、「OK」は使用しないでください。 「閉じる」など.
私が学んだ良いヒントの1つは、新聞記事のようなダイアログボックスを作成することです。サイズの意味ではなく、重要性の意味で。説明させてください。
最初に読んで最も重要なことを書き、次に詳細な情報を提供する必要があります。
つまり、これは良くありません。
There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.
Do you want to retry opening the file?
代わりに、順序を変更します。
Problem loading file, do you want to retry?
There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.
このようにして、ユーザーは好きなだけ読んだり、迷惑をかけたりしながら、何が求められているのかを知ることができます。
エラーが赤で表示されることがよくあります（デザインで許可されている場合）。
赤は「アラート」などを表しますので、よく読まれます。
まず、ユーザーが実際に理解できるエラーメッセージを記述します。 「エラー：1023」は良い例ではありません。エラーをログに記録する方が、「派手な」コードでユーザーに表示するよりも良い方法だと思います。または、ロギングが不可能な場合は、ユーザーにエラーの詳細をサポート部門に送信する適切な方法を提供してください。
また、短く、十分に明確にしてください。技術的な詳細は含めないでください。使用できない情報は表示しないでください。可能であれば、エラーの回避策を提供してください。デフォルトルートを提供しない場合は、それを採用する必要があります。
アプリケーションがWebアプリの場合、カスタムエラーページを設計することをお勧めします。 SOを例にとります。ここで適切なエラーページをデザインする方法についていくつかのアイデアを得ることができます： http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages /
私たちはユーザーに彼らの上司に連絡があったことを伝えました（それは嘘でした）。それは少しうまく機能し、削除する必要がありました。
さて、あなたの質問に直接答えるために：あなたのプログラマーにあなたのエラーメッセージを書かせないでください。この1つのアドバイスに従えば、累積的に、何千時間ものユーザーの不安と生産性、そして何百万ドルもの技術サポートコストを節約できます。
ただし、実際の目標は、ユーザーが間違いを犯さないようにアプリケーションを設計することです。エラーマッサージにつながり、バックアップを要求するような行動を取らせないでください。簡単な例として、すべてのフィールドに入力する必要があるWebフォームでは、ユーザーが[送信]ボタンをクリックしたときにエラーメッセージをポップアップするのではなく、すべてのフィールドに有効なコンテンツが含まれるまで[送信]ボタンを有効にしないでください。これは裏側の作業が増えることを意味しますが、ユーザーエクスペリエンスが向上します。
もちろん、それは少し理想的な世界です。時々、プログラムエラーは避けられません。それらが発生した場合は、明確で完全で有用な情報を提供する必要があります。最も重要なのは、システムをユーザーに公開したり、ユーザーの行動を非難したりしないことです。
適切なエラーメッセージには次のものが含まれます。
- 何が問題で、なぜそれが起こったのか。
- 問題の解決方法。
あなたができる最悪のことの1つは、単にシステムエラーメッセージをユーザーに渡すことです。たとえば、Java=プログラムが例外をスローする場合、単にプログラマーをUIに渡してユーザーに公開するだけではなく、キャッチして明確なメッセージを作成します。ユーザーに提示できるユーザー支援開発者。
幸運にも、最後の仕事で、自分のエラーメッセージを書くことを考えないプログラマーのチームと協力することができました。 1つが必要でプログラムがそれを回避するように設計できない（多くの場合リソースが限られている）状況で彼らが気付いたときはいつでも、彼らはいつも私のところに来て、必要なものを説明し、エラーメッセージを作成させましたはっきりしていて、会社のスタイルに従っていました。それがすべてのプログラマーのデフォルトの考え方である場合、コンピューティングの世界ははるかに優れた場所です。
エラーが少ない
アプリケーションが定期的にあなたに嘔吐を投げかけると、あなたはそれに対して免疫を失い、エラーは背景のムザックを刺激します。エラーがまれなイベントである場合は、さらに注意が向けられます。
大したことではないものはすべて手に入れ、それらの警告をすべて捨て、ユーザーの意図を理解する方法を見つけ、可能な限り決定を下します。この方法で効率化を続けているアプリがいくつかあります。開発者はすべてのエラーを重要だと考えていますが、これはユーザーの観点からは当てはまりません。問題に対するユーザーの一般的な応答を探してそれをキャプチャし、それをyour応答として展開します。
エラーを発生させる必要がある場合：短い、簡潔、低いテロ要因、感嘆符なし。段落はfailです。
特効薬はありませんが、エラーを重要にするためにソーシャルエンジニアリングを行う必要があります。
技術的な詳細をさらに有効にする「詳細」ボタンを追加すると、それ自体が技術的であると考える対象読者の部分にそれを読むインセンティブを提供します
私はスラッシュドットで最も恐ろしい解決策の候補を読みました：
ユーザーにエラーの責任を負わせる唯一の方法は、エラーを強制的に排除することでペナルティを与えることです。初心者の場合、可能であれば、管理者パスワードを入力して削除しない限り、エラーは実際には終了しません。また、ユーザーが再起動してそれを削除した場合（すべてのクライアントPCでタスクマネージャーが無効になっている）、コンピューターはエラーを開きません。 15分間クラッシュしたアプリケーション。もちろん、これはすべて、対処するユーザーのタイプに依存します。技術的に熟練したユーザーはこの種のシステムを受け入れないためですが、文字どおり「年」をかけてユーザーがクラッシュの責任を負うようにし、IT部門が認識していることを確認した後管理が困難になる前に問題を修正するために、これらは機能した唯一の手順です。これで、すべてのエンドユーザーは、エラーを無視すると自分自身で問題が発生することを認識しています。
ボタンの状態を「いかがですか？ここをクリックして、この問題をサポートするサポート技術者に相談してください。」
実在の人物と話すオプションを提供する多くのWebサイトがあります。
承認された回答のすべての推奨事項にもかかわらず、私のユーザーは見つけた最初のボタンをクリックし続けました。だから今私はこれを示します：
ユーザーhasは、[OK]ボタンが表示される前に選択を行います
彼が3番目のオプションを選択した場合、彼は続行できます。それ以外の場合、アプリケーションは終了します。
間違いがあった直後に、フィードバックを提供することをお勧めします（ユーザーが間違いをしたことを述べます）。 （たとえば、日付フィールドの値を入力するときは、値を確認し、間違っている場合は、入力フィールドを視覚的に変更してください）。
ページにエラーがある場合（私はWeb開発に詳しいので、「ページ」と呼んでいますが、「フォーム」とも呼ばれます）、「エラーの概要」を表示して、エラーと正確にエラーが発生したものの箇条書きです。ただし、メッセージごとに5〜6語以上ある場合、それらは読み上げられない/理解されません。
「注意！注意！エラーメッセージを読まなければ死ぬでしょう！」