エラー メッセージ
適切なユーザー インターフェイスかどうかの判断基準
デザイン コンセプト
使用パターン
ガイドライン
提示方法
ユーザー入力エラー
トラブルシューティング
アイコン
段階的表示
今後、このメッセージを表示しない
既定値
ヘルプ
エラー コード
サウンド
テキスト
ドキュメント
"エラー メッセージ" は、既に発生した問題をユーザーに通知します。これに対して、"警告メッセージ" は、将来、問題を引き起こす可能性のある状況をユーザーに通知します。エラー メッセージの表示には、モーダル ダイアログ ボックス、インプレース メッセージ、通知、またはバルーンが使用されます。
典型的なモーダル エラー メッセージ。
効果的なエラー メッセージは、問題が発生したという事実に加え、発生した理由や解決方法をユーザーに伝えます。ユーザーはエラー メッセージの結果に応じて、何らかの対処をするか、自分の操作を見直すことになります。
完成度が高く有益なエラー メッセージは、高品質のユーザー エクスペリエンスを実現するうえで不可欠な要素です。完成度の低いエラー メッセージは、製品に対する満足度を低下させ、無駄なテクニカル サポート コストにつながります。不要なエラー メッセージは、ユーザーの操作の流れを妨げることになります。
注: ダイアログ ボックス、警告メッセージ、確認、標準アイコン、通知、レイアウトに関するガイドラインは、それぞれ別の項目として記載しています。
適切なユーザー インターフェイスかどうかの判断基準
以下の点に基づいて判断します。
- ユーザー インターフェイス (UI) に表示されているのは、既に発生した問題か。該当しない場合は、エラー メッセージとはいえません。将来、問題を引き起こす可能性のある状況をユーザーに伝える場合は、警告メッセージを使用します。
- 混乱させることなく問題を防ぐことができるか。該当する場合は、問題そのものを回避するようにします。たとえば、想定外の値を入力できるコントロールの使用は避け、有効な値の範囲しか受け付けない制約付きコントロールを使用すれば、エラー メッセージを表示する必要はありません。また、クリックすることによってエラーになるような場合は、コントロールを無効化します。コントロールが無効化されていても、その理由が明らかに伝わるのであれば、これも 1 つの方法です。
- 問題を自動的に修正できるか。該当する場合は、問題を処理し、エラー メッセージを表示しません。
- ユーザーがメッセージの結果に応じて、何らかの対処をするか、自分の操作を見直す可能性はあるか。該当しない場合は、あえてユーザーの操作を中断する必要はなく、エラーを表示しない方がよいと判断できます。
- ユーザーが他のプログラムをアクティブに使用しているときにも、同じ問題が当てはまるかどうか。該当する場合は、通知領域アイコンを使用して問題を表示するようにします。
- 現在行っている操作に関連した問題でも、今すぐ何らか対処する必要があるわけでもないため、ユーザーが無視してもかまわないかどうか。該当する場合は、エラー メッセージではなく、操作の失敗通知を使用します。
- メイン ウィンドウ内のバックグラウンド タスクの状態に関連した問題か。該当する場合は、ステータス バーを使用して問題を表示するようにします。
- 主な対象ユーザーが IT プロフェッショナルであるかどうか。該当する場合は、ログ ファイル エントリや電子メール通知などのフィードバックのしくみを使用します。IT プロフェッショナルの場合、重大ではない情報にはログ ファイルを使用する方がいっそう好まれます。
デザイン コンセプト
完成度の低いエラー メッセージの特徴
残念ながら、わずらわしく、役に立たない、完成度の低いエラー メッセージは数多く存在します。エラー メッセージはモーダル ダイアログ ボックスを使用して表示されるため、ユーザーが現在行っている操作が中断され、メッセージに対して同意しなければ、操作を続行できません。
完成度が低いといっても、間違いは 1 つではなく、さまざまなケースが考えられます。次に、不名誉の殿堂に入っているエラー メッセージの例を見ていきます。
不要なエラー メッセージ
間違った例:
この例は、Windows® XP のエラー メッセージですが、最も完成度の低いものの 1 つといえます。Windows 自体がシャット ダウン処理の途中なので、プログラムを起動できなかったという意味です。これに関してユーザーが行えることはありません。また、ユーザーの最終的な目的は Windows をシャットダウンすることなので、何かをする理由もありません。しかも、このエラー メッセージを表示することで、Windows も自らシャット ダウンを妨げていることになります。
問題: エラー メッセージそのものが問題です。エラー メッセージを無視する以外、ユーザーにできることはありません。
主な原因: ユーザーの意図や視点を考えず、発生したエラーをすべて報告しようとしたことが原因です。
推奨される代替策: ユーザーが気に掛ける必要のないエラーは報告しないようにします。
"成功" しているにもかかわらず表示されるエラー メッセージ
間違った例:
このエラー メッセージは、プログラムの削除の直後に、ユーザーが Windows の再起動を拒否した場合に表示されます。ユーザーの視点から見れば、プログラムの削除は成功しています。
問題: ユーザーの視点から見れば、エラーは発生していません。エラー メッセージを無視する以外、ユーザーにできることはありません。
主な原因: ユーザーの視点から見ると作業は正常に完了していますが、アンインストール プログラムの視点で見ると確かに成功とはいえません。
推奨される代替策: ユーザーにとって容認可能な範囲であれば、エラーは報告しないようにします。
まったく意味のないエラー メッセージ
間違った例:
エラーが発生したことはわかりますが、ユーザーには、それが何なのか、また、何をすればよいのかがまったくわかりません。当然、[OK] ボタンをクリックしたいはずがありません。
問題: エラー メッセージに具体的な問題が記述されておらず、ユーザーにできることは何もありません。
主な原因: ほとんどの場合、プログラム側のエラー処理が不完全であることが原因です。
推奨される代替策: 適切に設計されたエラー処理をプログラムに実装するようにします。
わかりにくいエラー メッセージ
間違った例:
この例では、問題を示す文は明瞭ですが、補足説明があまりに難解です。
問題: 問題を示す文または解決方法が難解です。
主な原因: ユーザーの視点からではなく、コードの視点から問題を説明しています。
推奨される代替策: エラー メッセージの内容は、対象ユーザーが容易に理解できるように記述してください。ユーザーが実際に行うことのできる解決策を提供します。プログラムのエラー メッセージを 1 つの "エクスペリエンス" と考えて、適切に設計してください。プログラマが場当たり的にエラー メッセージを作成することは避けるようにします。
情報量の多すぎるエラー メッセージ
間違った例:
この例では、エラー メッセージに記述するトラブルシューティング手順としては、明らかに細かすぎます。
問題: 情報量が多すぎます。
主な原因: 複雑なトラブルシューティング プロセスをエラー メッセージ内で詳しく説明しようとしすぎていることが原因です。
推奨される代替策: 不要な情報は省略します。トラブルシューティング ツールの使用も避けてください。トラブルシューティング ツールが必要な場合は、最も可能性の高い解決策を中心に扱い、それ以外は、対応するヘルプ トピックへのリンクを設けるのみにとどめます。
不要で不親切なエラー メッセージ
間違った例:
オブジェクトが見つからないことと、"致命的" であることとが結び付きません。また、致命的なエラーへの応答として、[OK] ボタンしか存在しないのでは、あまりに不親切です。
問題: 語調が不必要に大げさで不親切です。
主な原因: 問題の原因は、プログラムの視点から見た場合の致命的なバグです。
推奨される代替策: 言葉の選択はユーザーの視点で慎重に行うようにします。
ユーザーに責任を押し付けるようなエラー メッセージ
間違った例:
ユーザーに過失があるかのような表現が使用されています。
問題: エラー メッセージの表現に問題があります。エラーの原因が、いかにもユーザーに非があるかのような表現です。
主な原因: 問題そのものではなく、ユーザーの行動に焦点を当てた無神経な表現が使用されています。
推奨される代替策: 問題を引き起こしたユーザーの操作ではなく、問題そのものに焦点を当てます。必要に応じて受動態を用いるなど、間接的な表現を心がけます。
意味のないエラー メッセージ
間違った例:
この例では、問題を示す文が非常に風刺的で、解決策も提示されていません。
問題: エラー メッセージの文に意味がなく、不合理な内容です。
主な原因: コンテキストをよく考えずにエラー メッセージが作成されています。
推奨される代替策: エラー メッセージの作成と校閲をライターに依頼します。エラーを校閲する際は、コンテキストとユーザーの心境を考慮するようにしてください。
プログラマ向けのエラー メッセージ
間違った例:
この例のエラー メッセージは、プログラムにバグがあることを示しています。プログラマにしか意味のないエラー メッセージです。
問題: プログラムの開発者がバグを特定するためのメッセージが、プログラムのリリース バージョンに残っています。こうしたエラー メッセージは、ユーザーにとって何の意味も価値もありません。
主な原因: プログラマが自分用のメッセージとして、通常の UI を使ったことに原因があります。
推奨される代替策: このようなメッセージは、製品のリリース バージョンから自動的に削除されるように、必ず条件付きコンパイルを使用してください。プログラマにしか意味のない内容なので、そのようなエラーをユーザーにわかりやすく記述しようとして無駄な時間を費やすことは避けましょう。
明らかに間違いのあるエラー メッセージ
間違った例:
この例には、メッセージの表示として、陥りやすいミスが多数存在します。
問題: エラー メッセージに表示されている情報は完全に誤りです。
主な原因: エラー メッセージのガイドラインが守られていません。このエラー メッセージは、ライターやエディターによって書かれたものではなく、校閲もされていません。
エラー処理の性質上、こうしたミスは頻繁に起こります。不名誉の殿堂入りを果たしそうなほど、ほぼすべてのエラー メッセージの完成度が低くなっています。
完成度の高いエラー メッセージの特徴
これまで紹介してきた悪い例と比べて、完成度の高いエラー メッセージには、次のような情報が盛り込まれています。
- 問題。問題が発生したことをはっきりと提示します。
- 原因。問題が発生した理由を説明します。
- 解決策。ユーザーが問題を解消できるように、解決策を提供します。
加えて、完成度の高いエラー メッセージには、次のような特徴があります。
- 関連性が高い。メッセージにユーザーが気に掛けている問題が反映されています。
- 実行性が高い。ユーザーがメッセージの結果に応じて、何らかの対処をするか、自分の操作を見直す必要があることがわかります。
- ユーザーが中心。コードの問題ではなく、対象ユーザーの操作や目的という観点から問題が説明されています。
- 簡潔である。メッセージが最小限に、かつ短すぎないように書かれています。
- 明確である。対象ユーザーが問題と解決策を理解しやすいように、わかりやすい言葉で書かれています。
- 具体的である。関連するオブジェクトの名前、場所、値などをはっきりと示しながら、問題が具体的な言葉で説明されています。
- 丁寧である。ユーザーに非があるかのような言い回しや、ユーザーを見下した表現は使用しません。
- めったに表示されない。表示する頻度はできるだけ少なくします。高い頻度で表示されるエラー メッセージは、設計に問題がある印象を与えます。
完成度の低いエラー メッセージでプログラムの評判を落とすようなことのないように、以上の特徴を踏まえながらエラー処理を設計してください。
不要なエラー メッセージを回避する
最も適切なエラー メッセージとは、決して発生しないエラー メッセージです。エラーの多くは、より良い設計をすることによって防ぐことができます。また、エラー メッセージよりも適切な方法が見つかることもあります。一般に、エラーは報告するよりも、防止するに越したことはありません。
最も避けるべきエラー メッセージは、対処のしようがないエラー メッセージです。ユーザーがメッセージを無視する以外に具体的な行動や変更を行うことができないのであれば、エラー メッセージを表示しないようにします。
ユーザーの視点で見ればまったく問題がなく、完全に排除してもかまわないエラー メッセージもあります。たとえば、既に削除処理が開始されているファイルを削除しようとすると、エラー メッセージが表示されることがあります。確かにコードの視点から見ると予期しないケースですが、ユーザーにとっては、最終的に目的が達成されるのでエラーとはいえません。
間違った例:
ユーザーの視点から見ると処理は成功しているため、このようなエラー メッセージは表示しない方がよいと判断できます。
もう 1 つの例を考えてみます。ユーザーが明示的にタスクをキャンセルするケースです。ユーザーの視点から見ると、次の状況はエラーではありません。
間違った例:
先ほどと同様、ユーザーの視点から見ると処理は成功しているため、このようなエラー メッセージは表示しない方がよいと判断できます。
テクノロジ中心ではなく、ユーザーの目的を中心に考えることによって、エラー メッセージを排除できる場合もあります。そのためには、エラーとは何なのかをもう一度よく考えることが必要です。ユーザーの目的に関する問題なのか、または、それを達成するうえでのプログラムの能力的な問題なのかを考えます。ユーザーの操作が現実世界において意味のある行動であれば、ソフトウェアでも同様に意味のある行動とする必要があります。
たとえば、e コマース プログラムの検索機能を使って製品を探したところ、入力したキーワードと完全に一致する製品が見つからないか、目的の製品が在庫切れだったとします。技術的にはエラーになりますが、エラー メッセージを表示する代わりに、プログラムで次のような処理を行うことが考えられます。
- 検索に対して最も近い条件を満たす製品を続けて検索します。
- 検索に明らかな誤りがある場合、修正候補を自動的に表示します。
- スペル ミス、つづり字異形、名詞の単複に対する動詞の活用形の誤りなど、一般的な問題は自動的に処理します。
- 製品の入荷予定日を表示します。
ユーザーの要求が理にかなったものである限り、適切に設計された e コマース プログラムは、それに見合った結果を返す必要があります。ただエラーを返すだけのプログラムは適切とはいえません。
効果的にエラー メッセージを防ぐ方法は他にもあります。問題の発生そのものを防ぐことです。たとえば、次のようにしてエラーを防ぐことができます。
- 制約付きコントロールを使用する。有効な値しか入力できないコントロールを使用します。リスト、スライダー、チェック ボックス、ラジオ ボタン、カレンダー コントロールなどのコントロールは、もともと有効な値の範囲が決まっていますが、値を自由に入力することができるテキスト ボックスでは、どうしてもエラー メッセージが必要となります。ただし、テキスト ボックスでも、特定の文字しか入力できないようにしたり、入力できる文字数を制限することは可能です。
- 対話操作を制限する。ドラッグ操作の場合、ドロップできる場所を制限します。
- コントロールやメニュー項目を無効にする。無効化されている理由をユーザーが容易に推測できる場合は、コントロールやメニュー項目を無効にします。
- 適切な既定値を設定する。既定値を表示することでユーザーの入力エラーを減らすことができます。値を変更する必要がある場合でも、既定値があれば、適切な入力形式を推測しやすくなります。
- 何もしなくても適切に動作するように配慮する。作業が自動的に実行されるか、作業そのものが不要であれば、ユーザーがミスをする可能性は低くなります。ユーザーが小さなミスをしたとしても、その意図がはっきりしていれば、問題を自動的に解決することが可能です。たとえば、書式に関する小さな問題は、自動的に修正することができます。
必要なエラー メッセージを提供する
本当に必要なエラー メッセージもあります。たとえば、ユーザーが何か誤った操作をした、ネットワークやデバイスが機能停止に陥った、オブジェクトが見つからない/変更されている、タスクを完了できない、プログラムにバグがあるなど、さまざまな問題が考えられます。こうした問題は回避するに越したことはありません。ソフトウェアを適切に設計することによって、ユーザーのさまざまなミスを防ぐことができる場合も確かにあります。しかし、こうした問題をすべて防ぐことは実際には困難です。また、こうした問題の 1 つが発生したとしても、エラー メッセージが適切であれば、ユーザーをすばやく適切な方向に導くことができます。
一般に、エラー メッセージは最悪のユーザー エクスペリエンスであって、確実に防ぐべきであると考えられています。しかし、正確にはそうではありません。最悪なのは、ユーザーを混乱させることであり、あらゆる手段を尽くして防ぐ必要があります。その手段の 1 つが、適切なエラー メッセージです。
コントロールの無効化について考えてみましょう。ほとんどの場合、コントロールが無効化されている理由は明確であるため、コントロールの無効化はエラー メッセージを回避する手段としては最適です。しかし、コントロールが無効化されている理由が明確でないとしたらどうでしょうか。ユーザーは先に進むことも、問題を特定するためのフィードバックを得ることもできません。ユーザーは立ち往生することでしょう。問題を推測するか、テクニカル サポートに問い合わせるしか方法がありません。このような場合は、コントロールを有効にしたままで、適切なエラー メッセージを表示した方がはるかに効果的です。
間違った例:
[次へ] ボタンが無効化されているのはなぜでしょうか。ユーザーを混乱させないためにも、この場合はボタンを有効にしておき、適切なエラー メッセージを表示する方がよいでしょう。
エラー メッセージを表示するかどうか迷った場合は、まず、実際にエラー メッセージを作成してみることです。ユーザーがその結果に応じて、何らかの対処をするか、自分の操作を見直す可能性が高いと判断できる場合は、エラー メッセージを提供するようにします。これに対して、ユーザーがメッセージを無視する以外に具体的な行動や変更を行うことができないのであれば、エラー メッセージを表示しないようにします。
適切なエラー処理のための設計
完成度の高いエラー メッセージ テキストを作成したくても、プログラム側で適切なエラー処理がなされていないために、それができない場合もあります。たとえば、次のエラー メッセージを見てください。
間違った例:
おそらく、プログラム側のエラー処理が不十分であるため、問題が何なのか本当にわからないものと思われます。
エラー メッセージの文そのものに問題がある可能性もありますが、むしろ、根本的にコードでエラー処理が適切になされていない、つまり、問題について具体的な情報が何もないことが、この文からは見て取れます。
具体的で実行性が高く、ユーザーの立場に立ったエラー メッセージを作成するには、プログラムのエラー処理コードによって、具体的で細分化されたエラー情報が提供される必要があります。その例を次に示します。
- 問題ごとに一意のエラー コードを割り当てる。
- 問題に複数の原因がある場合は、可能な限り、プログラム側で具体的な原因を特定する。
- 可変要素を伴う問題の場合は、それをパラメーターとして維持する。
- 低水準の問題は、高水準にして処理することで、ユーザーの視点からエラー メッセージを表示できるようにする。
完成度の高いエラー メッセージは、単に UI だけによるものではありません。ソフトウェア設計の問題でもあります。完成度の高いエラー メッセージ エクスペリエンスは、後から間に合わせで追加できるものではありません。
トラブルシューティング (およびその防止法)
トラブルシューティングの必要性が生じるのは、1 つのエラー メッセージで複数の原因が報告されたときです。
間違った例:
正しい例:
1 つのエラー メッセージで複数の問題が報告された場合、トラブルシューティングが必要になります。
次の例では、アイテムを移動できなかった理由として、既に移動された、既に削除された、または、アクセスが拒否されたことを挙げています。プログラム側で容易に原因を究明できるのであれば、ユーザーに具体的な原因を調査させる必要はありません。
間違った例:
この情報だけでは、問題の原因がわからず、ユーザーがトラブルシューティングを行う必要が生じます。
アクセスが拒否された場合はプログラム側で判断できるので、この問題は具体的なエラー メッセージで報告する必要があります。
正しい例:
具体的な原因が示されていれば、トラブルシューティングを行う必要はありません。
1 つのメッセージに複数の原因を記述するのは、具体的な原因を絞り込めない場合に限ります。この例では、アイテムが移動されたのか、削除されたのかを、プログラム側で判断することは困難である可能性があるため、1 つのエラー メッセージに複数の原因を記述しても差し支えはないかもしれません。しかし、この例で、削除済みのファイルを移動できなかったとしても、それをユーザーが気にする可能性は低いでしょう。原因がこのようなことであれば、エラー メッセージを表示する必要はありません。
不明なエラーの処理
何が問題で、何が原因なのか、また、どうすれば解決できるのか、本当に見当がつかない場合もあります。エラーを表示しないことが適切でない場合は、根拠のない問題、原因、解決策を表示するよりも、率直に、情報が不足していることを伝えた方がよいでしょう。
たとえば、プログラムにハンドルされない例外が存在する場合は、次のようなエラー メッセージが適しています。
不明なエラーを回避できない場合は、情報が不足していることを率直に伝えるようにします。
これに対し、役に立つ可能性が十分にあるならば、具体的で実行性が高い情報を積極的に提供するようにします。
不明なエラーでも、ネットワーク接続に問題がある可能性が高い場合は、このようなエラー メッセージが適しています。
適切なメッセージの種類を判断する
問題によっては、強調するポイントや表現の仕方により、エラー、警告、または情報のいずれでも表現できる場合があります。たとえば、Windows Internet Explorer® の設定で、署名されていない ActiveX コントロールの読み込みが禁止されているために、Web ページが ActiveX コントロールを読み込めないという状況を考えてみます。
- エラー。"このページに署名なしの ActiveX コントロールを読み込むことができません。" (既存の問題として表現されている)
- 警告。"Windows Internet Explorer が、署名なしの ActiveX コントロールを読み込むように設定されていないため、このページは予期したとおりに動作しない可能性があります。" または "このページで署名なしの ActiveX コントロールをインストールできるようにしますか? 信頼できない発行元からのコントロールをインストールすると、コンピューターに危害を与える可能性があります。" (どちらも、将来問題を引き起こす可能性のある状況として表現されている)
- 情報。"Windows Internet Explorer は、署名なしの ActiveX コントロールをブロックするように設定されています。" (単なる事実として表現されている)
適切なメッセージの種類を決定するには、ユーザーが認識または対処する必要のある、問題の最も重要な側面に焦点を当てます。一般に、何かの問題によってユーザーが操作を続けられなくなっている場合は、その問題をエラーとして表示します。ユーザーが操作を続行できる場合は、警告として表示するようにします。こうした重要な要素に基づいて、メイン指示テキストやその他の関連するテキストを作成したうえで、それに合ったアイコン (標準アイコンまたはその他) を選択します。メイン指示テキストとアイコンは、常に調和している必要があります。
エラー メッセージの提示
このトピックで取り上げている例を見てもわかるように、Windows プログラムのエラー メッセージは、多くの場合、モーダル ダイアログ ボックスが使用されます。しかし、エラー メッセージの提示方法は、それだけではありません。たとえば、次のような方法があります。
- インプレース
- バルーン
- 通知
- 通知領域アイコン
- ステータス バー
- ログ ファイル (IT プロフェッショナル向けのエラーの場合)
モーダル ダイアログ ボックスでのエラー メッセージの表示は、その場でユーザーの注意を引き、確認を求めるという意味では有効な手段です。しかし、その注意が必ずしも必要でない場合は、逆に大きな欠点となります。
ユーザーの操作を中断してまで、[閉じる] ボタンをクリックしてもらう必要性は本当にあるか、考えてみましょう。必要なければ、モーダル ダイアログ ボックスは使わずに他の方法を検討します。
モーダル ダイアログ ボックスは、直ちにユーザーに確認を求める必要がある場合は有効ですが、そうでない場合は逆効果になることがあります。一般に、目的を果たすことができる範囲で最も控えめな表示方法を使用することをお勧めします。
情報量を抑える
一般に、ユーザーはざっと見るだけで、きちんと読むことはしません。情報量が多いほどテキストを流し読みするのが難しくなり、ユーザーに全部読んでもらえる可能性は低くなります。テキストの情報量は必要最小限に減らし、追加情報を提供する場合は、段階的表示やヘルプ リンクを使用するようにします。
極端な例も多数ありますが、よく見られる典型的な例を 1 つ挙げます。次の例では、良いエラー メッセージの特徴を多く備えている反面、簡潔さに欠け、なかなか読む気になれません。
間違った例:
完成度の高いエラー メッセージではありますが、情報量が多すぎます。
このテキストが伝えようとしていることは、次のようなことではないでしょうか。
正しい例:
エラー メッセージの内容は基本的に同じですが、先ほどの例よりも、はるかにすっきりしています。
このエラー メッセージの特徴は、詳細な情報をヘルプに委ねるという、逆ピラミッド型の提示スタイルを使用していることです。
情報過多に関するガイドラインと例については、「ユーザー インターフェイスのテキスト」を参照してください。
8 つの重要な点
1. エラー処理を考慮したプログラム設計を行う。
2. 不要なエラー メッセージは表示しない。
3. 必要なエラー メッセージを表示して、ユーザーの混乱を防ぐ。
4. エラー メッセージには、問題、原因、および解決策を必ず明記する。
5. 適切なエラー メッセージの条件 (関連性が高い、実行性が高い、簡潔、明確、具体的、丁寧、めったに表示されない) を満たす。
6. プログラムの視点ではなく、ユーザーの視点からエラー メッセージを設計する。
7. ユーザーにトラブルシューティングをさせない (検出可能な原因ごとに異なるエラー メッセージを用いる)。
8. 目的を果たすことができる範囲で最も控えめな表示方法を使用する。
使用パターン
エラー メッセージには、いくつかの使用パターンがあります。
ガイドライン
提示方法
- 適切な場合は常にタスク ダイアログ ボックスを使用します。タスク ダイアログ ボックスを使用することによって、一貫した外観とレイアウトを実現できます。タスク ダイアログ ボックスを使用するには、Windows Vista® 以降が必要であるため、以前のバージョンの Windows には適しません。メッセージ ボックスを使用する必要がある場合は、メイン指示テキストと補足指示テキストの間に改行を 2 つ入力して分離します。
ユーザー入力エラー
- 可能な限り、次の方法によってユーザー入力エラーを回避または低減します。
- 有効な値しか入力できないコントロールを使用します。
- クリックすることによってエラーになるような場合は、コントロールやメニュー項目を無効化します。コントロールやメニュー項目が無効化されていても、その理由が明らかに伝わるのであれば、これも 1 つの方法です。
- 適切な既定値を設定する。
間違った例:
この例では、入力に制限があるにもかかわらず、制約のないテキスト ボックスが使用されています。このような場合は、スライダーを使用してください。
- ユーザー入力の問題をその場で指摘した方がよい場合は、モードレスのエラー処理 (インプレース エラーまたはバルーン) を使用します。
- テキスト ボックスにフォーカスがあるとき、または、テキスト ボックスからフォーカスが移動した直後に、ユーザー入力の問題が検出された場合、問題がそれほど重大ではなく一過性のものであれば、バルーンを使用します。インプレース メッセージの表示に必要な空き画面領域または動的レイアウトは、バルーンには必要ありません。一度に 1 つのバルーンだけを表示します。問題がそれほど重大なものではないので、エラー アイコンは不要です。バルーンは、クリックされるか、問題が解決されるか、一定の時間が経過すると消えます。
この例では、コントロールにフォーカスがある状態で、入力に問題があることをバルーンを使って通知しています。
- 操作から時間が経過した後でエラーが検出される場合は、インプレース エラーを使用します。コミット ボタンをクリックした時点で見つかるエラーなどに使用します (即座に反映される設定にはインプレース エラーを使用しないでください)。一度に複数のインプレース エラーを表示できます。標準のテキストと 16 × 16 ピクセルのエラー アイコンを使用します。可能であれば、このテキストとアイコンは問題のすぐ横に表示します。ユーザーが操作を確定し、他のエラーがないと判断されるまで、インプレース エラーは消えません。
この例では、コミット ボタンをクリックして初めてエラーが検出されるので、インプレース エラーが使用されています。
- 上記以外の問題には、モーダルなエラー処理 (タスク ダイアログ ボックスまたはメッセージ ボックス) を使用します。複数のコントロールが関連するエラー、その場で指摘する必要がないエラー、コミット ボタンがクリックされた時点で検出される入力以外のエラーなどが、これに該当します。
- ユーザー入力の問題が報告された場合は、間違ったデータが入力されている最初のコントロールに入力フォーカスを設定します。必要に応じてコントロールをスクロールして見える状態にしてください。テキスト ボックスの場合は、その内容全体を選択状態にします。常にどのコントロールに対するエラー メッセージなのかが、明確に伝わるようにする必要があります。
- 間違って入力されているデータをクリアしないでください。入力内容をそのまま残すことで、ユーザーは間違いに気付き、問題を訂正することができます。文字を最初から入力し直す手間も省くことができます。
- 例外: パスワードや PIN のテキスト ボックスは例外です。入力内容がマスク処理され、そのままでは効率よく入力できないので、入力内容をクリアしてください。
トラブルシューティング
- トラブルシューティングの必要性が生じないように注意してください。検出可能な複数の原因をそのまま 1 つのエラー メッセージで報告することは避けます。
- 検出可能な個々の原因に対応する個別のエラー メッセージを使用します (通常は、それぞれに補足指示テキストを付けます)。たとえば、いくつかの理由でファイルを開くことができない場合は、理由ごとに補足指示テキストを提供します。
- 1 つのメッセージに複数の原因を記述するのは、具体的な原因を絞り込めない場合に限ります。この場合、問題の解決につながる可能性の高い解決策から順に列挙するようにします。そうすることで、ユーザーが効率よく問題を解決することができます。
アイコン
- モーダル エラー メッセージ ダイアログ ボックスにはタイトル バー アイコンを割り当てません。タイトル バー アイコンは、メイン ウィンドウとサブ ウィンドウを視覚的に区別する場合に使用します。
- エラー アイコンを使用します。 次の場合は例外です。
- ユーザー入力の問題をモーダル ダイアログ ボックスまたはバルーンで表示する場合は、アイコンを使用しません。このような場合にアイコンを使用するのは、推奨される Windows のトーンに反するものです。ただし、インプレース エラー メッセージの場合は、エラー メッセージであることが明らかにわかるように、小さなエラー アイコン (16 × 16 ピクセル) を使用します。
これらの例は、エラー アイコンが不要なユーザー入力の問題です。
この例は、インプレース エラー メッセージなので、エラー メッセージであることを明確にするため、小さなエラー アイコンが必要です。
- アイコンが割り当てられている機能でユーザー入力以外の問題が生じている場合は、その機能のアイコンにエラー アイコンを重ねて表示します。その場合は、機能の名前をエラーの表題として使用します。
この例では、該当する機能のアイコンにエラー アイコンを重ね、エラーの表題に、その機能の名称を表示しています。
- ユーザー入力の問題をモーダル ダイアログ ボックスまたはバルーンで表示する場合は、アイコンを使用しません。このような場合にアイコンを使用するのは、推奨される Windows のトーンに反するものです。ただし、インプレース エラー メッセージの場合は、エラー メッセージであることが明らかにわかるように、小さなエラー アイコン (16 × 16 ピクセル) を使用します。
- エラーに警告アイコンを使用しないでください。ユーザーの不安を和らげる目的でこのような手法が使用されていることがありますが、エラーと警告は異なります。
間違った例:
この例では、エラーの深刻さを和らげるという、本来とは異なる目的で警告アイコンが使用されています。
その他のガイドラインと例については、「標準アイコン」を参照してください。
段階的表示
- 詳細の表示/非表示 (段階的表示) ボタンを使用して、エラー メッセージに含まれる高度な情報や詳細な情報を非表示にします。標準的な用途では、このようにしてエラー メッセージを簡素化します。必要な情報は非表示にしないでください。非表示にすると、ユーザーが気付かない可能性があります。
この例は、段階的表示ボタンを使用して、ユーザーが必要に応じて詳細な情報を閲覧できるようになっています。不要であれば展開しなくて済むため、UI もすっきりさせることができます。
- 実際に詳しい情報がない場合は、詳細の表示/非表示ボタンを使用しません。同じ情報を別の言葉で言い換えただけのものにならないように注意してください。
- ヘルプ情報を表示する目的で詳細の表示/非表示ボタンを使用しないでください。そのような場合は、ヘルプ リンクを使用してください。
ラベルのガイドラインについては、「段階的表示コントロール」を参照してください。
今後、このメッセージを表示しない
- エラー メッセージに、このオプションが必要な場合は、エラーとその頻度をもう一度よく考えてください。完成度の高いエラー (関連性が高い、実行性が高い、めったに表示されない) の特徴をすべて備えているのであれば、ユーザーにその表示を制限させる理由はありません。
その他のガイドラインについては、「ダイアログ ボックス」を参照してください。
既定値
- 既定値には、最も安全で、最も障害の起こる可能性が低く、最もセキュリティの高い応答が得られる値を選択します。安全性を判断要素として考える必要がない場合は、最もよく使用されるコマンドまたは最も便利なコマンドを選択します。
ヘルプ
- エラー メッセージはヘルプを参照しなくても済むように設計します。解決策にいくつもの手順が伴う場合を除けば、通常、問題を理解し解決するためにユーザーが外部のテキストを読む必要はありません。
- ヘルプのコンテンツは、関連性の高い有益な内容となるように配慮します。エラー メッセージと同じ情報を別の言葉で置き換えただけのものにならないように注意してください。問題を未然に防止する方法など、エラー メッセージには盛り込まれていない有益な情報を含めるようにします。リンクできる情報があるという理由だけで、ヘルプへのリンクを設けることは避けてください。
- ヘルプ コンテンツへのアクセスには、具体的で、簡潔で、関連性の高いヘルプ リンクを使用します。この用途でコマンド ボタンや段階的表示を使用しないでください。
- 具体的で実行性が高いエラー メッセージを作成できない場合は、オンライン ヘルプ コンテンツへのリンクの提供を検討します。オンライン ヘルプという形で追加情報をユーザーに提供すれば、プログラムのリリース後に情報を更新することもできます。
その他のガイドラインについては、「ヘルプ」を参照してください。
エラー コード
- 具体的で実行性が高いエラー メッセージを作成することが難しく、また、ヘルプを利用する利点もない場合は、エラー コードを提供することも検討します。ユーザーがインターネットから追加情報を検索する場合に、エラー コードがよく利用されます。
- 常に問題や解決策の説明文を提供します。問題や解決策の説明として、エラー コードだけに頼るのは避けてください。
間違った例:
この例では、エラー コードが解決策の説明文として代用されています。
- 原因にはそれぞれ一意のエラー コードを割り当てます。これにより、ユーザーがトラブルシューティングを行う必要がなくなります。
- インターネットで容易に検索できるエラー コードを使用します。32 ビットのコードを使用する場合は、先頭に 16 進数であることを表す "0x" を付加し、大文字を使用します。
正しい例:
1234
0xC0001234間違った例:
-1
-67113524 - 詳細の表示/非表示ボタンを使用してエラー コードを表示します。「エラー コード: <エラー コード>」のように表記します。
この例では、エラー メッセージを補足するものとしてエラー コードが使用され、追加情報を得る手立てとなっています。
サウンド
- エラー メッセージに効果音やビープ音は使用しないでください。耳障りになることが多く、必要性もありません。
- 例外: システム エラーの場合は例外です。コンピューターの運用に重大な影響を及ぼす問題で、ユーザーがすぐに対処しなければ深刻な結果が予想される場合は、効果音を再生するようにします。
テキスト
全般
- 冗長なテキストは削除します。タイトル、メイン指示テキスト、補足指示テキスト、コマンド リンク、コミット ボタンなどに冗長なテキストがないか確認してください。通常、メイン指示テキストと対話型コントロールのテキストはそのまま残し、他の部分にある冗長なテキストを削除します。
- ユーザーの立場に立った説明を使用します。ソフトウェアの観点からではなく、ユーザーの操作や目的という観点から問題を説明するようにします。対象ユーザーが理解できる有用な言葉を使用します。難解な技術的表現は避けます。
間違った例:
正しい例:
正しい例では、ユーザーが無理なく理解できる言葉が用いられているのに対し、間違った例では、難解な技術的表現が用いられています。
- 次の言葉は使用しないでください。
- エラー、障害 (代わりに "問題" を使用)
- 失敗しました (代わりに "できません" を使用)
- 不正な、無効な、悪い (代わりに "正しくない" を使用)
- 中止、キル、強制終了 (代わりに "停止" を使用)
- 致命的な (代わりに "重大な" を使用)
以上に挙げた言葉は不要であり、推奨される Windows のトーンに反するものです。エラー アイコンを正しく使用すれば、問題の発生を効果的に伝えることができます。
間違った例:
正しい例:
間違った例で使用されている、"致命的な" および "エラー" という表現は必要ありません。
- ユーザーに責任を押し付けたり、ユーザーに非があるような言い回しを避けます。"あなた" という表現は使わないようにします。一般には能動態が好まれますが、ユーザーを主語にすることでエラーの責任がユーザーにあるかのように感じさせてしまう可能性がある場合は受動態を使用します。
間違った例:
正しい例:
間違った例では、能動態が用いられているため、ユーザーに非があるかのように感じられます。
- 具体的にします。"構文エラー" や "無効な操作" など、あいまいな表現を避けます。関連するオブジェクトの名称、場所、値などを具体的に提示します。
間違った例:
ファイルが見つかりません。
ディスクがいっぱいです。
値が範囲外です。
文字が無効です。
デバイスを使用できません。これらの問題は、具体的な名前、場所、値が記載されていれば、より簡単に解決できます。
- 具体的に記述した方がよいからといって、可能性の低い問題、原因、解決策を挙げないでください。適切でない可能性のある問題、原因、解決策を提供することは避けてください。たとえば、不確実な情報を挙げるよりも、"不明なエラーが発生しました" とする方が適切です。
- "してください (please)" という表現は避けます。ユーザーに何か面倒なこと (処理の終了を待つなど) を依頼する場合や、ソフトウェア側の都合で何かを依頼する状況を除き、"してください" という表現は避けます。
正しい例:
"ファイルをコンピューターにコピーしています。しばらくお待ちください..." - 謝罪表現は、ユーザーにとって深刻な問題を引き起こしたエラー メッセージでのみ使用します。たとえば、データが失われた、コンピューターを使用できないなどが該当します。プログラムの正常な動作の範囲内で発生した問題 (ネットワーク接続の検出に一定時間かかるなど) の場合は、謝罪表現は使用しないでください。
正しい例:
"申し訳ございません。回復不可能な問題が検出されたため、コンピューター上のファイルを保護するために Fabrikam バックアップを終了しました。" - 製品に言及する際は省略名を使用します。製品のフルネームや商標記号は使用しません。ユーザーが製品から会社名を連想できない場合を除いて、会社名は含めません。プログラムのバージョン番号も省略します。
間違った例:
正しい例:
間違った例では、製品のフル ネームと商標記号が使用されています。
- オブジェクト名は二重引用符で囲みます。テキストが読みやすくなり、意味の取り違えを未然に防ぐことができます。
- 例外: 完全修飾のファイル パス、URL、ドメイン名などを引用符で囲む必要はありません。
正しい例:
この例では、オブジェクト名が引用符で囲まれていないと、エラー メッセージの意味が正しく伝わりません。
- オブジェクト名を文の冒頭に置くことは避けます。内容がわかりにくくなる場合があります。
- 感嘆符やすべて大文字での表現は使用しないでください。感嘆符や大文字は、ユーザーに向かって叫んでいる印象を与えます。
その他のガイドラインと例については、「スタイルとトーン」を参照してください。
タイトル
- タイトルにエラーの発生源となったコマンドや機能を明記します。 次の場合は例外です。
- いくつもの異なるコマンドによってエラーが表示される場合は、プログラム名を明記するようにします。
- タイトルが冗長であったりメイン指示テキストと紛らわしい場合は、代わりにプログラム名を使用します。
- タイトルで問題を説明したり要約することはしません。問題の説明や要約はメイン指示テキストで行います。
間違った例:
この例では、問題を説明するためにタイトルが間違って使用されています。
- タイトル スタイルの大文字化を使用し、末尾に句読点は付けません。
メイン指示テキスト
- メイン指示テキストでは、問題をはっきりと、わかりやすく、具体的な言葉で説明します。
- 簡潔な 1 文だけを使用します。メイン指示テキストには必須の情報だけを含めます。主語がプログラムまたはユーザーの場合は、暗黙の了解として省略してかまいません。簡潔にまとめることができる場合は、問題の理由を記述します。さらに説明が必要な場合は、補足指示テキストを使用します。
間違った例:
この例では、エラー メッセージ全体がメイン指示テキストに記述されているため、非常に読みにくいものになっています。
- 具体的に記述します。関連するオブジェクトがある場合は、その名前を提示します。
- 完全なファイル パスや URL をメイン指示テキストに記述することは避けます。代わりに略称 (ファイル名など) を使用し、フル ネーム (ファイル パスなど) は補足指示テキストに記述するようにします。ただし、他の補足指示テキストが必要なく、記述する完全なファイル パスや URL が 1 つのみであれば、メイン指示テキストに記述してもかまいません。
これはファイル名だけをメイン指示テキストに記述した例です。完全なパスは補足指示テキストに記述されています。
- コンテキストから明らかな場合は完全なファイル パスや URL を表示しません。
この例では、ユーザーが Windows エクスプローラーでファイルの名前を変更しています。この場合、完全なファイル パスはコンテキストから明らかなので必要ありません。
- 可能な限り現在形を使用する。
- センテンス スタイルの大文字化を使用します。
- 指示テキストが文の場合、文末の句点は含めません。指示テキストが疑問文の場合は、疑問符を付けます。
メイン指示テキストのテンプレート
表現に関して厳密な規則はありませんが、メイン指示テキストには、可能な限り次のテンプレートを使用してください。
- <主語 (省略可)> は <動作を実行> できません
- <理由> のため、<主語 (省略可)> は <動作を実行> できません
- <主語 (省略可)> は "<オブジェクト名>" に対して <動作を実行> できません
- <理由> のため、<主語 (省略可)> は "<オブジェクト名>" に対して <動作を実行> できません
- <動作を実行> するのに十分な <リソース> がありません
- <主語> には、<目的> に必要な <オブジェクト名> がありません
- <デバイスまたは設定> がオフになっているため、<予期しない結果> になります
- <デバイスまたは設定> が <利用できません | 見つかりません | オンになっていません | 有効になっていません>
- "<オブジェクト名>" は現在利用できません
- ユーザー名またはパスワードが正しくありません
- "<オブジェクト名>" へのアクセス許可がありません
- <動作を実行> する権限がありません
- <プログラム名> で重大な問題が発生したため、直ちに終了する必要があります
文法的に正しく、ガイドラインに従う限り、必要に応じてメイン指示テキストのテンプレートを変更してかまいません。
補足指示テキスト
- 補足指示テキストは次の用途に使用します。
- 問題に関する追加情報を提供する。
- 問題の原因を説明する。
- 問題を解決するための手順を列挙する。
- 問題の再発を未然に防ぐための対策を提供する。
- ユーザーが問題を解決できるように、可能な限り、実用的で有益な解決策を提供します。ただし、解決の見込みが十分にある解決策を示すようにしてください。解決につながる見込みの低い、憶測だけの情報でユーザーに無駄な時間をとらせないようにします。
間違った例:
この例で問題に対して推奨されている解決策は、うまくいく可能性もありますが、決して有望な方法ではありません。
- ユーザーの入力内容に誤りがあることが問題となっている場合は、補足指示テキストを使用して、正しい値について説明します。他の資料を参照しなければ原因が究明できないということのないようにします。
- 問題を示す文から容易に解決方法がわかる場合は、解決策は提供しません。
この例では、解決策が問題を示す文から容易に推測できるため、補足指示テキストは不要です。
- 解決策に複数の手順が含まれる場合は、その順に記述します。ただし、多くても 2 つか 3 つの手順に収めないと、記憶するのが困難になります。その意味で、複数の手順から成る解決策はできるだけ避けてください。多くの手順が必要となる場合は、適切なヘルプ トピックへのリンクを提供します。
- 補足指示テキストは簡潔にします。ユーザーが知る必要のある情報だけを提供します。不要な情報は省略します。適度な長さの文を最大 3 つで収めることを目標にします。
- 文の流れに従って操作した結果、予期せぬ事態に陥るということのないよう、操作よりも結果を先に記述します。
正しい例:
Windows を再起動するには、[OK] をクリックします。間違った例:
[OK] をクリックして Windows を再起動します。間違った例では、ユーザーが結果を認識する前に [OK] をクリックしてしまう可能性があります。
- 他に解決策がない場合を除き、管理者への問い合わせは提案しません。このような解決策は、本当に管理者以外に解決できない問題の場合にのみ採用します。
間違った例:
この例では、ユーザーのネットワーク接続に原因がある可能性が高く、管理者に問い合わせるほどの問題ではありません。
- テクニカル サポートへの問い合わせは提案しません。テクニカル サポートに問い合わせて問題を解決するという選択肢はいつでも利用できます。エラー メッセージを通じて促す必要はありません。むしろ、ユーザーがテクニカル サポートに頼らずに問題を解決できるような、有益なエラー メッセージを作成することを目指します。
間違った例:
テクニカル サポートへの問い合わせを提案する不適切なエラー メッセージの例です。
- 文を使用し、末尾に句点を付けます。センテンス スタイルの大文字化を使用します。
コミット ボタン
- 問題を解決するためのコマンド ボタンまたはコマンド リンクをエラー メッセージに設ける場合は、それぞれのガイドラインに従います (「ダイアログ ボックス」を参照)。
- エラーが発生したためプログラムを終了しなければならない場合は、[終了] プログラム ボタンを提供します。混乱を避けるために、このような場合に [閉じる] ボタンは使用しません。
- それ以外の場合は、[閉じる] ボタンを使用します。エラー メッセージに [OK] ボタンは使用しないでください。問題を容認するような印象を与えてしまいます。
- 例外: 使用するエラー報告メカニズムで、固定のラベルとして [OK] ボタンがある場合は (ErrorMessage API など)、[OK] ボタンを使用してもかまいません。
ドキュメント
エラーに言及するときは、以下のことに留意します。
- エラーは、メイン指示テキストで示します。メイン指示テキストが長い、または詳細な場合は、内容を要約します。
- 必要に応じて、エラー メッセージ ダイアログ ボックスを "メッセージ" と呼ぶこともできます。プログラミングやその他の技術文書内でのみ、"エラー メッセージ" と呼びます。
- テキストを二重引用符 (" ") で囲み、可能な場合は太字にします。
例: "ドライブに CD ディスクが挿入されていません" というメッセージが表示された場合は、新しい CD ディスクをドライブに挿入して、もう一度やり直してください。