user-interface - ユーザーにエラーメッセージを読ませるにはどうすればよいですか？

Question

技術者以外の視聴者向けにプログラムする場合、ユーザーが注意深く書かれた啓発的なエラーメッセージを読まない可能性が高く、欲求不満の肩をすくめて利用可能な最初のボタンをクリックするだけです。

だから、単にそれを脇に置くのではなく、ユーザーが実際にあなたのエラーメッセージを読むのを助けるためにあなたがどのような良い習慣を勧めることができるのか疑問に思います。私が考えることができるアイデアは、次のようなものになります。

もちろん、フォーマットは役に立ちます。おそらく、より長く、より詳細なエラーメッセージにつながる「詳細」ボタンが付いた、単純で短いメッセージです。
すべてのエラーメッセージをユーザーガイドの一部のセクションにリンクさせます（達成するのがやや難しい）
エラーメッセージを発行せず、タスクの実行を拒否するだけです（ユーザー入力を処理する「Apple」の方法）。

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

score 71 · Accepted Answer

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

ステータスバーにエラーメッセージを表示しないでください。エラーメッセージは、色などで飾り立てられていても決して読みません。どんなに頑張っても... Win 95 の UI テストが開始される前のある段階で、MS は UI を読み取る実験を行いました ( ed - コンテキストで明示的に記述されたメッセージに注意する必要があります)。「椅子の下を見てください」 )、被験者が座っていた椅子の下側に 100 ドル札がテープで貼られていました...誰もステータスバーのメッセージに気づきませんでした!
メッセージは短くしてください。「アラート: システムで問題が発生しました」などの威圧的な言葉は使用しないでください。エンドユーザーは非常ボタンを押して過剰反応することになります...
どんなに頑張っても、メッセージを識別するために色を使用しないでください...心理的には、雄牛に赤旗を振るようなものです!
最小限の反応と進め方を伝えるために、ニュートラルな言葉を使用してください。
中立的なエラーメッセージを一覧表示するダイアログボックスを表示し、「今後これらのエラーメッセージをもっと表示しますか?」というチェックボックスを含める方がよい場合があります。ソフトウェアの途中でポップアップメッセージが殺到すると、彼らはイライラし、アプリケーションによってオフにされます。チェックボックスがオンになっている場合は、代わりにファイルに記録します...
どのようなエラーメッセージが表示されるかをエンドユーザーに知らせてください...これは...トレーニングとドキュメントを意味します...これは理解するのが難しいものです...エンドユーザーに、「問題」または「グリッチ」であり、その場合に何をすべきか...彼らは、エラーが発生する可能性があることを知ってはなりません。
常に、常に、平穏無事に発生したときにフィードバックを求めることを恐れないでください-「エラー番号1304が表示されたとき、どのように反応しましたか? あなたの解釈は何でしたか? - おまけに、エンドユーザーは「エラー 1304、データベースオブジェクトが失われました!」ではなく、より一貫した説明を提供できる場合があります。代わりに、「私はこれをクリックしたので、そのため、誰かがマシンのネットワークケーブルを誤って引っ張った場合、これに対処しなければならないことがわかり、エラーが「おっと、ネットワーク接続が切断されました」と修正される可能性があります...ドリフトが発生します。
最後に大事なことを言い忘れましたが、国際的な視聴者をターゲットにしたい場合は、エラーメッセージの国際化を考慮に入れてください。そのため、翻訳が容易になり、同義語やスラングワードなどを避けるため、中立的な状態を保つ必要があります。意味のない翻訳 - たとえば、自動車会社であるフィアットフォードは自社ブランドのフィアットフォードピントを販売していましたが、南アメリカで販売が行われていないことに気付きました。ピントは南米では「小さなペニス」を表すスラングであり、したがって販売は行われませんでした。 ...
( ed )「エラーメッセージ」または「修正アクション」などのタイトルのドキュメントの別のセクションに予想されるエラーメッセージのリストを文書化し、エラー番号を正しい順序でリストし、続行方法について 1 つまたは 2 つのステートメントを記載します。 ..
( ed ) Victor Hurdugaciの意見に感謝します。メッセージは礼儀正しく保ち、エンドユーザーをばかげていると感じさせないでください。ユーザーベースが国際的である場合、これはJack Marchettiの回答に反します...

編集:もう 1 つの非常に重要なポイントについて言及したgnibblerに感謝の言葉を贈ります。

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

編集＃2：悪い！おっと、車について言及してくれたDanMのおかげで、名前を混同してしまいました。Ford Pintoでした...私の悪い...

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

編集＃4：ケンのコメントに応えて-これが私の見解です...いいえ、そうではありません。ニュートラルな標準のWindows色を使用してください...派手な色には行かないでください！Microsoft 仕様の通常の標準 GUI ガイドラインである、通常の灰色の背景色と黒のテキストに固執します。UX ガイドライン( ed ) を参照してください。

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

score 16 · Accepted Answer

彼らにメッセージを見せてください。十分な注意を払いますが、すべてのエラーをファイルに記録します。ユーザーは、イベントの数秒後に何をしていたのか、エラーメッセージが何だったのかを思い出せません。これは、加害者の目撃証言のようなものです。

問題の調整を支援できるように、ログを電子メールで送信したりアップロードしたりできるようにする良い方法を提供してください。Web アプリケーションの場合: さらに良いことに、問題が報告される前に状況に関する情報を受け取ることができます。

score 11 · Accepted Answer

簡単な答え: できません。

短い答えではありません: それらを目に見えるようにし、関連性があり、文脈に即したものにします (彼らが台無しにしたものを強調します)。それでも、あなたは負け戦を戦っています。人々はコンピューターの画面で本を読むのではなく、スキャンし、ダイアログボックスが消えるまでボタンをクリックするように訓練されています。

score 10 · Accepted Answer

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

煩わしさを軽減します。例: ユーザーが日付を間違って入力した場合、または数字が必要な場所にテキストを入力した場合は、メッセージをポップアップ表示せず、フィールドを強調表示してその周りにメッセージを書き込みます。

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

非常に重要: 主張しないでください。一部のメッセージボックスはモーダルダイアログを使用し、それを読ませようとしますが、これは非常に面倒です。メッセージボックスを警告メッセージとして表示することができれば、より良いでしょう。たとえば、スタックオーバーフローメッセージがページの上部に表示され、情報を提供しますが迷惑ではありません。

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

score 10 · Accepted Answer

アイコンではなく、かなり大きなビットマップであり、標準の Windows メッセージアイコンのようなものではありません。メッセージボックスの文言を覚えている人は誰もいませんが (ボックスに「OK」ボタンが押せばほとんどの人はそれを読むことさえできません)、ほとんどの人は見た画像を覚えています。そのため、サポート担当者はお客様に「コーヒーを飲む男性を見ましたか?」と尋ねることができます。または「空の机を見ましたか？」. 少なくともそのようにして、何がうまくいかなかったのかを大まかに知ることができます。

score 10 · Accepted Answer

ユーザーベースによっては、面白い/失礼な/個人的なエラーメッセージを書くと効果的です。

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

彼らが間違った日付を入力したとき、私は次のように書いていました。

日付の入力方法を学びましょう。

編集: もちろん、より役立つメッセージは、「日付を mm/dd/yyyy として入力してください」、またはおそらくコードで、入力した内容とエラーを表示するために「blahblah」と入力したかどうかを確認することです。しかし、これは私が個人的に知っている人事担当者にとっては非常に小さなアプリケーションでした。したがって、再び人々は、この投稿の最初の行を読んでください:あなたのユーザーベースに応じて...

私は最近、アートインスティテュートのプロジェクトに取り組んでいたため、次のようなエラーメッセージは対象ユーザー向けでした。

バロック時代以前のほとんどの芸術は署名されていませんでした。しかし、今はバロックの時代を超えているので、すべての分野を完成させなければなりません。

基本的には、可能な限り聴衆に合わせて表示し、「電子メールを入力してください」や「有効な電子メールを入力してください」などの不可解な一般的なエラーで退屈にならないようにします。

score 8 · Accepted Answer

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

score 7 · Accepted Answer

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

この点があなたの経験の原因である可能性があります。「とにかく理解できない」ため、ある時点で彼らはそれらを読むのをやめるので、あなたの仕事は簡単です:

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

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

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

次のようなものに：

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

score 5 · Accepted Answer

エラーメッセージには意味があり、ユーザーを支援する方法であり、エラーメッセージを読むことをユーザーに示します。それが単なる専門用語または一般的なナンセンスなメッセージである場合、彼らはすぐにそれらを却下することを学びます.

詳細な診断情報を (電子メールなどで) 送信するための既定のアクションを含むエラーダイアログを含めることは非常に良い方法であることがわかりました。これらの電子メールに貴重な情報や回避策をすばやく返信すると、彼らはあなたを崇拝します。

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

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

編集：

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

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

人々がドキュメントを読まないことはよく知られています (家庭用電化製品にプラグを差し込んだときに、指示を連続して読みましたか?)。デフォルトのボタンをしばらく無効にする)有意義で役立つ情報を表示します。彼らはあなたのソフトウェアの失敗を気にせず、結果を得たいと思っています。

score 3 · Accepted Answer

私が学んだ 1 つの良いヒントは、ダイアログボックスを新聞記事のように書くべきだということです。サイズの意味ではなく、重要性の意味で。説明させてください。

読むべき最も重要なことを最初に書き、2 番目に詳細な情報を提供する必要があります。

言い換えれば、これは良くありません:

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.

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

score 2 · Accepted Answer

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

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

score 2 · Accepted Answer

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

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

アプリケーションが Web アプリの場合、カスタムエラーページを設計することをお勧めします。SO を例にとると、ユーザーへのストレスが軽減されます。優れたエラーページをデザインする方法については、http ://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/ を参照してください。

score 2 · Accepted Answer

私の経験から、ユーザー (特に非技術者) にエラーメッセージを読ませることはできません。表示されるメッセージがどれほど明確でわかりやすく、太く、赤く、点滅していても、ほとんどのユーザーは、「本当にすべてを削除しますか?」であっても、慣れていないものをクリックするだけです。ユーザーが「OK」または「キャンセル」の代わりに「ウィンドウを閉じる」アイコンをクリックするのを見てきました

表示内容をユーザーに読ませる必要がある場合は、ボタンをクリックできるようになるまで JavaScript-Countdown を使用することをお勧めします。そうすれば、ユーザーは待ち時間を使って、本来読むべきものを実際に読むことができるでしょう。ただし注意してください: ほとんどのユーザーは、それによってさらにイライラするでしょう :)

さらに、「もっと読む」リンクのアイデアも気に入っていますが、どうしてもメッセージを取り除きたいだけのユーザーにもっと興味を持ってもらえるとは思えません...

記録のために: エラーメッセージを読んでも、それを恐れて何もしないというユーザーがいます。私はかつて、顧客が私にエラーメッセージを読んで、何をすべきかを尋ねるサポートコールを持っていました. 「さて、あなたの選択肢は何ですか？」と私は尋ねました。「ウィンドウには「OK」ボタンしかありません」と彼は答えました。... うーん、難しい :)

score 2 · Accepted Answer

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

score 2 · Accepted Answer

一つ付け加えておきたいことがあります。

エラーメッセージを閉じるアクションボタンには、感嘆符ではなく動詞を使用します。たとえば、「OK!」は使用しないでください。「閉じる」など

score 2 · Accepted Answer

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

一方、実際にユーザーに有用な回避策を示すことができる場合、ユーザーにそれを読ませる 1 つの方法は、10 秒ほど後に [OK] ボタンを有効にすることです。新しいプラグインをインストールしようとするときの Firefox のやり方と同じです。

正常に回復できない完全なクラッシュの場合は、次のように非常に一般的な言葉でユーザーに通知します。

「お手数をおかけして申し訳ありません。このクラッシュに関する情報を送信したいのですが、許可していただけますか? はい / いいえ」

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

あまりにも多くのソーシャルメディアと情報過多により、人々はテキストの壁を見ると頭が固まってしまいます。

編集：

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

score 1 · Accepted Answer

マネージャーに連絡したことをユーザーに伝えました (これは嘘でした)。少しうまく機能しすぎて、削除する必要がありました。

score 1 · Accepted Answer

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

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

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

適切なエラーメッセージには、次の内容が含まれている必要があります。

何が問題で、なぜそれが起こったのか。
問題を解決する方法。

あなたができる最悪のことの 1 つは、単にシステムエラーメッセージをユーザーに渡すことです。たとえば、Java プログラムが例外をスローした場合、単純にプログラマーズを UI に渡してユーザーに公開しないでください。それをキャッチし、ユーザー支援開発者が作成した明確なメッセージをユーザーに提示できるようにします。

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

score 1 · Accepted Answer

より技術的な詳細を有効にする「詳細」ボタンを追加すると、自分自身を技術的であると考えるターゲットオーディエンスの一部に、それを読むインセンティブが提供されます

score 0 · Accepted Answer

0

「注意！注意！エラーメッセージを読まないと死ぬぞ！」

于 2010-03-14T00:12:49.250 に答える

score 0 · Accepted Answer

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

ページにエラーがある場合 (私は Web 開発に興味があるため、「ページ」と呼んでいますが、「フォーム」とも呼ばれます)、「エラーの概要」を表示し、エラーがあることを説明します。エラーと、正確に発生したエラーの箇条書きリストです。ただし、メッセージごとに 5 ～ 6 語を超える場合、それらは読まれません/理解されません。

score 0 · Accepted Answer

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

ユーザーにエラーの責任を負わせるための唯一の方法は、エラーを強制的になくすことに対するペナルティをユーザーに与えることであることがわかりました。手始めに、可能であれば、管理者パスワードを入力してエラーを解消しない限り、エラーは実際には閉じられず、エラーを取り除くために再起動すると (すべてのクライアント PC でタスクマネージャーが無効になっています)、マシンは開きません。 15 分間クラッシュしたアプリケーション。もちろん、これはすべてあなたが扱っているユーザーのタイプに依存します。より技術的に熟達したユーザーはこの種のシステムを受け入れないからです。管理が難しくなる前に問題を修正するために、これらが機能した唯一の手順です。今、

score 0 · Accepted Answer

ボタンの状態を「ここをクリックして、この問題を支援するサポート技術者と話してください」にするのはどうですか。

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

score 0 · Accepted Answer

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

これを読む！

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

正しい選択肢を選んだ

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

user-interface - ユーザーにエラーメッセージを読ませるにはどうすればよいですか？

25 に答える 25

編集：

Related

Reference