ユーザーにエラーメッセージを読ませるには？

技術者以外のユーザー向けにプログラムを作成すると、注意深く書かれた啓発的なエラーメッセージがユーザーに読まれず、いらいらしたばかりの最初のボタンをクリックするだけの危険性が高くなります。

したがって、ユーザーが単にエラーメッセージを放棄するのではなく、実際にエラーメッセージを読むのを支援するために推奨できる推奨事項について知りたいと思います。私が考えることができるアイデアは、次の線に沿って分類されます。

• もちろんヘルプのフォーマット。おそらく、より長く詳細なエラーメッセージにつながる[詳細]ボタンが付いた、シンプルで短いメッセージ
• すべてのエラーメッセージをユーザーガイドの一部にリンクさせる（やや難しい）
• エラーメッセージを発行しないでください。単に、タスクの実行を拒否してください（ユーザー入力を処理するための "Apple"の方法）

編集：私が念頭に置いている聴衆は、ソフトウェアをあまり頻繁に使用せず、拘束されていない（つまり、社内のソフトウェアや狭いコミュニティがない）かなり広いユーザーベースです。この質問のより一般的な形式がslashdotで尋ねられたので、いくつかの回答をそこで確認することができます。

それは私からの+1に値する素晴らしい質問です。質問は単純ですが、エンドユーザーの性質の多くの側面をカバーしています。これは、あなたとソフトウェア自体、そしてもちろんエンドユーザーに利益をもたらすいくつかの要因に要約されます。

• エラーメッセージをステータスバーに配置しないでください。色などでジャズアップされていても、メッセージを読むことはありません。どんなに頑張っても...発売前のWin 95 UIテストのある段階で、MSはUIを読み取るための実験を行いました（編集 -メッセージのコンテキストで明示的に述べられていることに注意してください） 「椅子の下を見てください」）、被験者が座っていた椅子の下側に$ 100ドルの紙幣がテープで留められていました...ステータスバーにメッセージが表示されていませんでした。
• メッセージを短くし、「アラート：システムで問題が発生しました」などの脅迫的な言葉を使用しないでください。エンドユーザーがパニックボタンを押すと、過剰に反応します...
• どんなに頑張っても、メッセージを識別するために色を使用しないでください...心理的には、それは雄牛に赤い旗を振るようなものです！
• 中立的な言葉で最小限の反応と進め方を伝えましょう！
• ニュートラルなエラーメッセージをリストするダイアログボックスを表示し、エンドユーザーが最後に望んでいる「これらのエラーメッセージを今後さらに表示しますか？」を示すチェックボックスを含める方が良い場合がありますポップアップメッセージで攻撃されるソフトウェアの途中で、彼らはイライラし、アプリケーションによってオフになります！チェックボックスがチェックされている場合は、代わりにファイルに記録してください...
• エンドユーザーにどのようなエラーメッセージが表示されるかを知らせてください...これは、...トレーニングとドキュメントを意味します...これは、理解するのが難しい問題です...あると思わせたくない「問題」または「グリッチ」であり、その場合に何をすべきか...彼らは実際にトリッキーなエラーの可能性があることを知らないはずです。
• 常に、常に、「問題のない番号1304が表示されたとき、どのように対応しましたか？あなたの解釈は何でしたか-そのおまけとして、エンドユーザーは「エラー1304、データベースオブジェクトが失われました！」の代わりに、より一貫した説明を提供できるかもしれません。代わりに、「これをクリックしたので、そのため、誰かが誤ってマシンのネットワークケーブルを引き抜いた場合」、これはそれに対処する必要があるという手がかりとなり、エラーを修正して「エラー、ネットワーク接続が切断されました」と表示される場合があります...ドリフトが発生します。
• 最後に重要なことですが、海外の対象者を対象とする場合は、エラーメッセージの国際化を考慮に入れてください。そのため、中立に保つのはそのためです。翻訳、同義語、俗語などの作成が容易になるためです。意味のない翻訳-たとえば、自動車会社のフィアットフォードは、自社のブランドのフィアットフォードピントを販売していましたが、南米では販売が行われていないことに気づきました。ピントは「小さなペニス」の俗語であり、販売はありませんでした。 ...
• （ed）予期されるエラーメッセージのリストを、「エラーメッセージ」または「修正処置」などのタイトルのドキュメントの別のセクションに文書化し、続行する方法に関するステートメントまたは2つを含む正しい順序でエラー番号をリストします。 ..
• （編集）彼の入力のためのビクターHurdugaciのおかげで、メッセージを丁寧に保ち、エンドユーザーを愚かに感じさせないでください。これは、ユーザーベースが国際的である場合、Jack Marchettiの回答に反します...

編集：別の非常に重要なポイントについても言及したgnibblerへの特別な感謝の言葉！

• エンドユーザーがエラーメッセージを選択/コピーして、必要に応じてヘルプサポートチームまたは開発チームにメールを送信できるようにします。

編集＃2：悪い！おっと、車について言ったDanMのおかげで、私は名前を混同しました、それはフォードピントでした...私の悪い...

編集＃3：edによって強調表示されて、追加または補遺を示し、他の入力にクレジットされています...

編集＃4：ケンのコメントへの応答-ここに私の見解があります...いいえ、そうではありません。中立的な標準のWindows色を使用してください...派手な色は避けてください！黒色のテキストを使用した通常の灰色の背景色に固執します。これは、Microsoft仕様の通常の標準GUIガイドラインです。UXガイドライン（ed）を参照してください。

派手な色を主張する場合は、少なくとも、色覚異常の可能性があるユーザー、つまり、アクセシビリティは、障害、画面拡大に適したエラーメッセージ、色覚異常、アルビノに苦しむ人にとってもう1つの重要な要素であることを考慮に入れてください。派手な色やてんかんにも敏感かもしれません...発作を引き起こす可能性のある特定の色に苦しんでいる可能性があります...

メッセージを表示します。デューデリジェンスとすべてが、すべてのエラーをファイルに記録します。ユーザーは自分が何をしていたのか、またはイベントの数秒後のエラーメッセージを思い出せません。これは、パータレーターの目撃証言のようなものです。

彼らが問題を調整するのを助けることができるように彼らにあなたに電子メールを送るか、またはログをアップロードすることを許可する良い方法を提供してください。それがWebアプリケーションの場合：さらに良いことに、問題を報告する誰よりも先に状況に関する情報を受け取ることができます。

短い答え：できません。

短い回答：わかりやすく、関連性があり、状況に応じたものにします（混乱したものを強調します）。しかし、それでも、あなたは敗北の戦いを戦っています。人々はコンピューターの画面で読むのではなく、スキャンして、ダイアログボックスが消えるまでボタンをクリックするように訓練されています。

エラーボックスには、アイコンではなく、かなり大きなビットマップであり、標準のWindowsメッセージアイコンのような単純で覚えやすいグラフィックを配置しました。メッセージボックスの言い回しを覚えることはできませんが（メッセージボックスに[OK]ボタンが押されていても、ほとんどの人は読み上げません）、見た写真を覚えている人はほとんどいます。したがって、サポート担当者はお客様に「コーヒーを飲む人を見ましたか」と尋ねることができます。または「空の机を見ましたか？」少なくともそのようにして、何が問題だったかを大まかに知ることができます。

ユーザーベースによっては、おかしい/失礼/個人的なエラーメッセージを書くことがうまくいく場合があります。

たとえば、人事担当者が従業員の雇用/解雇日をよりよく追跡できるアプリケーションを作成しました。[私たちは小さな会社で、とてもくつろいでいました]。

彼らが間違った日付を入力したとき、私は書きます：

ちょっとお尻、日付の入力方法を学んでください！

編集：もちろん、より役立つメッセージは次のとおりです。「日付をmm / dd / yyyyとして入力してください。しかし、これは私が個人的に知っていた人事担当者にとっては非常に小さなアプリケーションでした。したがって、再び人々は、この投稿の最初の行を読んでください：ユーザーベースに応じて...

私は最近Art Instituteプロジェクトに取り組んだので、エラーメッセージは次のような聴衆に向けられました。

バロック時代以前のほとんどの芸術は無署名でした。ただし、現在はバロック時代を超えているため、すべてのフィールドに入力する必要があります。

基本的には可能な限り視聴者を対象にしてください。「メールを入力してください」や「有効なメールを入力してください」などの一般的ではない一般的なエラーを退屈させないでください。

アラート/ポップアップは煩わしいため、誰もが最初に表示されるボタンを押します。

煩わしさを軽減します。例：ユーザーが間違った日付を入力するか、数字が予想されるテキストを入力した場合、その後、しないでくださいだけでフィールドを強調表示し、メッセージをポップアップし、その周りにメッセージのどこかを記述します。

カスタムメッセージボックスを作成します。システムのデフォルトのメッセージボックスを使用しないでください。たとえば、Windows XPのメッセージボックスは煩わしいものです。システムのデフォルトとは異なる背景色で、新しい色のメッセージボックスを作成します。

非常に重要：主張しないでください。一部のメッセージボックスはモーダルダイアログを使用し、それを読み上げるように要求しますが、これは非常に迷惑です。メッセージボックスを警告メッセージとして表示できる場合は、たとえば、ページの右上にスタックオーバーフローメッセージが表示され、通知はするが不快ではないという方がよいでしょう。

更新
メッセージを意味のある有用なものにします。たとえば、「キーボードが見つかりません。続行するにはF1キーを押してください」などのように記述しないでください。

最良のUIデザインは、エラーメッセージを実質的に表示しない場所です。ソフトウェアはユーザーに適応する必要があります。このようなデザインでは、エラーメッセージは目新しいものになり、ユーザーの注意を引くことになります。このような無意味なダイアログでユーザーを駆り立てると、メッセージを無視するように明示的にトレーニングすることになります。

私の意見と経験では、エラーメッセージを読み取らないのはパワーユーザーです。私が知っている非技術者は画面のすべてのメッセージを最も注意深く読み、この時点での問題は主に次のとおりです。彼らはそれを理解していません。

この時点があなたの経験の原因であるかもしれません、なぜなら彼らはある時点でそれらを読むのをやめます、なぜなら彼らは「とにかくそれを理解しない」ので、あなたの仕事は簡単です：

エラーメッセージをできるだけわかりやすくし、技術的な部分は隠しておきます。

たとえば、次のようなメッセージを転送します。

ORA-00237：スナップショット操作は許可されていません：制御ファイルが新しく作成されました原因：CREATE CONTROLFILEで新しく作成された、現在マウントされている制御ファイルを使用してcfileMakeAndUseSnapshotを呼び出そうとしました。処置：現在の制御ファイルをマウントして、操作を再試行してください。

次のようなものに：

データベースの一時的な問題のため、このステップを処理できませんでした。（あなたの管理者|ヘルプデスク|問題を解決するために開発者または管理者に連絡できる人）に連絡してください。ご不便おかけしてすみません。

エラーメッセージに意味があることをユーザーに示します。これはユーザーに支援を提供する方法であり、ユーザーはそれを読みます。専門用語や一般的な意味のないメッセージの場合は、すぐに却下する方法を学びます。

詳細な診断情報を（たとえば電子メールを介して）送信するデフォルトのアクションを含むエラーダイアログを含めることは非常に良い習慣であることを学びました。貴重な情報や回避策でそれらの電子メールにすばやく応答すると、彼らはあなたを崇拝します。

これは優れた学習ツールでもあります。将来のバージョンでは、既知の問題を解決するか、少なくともインプレースの回避策情報を提供できます。それまでユーザーは、このメッセージはXによって引き起こされ、問題はYによって解決できることを理解します。

もちろん、これは大規模なアプリケーションでは機能しませんが、数百人のユーザーがいるエンタープライズアプリケーションや、リーンアジャイル、早期リリースが頻繁に行われる環境では非常にうまく機能します。

編集：

あなたは幅広いユーザーベースを持っているので、ユーザーがしていることをする/期待することができるソフトウェアを提供することをお勧めします。電話番号が適切にフォーマットされていない場合はエラーメッセージを表示せず、正しい場合は再フォーマットします。

私は個人的に私に考えさせないソフトウェアが好きで、たまにあなた（開発者）が私の意図を解釈するために何もできないときは、非常によく書かれた（そして実際のユーザーによってレビューされた）メッセージを提供します。

人々がドキュメントを読まない（家庭用電化製品を差し込んだときに連続して説明を読んだか）ことはよく知られていることです。しばらく無効にデフォルトボタン）意味のあると便利情報。彼らはあなたのソフトウェアの失敗を気にしません、彼らは今、結果を得たいと思っています。

それらを楽しくする。（私たちがいるサイトを考えると、それは関連しているように見えました:)）

まず、ユーザーが実際に理解できるエラーメッセージを記述します。「エラー：1023」は良い例ではありません。エラーをログに記録する方が、「派手な」コードでユーザーに表示するよりも良い方法だと思います。または、ログを記録できない場合は、ユーザーにエラーの詳細をサポート部門に送信する適切な方法を提供します。

また、短く、十分に明確にしてください。技術的な詳細は含めないでください。使用できない情報は表示しないでください。可能であれば、エラーの回避策を提供してください。デフォルトルートを提供しない場合は、それを採用する必要があります。

アプリケーションがWebアプリの場合、カスタムエラーページを設計することをお勧めします。彼らはユーザーのストレスを軽減します。あなたはここで良いエラーページをデザインする方法についていくつかのアイデアを得ることができます：http : //www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

追加したいことが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.

このようにして、ユーザーは好きなだけ読んだり、迷惑をかけたりしながら、何が求められているのかを知ることができます。

また、スラッシュドットのユーザー応答を参照してくださいここに。

ユーザーに簡単な回避策を提供できる場合を除いて、ユーザーにエラーメッセージをまったく表示しないでください。ユーザーの90％が何を言っているか気にしないので、意味がありません。

あなたがいる場合一方、CAN、実際にユーザーに便利な回避策を示し、それを読むためにそれらを強制する、その後一つの方法は、OKボタンを10秒ほど後に有効になるようです。新しいプラグインをインストールしようとしているときに、Firefoxがどのようにそれを実行するかということです。

それが完全なクラッシュであり、正常に回復できない場合は、次のように非常に簡単な言葉でユーザーに通知します。

「ご迷惑をおかけして申し訳ありません。このクラッシュに関する情報をお送りしますが、よろしいですか？はい/いいえ」

また、エラーメッセージが文章より長くならないようにしてください。人々（私も含む）がエラーについて話している段落全体を見るとき、私の心はただ止まります。

多くのソーシャルメディアと情報の過負荷により、テキストの壁を見ると人々の心は凍りつきます。

編集：

最近誰かがまた、あなたが見せたいメッセージと一緒に漫画を使うことを提案しました。あなたが持っているかもしれないタイプのエラーに近いかもしれないディルバートからの何かのように。

私の経験から：ユーザー（特に非技術者）がエラーメッセージを読むことはできません。メッセージがどれほど明確でわかりやすく、太字で赤く点滅していても、ほとんどすべてのユーザーは、「本当にすべてを削除しますか？」であっても、使い慣れていないものをクリックするだけです。ユーザーがどのオプションを選択したかさえ知らなかったにもかかわらず、ユーザーが「OK」や「キャンセル」の代わりに「ウィンドウを閉じる」アイコンをクリックするのを見てきました...

表示しているものをユーザーに強制的に読ませる必要がある場合は、ボタンがクリック可能になるまでJavaScriptカウントダウンをお勧めします。そうすれば、ユーザーはうまくいけば、待機時間を使用して実際に想定されている内容を読み取ることができます。しかし注意してください：ほとんどのユーザーはそれによってさらにいらいらします:)

私はさらに、「もっと読む」リンクのアイデアが好きですが、それだけでメッセージを取り除きたいユーザーがもっと興味を持つようになるとは思いません...

参考までに、エラーメッセージを読んでも、何もしないように恐れているユーザーがいます。以前、お客様からエラ​​ーメッセージが表示され、どうすればよいかを尋ねられるサポートコールがありました。「さて、あなたの選択肢は何ですか？」と私は尋ねました。「ウィンドウには「OK」ボタンしかありません。」と彼は答えた。... mmh、ハードなもの:)

エラーが赤で表示されることがよくあります（デザインで許可されている場合）。

赤は「アラート」などを意味するので、よく読まれます。

さて、あなたの質問に直接答えるために：あなたのプログラマーにあなたのエラーメッセージを書かせないでください。この1つのアドバイスに従えば、累積的に、何千時間ものユーザーの不安と生産性、そして何百万ドルもの技術サポートコストを節約できます。

ただし、実際の目標は、ユーザーが間違いを犯さないようにアプリケーションを設計することです。エラーマッサージにつながり、バックアップを要求するような行動を取らせないでください。簡単な例として、すべてのフィールドに入力する必要があるWebフォームでは、ユーザーが[送信]ボタンをクリックしたときにエラーメッセージをポップアップするのではなく、すべてのフィールドに有効なコンテンツが含まれるまで[送信]ボタンを有効にしないでください。これは裏側の作業が増えることを意味しますが、ユーザーエクスペリエンスが向上します。

もちろん、それは少し理想的な世界です。場合によっては、プログラムエラーが避けられないことがあります。それらが発生した場合は、明確で完全かつ有用な情報を提供する必要があります。最も重要なのは、システムをユーザーに公開したり、ユーザーの行動を非難したりしないことです。

適切なエラーメッセージには次のものが含まれます。

1. 問題は何で、なぜそれが起こったのか。
2. 問題の解決方法。

実行できる最悪のことの1つは、単にシステムエラーメッセージをユーザーに渡すことです。たとえば、Javaプログラムが例外をスローする場合、プログラマーをUIに渡してユーザーに公開しないでください。それをキャッチし、ユーザーアシスタンスデベロッパーによって作成された、ユーザーに提示できる明確なメッセージを用意します。

幸運にも、最後の仕事で、自分のエラーメッセージを書くことを考えないプログラマーのチームと協力することができました。1つが必要でプログラムがそれを回避するように設計できない（多くの場合リソースが限られている）状況で彼らが気付いたときはいつでも、彼らはいつも私のところに来て、彼らが必要なものを説明し、エラーメッセージを作成させました。はっきりしていて、会社のスタイルに従っていました。それがすべてのプログラマーのデフォルトの考え方である場合、コンピューティングの世界ははるかに優れた場所になるでしょう。

エラーが少ない

アプリケーションが定期的にあなたに嘔吐を投げかけると、あなたはそれに対して免疫を失い、エラーは背景のムザックを刺激します。エラーがまれなイベントである場合、より多くの注意を集めます。

大したことではないものはすべて手に入れ、それらの警告をすべて捨て、ユーザーの意図を理解する方法を見つけ、可能な限り決定を下します。この方法で効率化を続けているアプリがいくつかあります。開発者はすべてのエラーを重要だと考えていますが、これはユーザーの観点からは正しくありません。問題に対するユーザーの一般的な応答を探してそれをキャプチャし、それを応答として展開します。

エラーを発生させる必要がある場合：短い、簡潔、低いテロ要因、感嘆符なし。段落は失敗します。

特効薬はありませんが、エラーを重要にするためにソーシャルエンジニアリングを行う必要があります。

私たちはユーザーに彼らの上司に連絡したことを伝えました（それは嘘でした）。それは少しうまく機能し、削除する必要がありました。

技術的な詳細をさらに有効にする「詳細設定」ボタンを追加すると、それ自体を技術的であると考える対象読者の部分にそれを読むインセンティブを提供します

間違いが発生した直後にフィードバックを提供することをお勧めします（ユーザーが間違いを犯したことを述べます）。（たとえば、日付フィールドの値を入力するときは、値を確認し、間違っている場合は入力フィールドを視覚的に変えてください）。

ページにエラーがある場合（私はWeb開発に詳しいので、「ページ」と呼んでいますが、「フォーム」とも呼ばれます）、「エラーの概要」を表示して、エラーと正確にエラーが発生したものの箇条書きです。ただし、メッセージごとに5〜6語以上ある場合、それらは読み上げられません/理解されません。

ボタンの状態を「いかがですか？ここをクリックして、この問題をサポートするサポート技術者に相談してください。」

実在の人物と話すオプションを提供する多くのWebサイトがあります。

私はスラッシュドットで最も恐ろしい解決策の候補を読みました：

ユーザーにエラーの責任を負わせる唯一の方法は、エラーを強制的に排除することでペナルティを与えることです。初心者の場合、可能であれば、管理者パスワードを入力して削除しない限り、エラーは実際には終了しません。また、ユーザーが再起動してそれを削除した場合（すべてのクライアントPCでタスクマネージャーが無効になっている）、コンピューターはエラーを開きません。 15分間クラッシュしたアプリケーション。もちろん、これはすべて、対処するユーザーのタイプに依存します。より技術的に熟練したユーザーはこの種のシステムを受け入れないためですが、文字どおり「年」をかけてユーザーがクラッシュの責任を負うようにし、IT部門が認識していることを確認した後管理が困難になる前に問題を修正するために、これらは機能した唯一の手順です。さて、

「注意！注意！エラーメッセージを読まなければ死ぬでしょう！」

承認された回答のすべての推奨事項にもかかわらず、私のユーザーは見つけた最初のボタンをクリックし続けました。だから今私はこれを示します：

ユーザーは [OK]ボタンが表示される前に選択を行う必要があります

彼が3番目のオプションを選択した場合、彼は続行できます。それ以外の場合、アプリケーションは終了します。