Windows 7 のエラー メッセージ

Note

この設計ガイドは Windows 7 用に作成されており、新しいバージョンの Windows では更新されていません。 ガイダンスの多くは原則として適用されますが、プレゼンテーションと例には 現在の設計ガイダンスは反映されていません。

Windows 7 のエラー メッセージは、既に発生している問題をユーザーに警告します。 これに対し、警告メッセージは、将来問題を引き起こす可能性のある条件をユーザーに警告します。 エラー メッセージは、モーダル ダイアログ ボックス、インプレース メッセージ、通知、吹き出しを使用して表示できます。

一般的なモーダル エラー メッセージ。

有効なエラー メッセージは、問題が発生したことをユーザーに通知し、問題が発生した理由を説明し、ユーザーが問題を解決できるように解決策を提供します。 ユーザーは、エラー メッセージの結果としてアクションを実行するか、動作を変更する必要があります。

適切に記述された便利なエラー メッセージは、高品質のユーザー エクスペリエンスにとって非常に重要です。 エラー メッセージの書き込みが不十分な場合、製品の満足度が低くなります。これは、回避可能なテクニカル サポート コストの主な原因です。 不要なエラー メッセージがユーザーのフローを中断します。

メモ：ダイアログ ボックス、警告メッセージ、確認、標準アイコン、通知、レイアウトに関連するガイドラインは、別の記事で示されています。

これは適切なユーザー インターフェイスですか?

それを判断するには、以下の質問を考えます。

• ユーザー インターフェイス (UI) が既に発生している問題を示していますか? そうでない場合、メッセージはエラーではありません。 ユーザーが将来問題を引き起こす可能性がある状態のアラートを受け取る場合は、警告メッセージを使用します。
• 混乱を引き起こさずに問題を防ぐことができますか? その場合は、代わりに問題を回避してください。 たとえば、エラー メッセージを必要とする可能性がある制約のないコントロールを使用する代わりに、有効な値に制限されたコントロールを使用します。 また、クリック時にコントロールを無効にすると、コントロールが無効になっている理由が明らかである限り、エラーが発生します。
• 問題は自動的に修正できますか? その場合は、問題を処理し、エラー メッセージを抑制します。
• ユーザーは、メッセージの結果としてアクションを実行したり、動作を変更したりする可能性がありますか? そうでない場合、条件はユーザーの中断を正当化しないため、エラーを抑制することをお勧めします。
• ユーザーが他のプログラムを積極的に使用している場合、問題は関連していますか? その場合は、 通知領域アイコンを使用して問題を表示することを検討してください。
• 問題は現在のユーザー アクティビティに関連せず、即時のユーザー アクションを必要とせず、ユーザーは自由に無視できますか? その場合は、代わりに アクションエラー通知 を使用してください。
• この問題は、プライマリ ウィンドウ内のバックグラウンド タスクの状態に関連していますか? その場合は、 ステータス バーを使用して問題を表示することを検討してください。
• 主要なターゲット ユーザーは IT プロフェッショナルですか? その場合は、 ログ ファイル エントリや電子メール アラートなどの代替フィードバック メカニズムを使用することを検討してください。 IT プロフェッショナルは、重要でない情報に対してログ ファイルを強く優先します。

設計概念

不適切なエラー メッセージの特性

迷惑な、役に立たない、書き込みが不十分なエラーメッセージが多数あることは驚くべきではありません。 また、エラー メッセージはモーダル ダイアログを使用して表示されることが多いため、ユーザーの現在のアクティビティが中断され、ユーザーの続行を許可する前に確認される要求が中断されます。

問題の一部は、それを間違って行う方法が非常に多いということです。 羞恥のエラー メッセージ ホールから次の例を考えてみましょう。

不要なエラー メッセージ

正しくない:

Windows XP からのこの例は、これまでで最悪のエラー メッセージである可能性があります。 Windows 自体がシャットダウン中であるため、プログラムを起動できなかったことを示します。 ユーザーがこれについて何もできないか、あるいはこれについてやりたいと思っています(ユーザーは結局Windowsをシャットダウンすることを選択しました)。 また、このエラー メッセージを表示することで、Windows はシャットダウンを防ぎます。

問題を： エラー メッセージ自体が問題です。 エラー メッセージを無視する以外に、ユーザーが行う必要はありません。

主な原因: ユーザーの目標や視点に関係なく、すべてのエラー ケースを報告します。

推奨される代替手段: ユーザーが気にしないエラーを報告しないでください。

"成功" エラー メッセージ

正しくない:

このエラーメッセージは、ユーザーがプログラムの削除直後にWindowsを再起動しないことを選択した結果として発生しました。 プログラムの削除は、ユーザーの観点から正常に行われました。

問題を： ユーザーの観点からエラーはありません。 エラー メッセージを無視する以外に、ユーザーが行う必要はありません。

主な原因: タスクはユーザーの観点から正常に完了しましたが、アンインストール プログラムの観点からは失敗しました。

推奨される代替手段: ユーザーが許容できる条件のエラーを報告しないでください。

完全に役に立たないエラー メッセージ

正しくない:

ユーザーはエラーが発生したことを知っていますが、エラーが何であったのか、何をすべきかは分かりません。 そして、いいえ、それは大丈夫ではありません!

問題を： エラー メッセージは特定の問題を与えるので、ユーザーはそれについて何もできません。

主な原因: ほとんどの場合、プログラムのエラー処理が不十分です。

推奨される代替手段: プログラムに適切なエラー処理を設計します。

理解できないエラー メッセージ

正しくない:

この例では、問題ステートメントは明確ですが、補足的な説明は完全に困惑しています。

問題を： 問題のステートメントまたは解決策は理解できません。

主な原因: ユーザーではなくコードの観点から問題を説明する。

推奨される代替手段: ターゲット ユーザーが簡単に理解できるエラー メッセージ テキストを記述します。 ユーザーが実際に実行できるソリューションを提供します。 プログラマがその場でエラー メッセージを作成しないように、プログラムのエラー メッセージ エクスペリエンスを設計します。

過剰に発生するエラー メッセージ

正しくない:

この例では、エラー メッセージは明らかにすべてのトラブルシューティング手順の説明を試みます。

問題を： 情報が多すぎます。

主な原因: 詳細が多すぎるか、エラー メッセージ内で複雑なトラブルシューティング プロセスを説明しようとしています。

推奨される代替手段: 不要な詳細を避けます。 また、トラブルシューティング ツールは避けてください。 トラブルシューティング ツールが必要な場合は、最も可能性の高い解決策に焦点を当て、ヘルプの適切なトピックにリンクして残りの部分について説明します。

不必要に過酷なエラー メッセージ

正しくない:

プログラムがオブジェクトを見つけることができないことはほとんど致命的に聞こえない。 そして、それが壊滅的であると仮定すると、なぜ応答はOKなのでしょうか?

問題を： プログラムのトーンは不必要に過酷または劇的です。

主な原因: この問題は、プログラムの観点から致命的に見えるバグが原因です。

推奨される代替手段: ユーザーの視点に基づいて言語を慎重に選択します。

ユーザーを非難するエラー メッセージ

正しくない:

なぜユーザーが犯罪者のように感じるのですか?

問題を： エラー メッセージは、ユーザーがエラーを犯したと非難する方法で表現されます。

主な原因: 問題の代わりにユーザーの動作に焦点を当てた、無神経な言い回し。

推奨される代替手段: 必要に応じてパッシブ音声を使用して、問題の原因となったユーザー アクションではなく、問題に焦点を当てます。

Silly エラー メッセージ

正しくない:

この例では、問題ステートメントは非常に皮肉であり、解決策は提供されていません。

問題を： 愚かまたは非セキテーターであるエラー メッセージ ステートメント。

主な原因: コンテキストに注意を払わずにエラー メッセージを作成する。

推奨される代替手段: ライターによって作成および確認されたエラー メッセージを表示します。 エラーを確認するときは、コンテキストとユーザーの心の状態を考慮してください。

プログラマーのエラー メッセージ

正しくない:

この例では、エラー メッセージはプログラムにバグがあることを示しています。 このエラー メッセージはプログラマにとってのみ意味があります。

問題を： プログラムの開発者がバグを見つけるのに役立つメッセージは、プログラムのリリース バージョンに残されています。 これらのエラー メッセージは、ユーザーにとって意味も価値もありません。

主な原因: 通常の UI を使用して自分にメッセージを送信するプログラマ。

推奨される代替手段: 開発者は、製品のリリース バージョンから自動的に削除されるように、このようなすべてのメッセージを条件付きでコンパイルする必要があります。 ユーザーだけがプログラマであるため、このようなエラーをユーザーが理解できるようにしようと時間を無駄にしないでください。

表示が不十分なエラー メッセージ

正しくない:

この例では、多くの一般的なプレゼンテーションの間違いがあります。

問題を： エラー メッセージのプレゼンテーションですべての詳細が間違っている。

主な原因: エラー メッセージのガイドラインを知らず、適用する。 ライターとエディターを使用してエラー メッセージを作成および確認しない。

エラー処理の性質は、これらの間違いの多くが非常に簡単に行えるようにすることです。 ほとんどのエラーメッセージが羞恥のホールの指名者である可能性があることに気づくのは不安です。

適切なエラー メッセージの特性

前の悪い例とは対照的に、適切なエラー メッセージには次があります。

• 問題。 問題が発生したことを示します。
• 原因。 問題が発生した理由について説明します。
• ソリューション ユーザーが問題を解決できるようにソリューションを提供します。

さらに、次の方法で適切なエラー メッセージが表示されます。

• 関連。 このメッセージは、ユーザーが気にする問題を示します。
• 実用的。 ユーザーは、アクションを実行するか、メッセージの結果として動作を変更する必要があります。
• ユーザー中心。 メッセージには、コードが不満を持つものではなく、ターゲット ユーザーのアクションまたは目標の観点から問題が記述されています。
• 短い。 メッセージはできるだけ短くなりますが、短くはありません。
• [クリア] を選択します。 メッセージでは、ターゲット ユーザーが問題と解決策を簡単に理解できるように、プレーンな言語が使用されます。
• 特定。 このメッセージは、特定の言語を使用して問題を説明し、関連するオブジェクトの特定の名前、場所、および値を指定します。
• 礼儀正しくします。 ユーザーが非難されたり、愚かな気持ちになったりしてはいけません。
• まれ。 まれに表示されます。 頻繁に表示されるエラー メッセージは、不適切なデザインの兆候です。

これらの特性を持つようにエラー処理エクスペリエンスを設計することで、プログラムのエラー メッセージをエラー メッセージの羞恥のホールから除外できます。

不要なエラー メッセージの回避

多くの場合、最適なエラー メッセージはエラー メッセージでありません。 設計を改善することで多くのエラーを回避でき、多くの場合、エラー メッセージの代わりに優れた方法があります。 通常は、エラーを報告するよりもエラーを防ぐ方が良いです。

回避する最も明白なエラー メッセージは、操作できないエラー メッセージです。 ユーザーが何もせずにメッセージを無視する可能性がある場合は、エラー メッセージを省略します。

一部のエラー メッセージは、ユーザーの観点から問題ではないので排除できます。 たとえば、ユーザーが既に削除中のファイルを削除しようとしたとします。 これは、コードの観点からは予期しないケースである可能性もありますが、ユーザーは望ましい結果が得られるので、このエラーは考慮しません。

正しくない:

このエラー メッセージは、ユーザーの観点からアクションが成功したため排除する必要があります。

別の例として、ユーザーがタスクを明示的に取り消したとします。 ユーザーの観点では、次の条件はエラーではありません。

正しくない:

このエラー メッセージは、ユーザーの観点からアクションが成功したため、削除する必要もあります。

場合によっては、テクノロジではなくユーザーの目標に重点を置くことで、エラー メッセージを排除できます。 その際に、エラーが実際に何であるかを再検討します。 ユーザーの目標、またはそれらを満たすプログラムの能力に問題がありますか? 実際の世界でユーザーの行動が理にかなっている場合は、ソフトウェアでも理にかなっているはずです。

たとえば、eコマース プログラム内で、ユーザーが検索を使用して製品を検索しようとしたときに、リテラル検索クエリに一致するものがなく、目的の製品が在庫切れであるとします。 技術的には、これはエラーですが、エラー メッセージを表示する代わりに、プログラムは次の操作を行うことができます。

• 引き続き、クエリに最も近い製品を検索します。
• 検索に明らかな間違いがある場合は、修正されたクエリを自動的に推奨します。
• スペル ミス、代替スペル、複数形化と動詞ケースの不一致などの一般的な問題を自動的に処理します。
• 製品が在庫になるタイミングを示します。

ユーザーの要求が妥当である限り、適切に設計された e コマース プログラムは、エラーではなく合理的な結果を返す必要があります。

エラー メッセージを回避するもう 1 つの優れた方法は、最初に問題を防ぐことです。 次の方法でエラーを回避できます。

• 制約付きコントロールの使用。 有効な値に制限されているコントロールを使用します。 リスト、スライダー、チェック ボックス、ラジオ ボタン、日付と時刻の選択などのコントロールは有効な値に制限されますが、テキスト ボックスは多くの場合、エラー メッセージを必要とせず、必要になる場合があります。 ただし、テキスト ボックスを制限して、特定の文字のみを受け入れ、最大文字数を受け入れることもできます。
• 制約付き相互作用の使用。 ドラッグ操作の場合は、ユーザーが有効なターゲットにのみドロップできるようにします。
• 無効なコントロールとメニュー項目の使用。 ユーザーがコントロールまたはメニュー項目が無効になっている理由を簡単に推測できる場合は、コントロールとメニュー項目を無効にします。
• 適切な既定値を指定します。 ユーザーが既定値を受け入れる場合、入力エラーが発生する可能性は低くなります。 ユーザーが値を変更する場合でも、既定値を使用すると、ユーザーは期待される入力形式を知ることができます。
• モノを動かすだけで済む。 タスクが不要な場合や、タスクに対して自動的に実行された場合、ユーザーが間違いを犯す可能性は低くなります。 または、ユーザーが小さな間違いを犯しても、その意図が明確な場合、問題は自動的に修正されます。 たとえば、小さな書式設定の問題を自動的に修正できます。

必要なエラー メッセージの提供

場合によっては、実際にエラー メッセージを提供する必要があります。 ユーザーが間違いを犯し、ネットワークとデバイスが動作しなくなったり、オブジェクトが見つからない、変更されたり、タスクが完了したり、プログラムにバグが発生したりします。 理想的には、これらの問題は発生頻度が低くなります。たとえば、多くの種類のユーザーミスを防ぐためにソフトウェアを設計できますが、これらの問題をすべて防ぐのは現実的ではありません。 また、これらの問題のいずれかが発生すると、役に立つエラー メッセージが表示され、ユーザーはすぐに足に戻ります。

一般的な考え方は、エラー メッセージは最悪のユーザー エクスペリエンスであり、すべてのコストで回避する必要があるということですが、ユーザーの混乱は最悪のエクスペリエンスであり、すべてのコストで回避する必要があると言う方が正確です。 場合によっては、そのコストが役に立つエラー メッセージです。

無効なコントロールを検討してください。 ほとんどの場合、コントロールが無効になっている理由は明らかです。そのため、コントロールを無効にすることは、エラー メッセージを回避するための優れた方法です。 ただし、コントロールが無効になっている理由が明らかでない場合はどうなりますか? ユーザーは続行できません。問題を特定するためのフィードバックはありません。 これでユーザーが停止し、問題を推測するか、テクニカル サポートを受ける必要があります。 このような場合は、コントロールを有効のままにして、代わりに役立つエラー メッセージを表示することをお勧めします。

正しくない:

[次へ] ボタンが無効になっているのはなぜですか? 有効のままにしておき、役に立つエラー メッセージを表示してユーザーの混乱を回避することをお勧めします。

エラー メッセージを表示する必要があるかどうかがわからない場合は、まず、指定する可能性があるエラー メッセージを作成します。 ユーザーがアクションを実行するか、その結果として動作を変更する可能性がある場合は、エラー メッセージを入力します。 これに対し、ユーザーが何もせずにメッセージを無視する可能性がある場合は、エラー メッセージを省略します。

適切なエラー処理のための設計

適切なエラー メッセージ テキストの作成は困難な場合もありますが、プログラムからの適切なエラー処理のサポートがなければ不可能な場合があります。 次のエラー メッセージを考えてみましょう。

正しくない:

プログラムのエラー処理のサポートが不足しているため、問題は本当に不明である可能性があります。

これは非常に不適切に記述されたエラー メッセージである可能性がありますが、基になるコードによる適切なエラー処理の欠如を反映している可能性が高く、問題に関する特定の情報はありません。

特定の操作可能なユーザー中心のエラー メッセージを作成するには、プログラムのエラー処理コードで、特定の高レベルのエラー情報を提供する必要があります。

• 各問題には、一意のエラー コードが割り当てられている必要があります。
• 問題に複数の原因がある場合、プログラムは可能な限り特定の原因を特定する必要があります。
• 問題にパラメーターがある場合は、パラメーターを維持する必要があります。
• ユーザーの観点からエラー メッセージを表示できるように、低レベルの問題を十分に高いレベルで処理する必要があります。

適切なエラー メッセージは、単なる UI の問題ではない、ソフトウェア設計の問題です。 適切なエラー メッセージ エクスペリエンスは、後で取り組むことができるものではありません。

トラブルシューティング (および回避する方法)

複数の異なる原因に関する問題が 1 つのエラー メッセージで報告された場合のトラブルシューティングの結果。

正しくない:

正確:

1 つのエラー メッセージで複数の問題が報告された場合のトラブルシューティングの結果。

次の例では、アイテムが既に移動または削除されたか、アクセスが拒否されたため、アイテムを移動できませんでした。 プログラムが原因を簡単に特定できる場合、特定の原因を特定するためにユーザーに負担をかけるのはなぜですか?

正しくない:

さて、それはどれですか? 次に、ユーザーはトラブルシューティングを行う必要があります。

プログラムはアクセスが拒否されたかどうかを判断できるため、この問題は特定のエラー メッセージで報告する必要があります。

正確:

特定の原因により、トラブルシューティングは必要ありません。

特定の原因を特定できない場合にのみ、複数の原因でメッセージを使用します。 この例では、項目が移動または削除されたかどうかをプログラムが判断するのが難しいため、複数の原因を含む 1 つのエラー メッセージがここで使用される可能性があります。 ただし、削除されたファイルを移動できなかった場合など、ユーザーが気にする可能性は低いです。 これらの原因では、エラー メッセージは必要ありません。

不明なエラーの処理

場合によっては、問題、原因、または解決策を本当に知りません。 エラーを抑制するのが賢明でない場合は、正しくない可能性のある問題、原因、または解決策を提示するよりも、情報の不足を前もって把握することをお勧めします。

たとえば、プログラムにハンドルされない例外がある場合は、次のエラー メッセージが適しています。

不明なエラーを抑制できない場合は、情報の不足を前面に出す方が良いです。

一方、ほとんどの場合に役立つ可能性が高い場合は、具体的で実用的な情報を提供してください。

このエラー メッセージは、ネットワーク接続が通常問題である場合、不明なエラーに適しています。

適切なメッセージの種類を決定する

一部の問題は、強調と言い回しに応じて、エラー、警告、または情報として表示されます。 たとえば、Web ページが現在の Windows インターネット エクスプローラー構成に基づいて署名されていない ActiveX コントロールを読み込めないとします。

• エラー。 "このページでは、署名されていない ActiveX コントロールを読み込めません。"(既存の問題として表現されます。
• 警告。 "Windows インターネット エクスプローラーが署名されていない ActiveX コントロールを読み込むよう構成されていないため、このページは期待どおりに動作しない可能性があります。"このページに署名されていない ActiveX コントロールのインストールを許可しますか? 信頼されていないソースからこれを行うと、コンピューターに損害を与える可能性があります。(どちらも、将来の問題を引き起こす可能性のある条件として表現されています。
• 情報。 "署名されていない ActiveX コントロールをブロックするように Windows インターネット エクスプローラーを構成しました。"(ファクトのステートメントとして表現されます。

適切なメッセージの種類を特定するには、ユーザーが知る必要がある、または対処する必要がある問題の最も重要な側面に焦点を当てます。 通常、問題によってユーザーの続行がブロックされた場合は、エラーとして提示する必要があります。ユーザーが続行できる場合は、警告として提示します。 そのフォーカスに基づいてメイン命令またはその他の対応するテキストを作成し、テキストに一致するアイコン (標準またはそれ以外の場合) を選択します。 メイン命令のテキストとアイコンは常に一致する必要があります。

エラー メッセージの表示

Windows プログラムのほとんどのエラー メッセージは、モーダル ダイアログ ボックス (この記事のほとんどの例と同様) を使用して表示されますが、他のオプションもあります。

• インプレース
• バルーン
• 通知
• 通知領域アイコン
• ステータス バー
• ログ ファイル (IT プロフェッショナルを対象とするエラーの場合)

モーダル ダイアログ ボックスにエラー メッセージを配置すると、ユーザーの即時の注意と確認を要求できるという利点があります。 ただし、これは、その注意が必要ない場合の主な欠点でもあります。

ユーザーが [閉じる] ボタンをクリックできるように、ユーザーを中断する必要はありますか? そうでない場合は、モーダル ダイアログ ボックスを使用する代わりの方法を検討してください。

モーダル ダイアログは、ユーザーが問題を続行する直前に確認する必要がある場合に最適な選択肢ですが、多くの場合、そうでない場合は不適切な選択です。 一般に、ジョブを適切に実行する最も軽量なプレゼンテーションを使用する必要があります。

過剰通信を避ける

一般に、 ユーザーは読み取らない、スキャンする。 テキストが多いほど、テキストのスキャンが困難になり、ユーザーがテキストをまったく読まない可能性が高くなります。 その結果、テキストを必須事項まで減らし、必要に応じて段階的な開示とヘルプ リンクを使用して追加情報を提供することが重要です。

多くの極端な例がありますが、もう 1 つの一般的な例を見てみましょう。 次の例では、適切なエラー メッセージのほとんどの属性がありますが、そのテキストは簡潔ではなく、読む動機が必要です。

正しくない:

この例は適切なエラー メッセージですが、オーバーコミットします。

このテキストは本当に何を言っていますか? 次のようなものです。

正確:

このエラー メッセージには基本的に同じ情報がありますが、はるかに簡潔です。

ヘルプを使用して詳細を指定すると、このエラー メッセージには 逆ピラミッド形式 のプレゼンテーションが表示されます。

過剰通信に関するその他のガイドラインと例については、「 ユーザー インターフェイス テキスト」を参照してください。

8 つのことだけを行う場合

1. エラー処理用にプログラムを設計します。
2. 不要なエラー メッセージを表示しないでください。
3. 必要なエラー メッセージを表示して、ユーザーの混乱を避けます。
4. エラー メッセージに問題、原因、解決策が示されていることを確認します。
5. エラー メッセージが関連性があり、実用的で、簡潔で、明確で、具体的で、丁寧で、まれであることを確認します。
6. プログラムの観点ではなく、ユーザーの視点からのエラー メッセージを設計します。
7. トラブルシューティングにユーザーが関与しないようにするには、検出可能な原因ごとに異なるエラー メッセージを使用します。
8. ジョブを適切に実行する最も軽量のプレゼンテーション方法を使用します。

使用パターン

エラー メッセージには、いくつかの使用パターンがあります。

Label	値
システムの問題 オペレーティング システム、ハードウェア デバイス、ネットワーク、またはプログラムが失敗したか、タスクの実行に必要な状態ではありません。	多くのシステムの問題は、ユーザーが解決できます。 デバイスの問題は、デバイスをオンにし、デバイスを再接続し、メディアを挿入することで解決できます。 ネットワークの問題は、物理ネットワーク接続を確認し、 ネットワークの診断と修復を実行することで解決できます。 プログラムの問題は、プログラムのオプションを変更するか、プログラムを再起動することで解決できます。 この例では、プログラムでユーザー タスクを実行するカメラが見つかりません。 この例では、タスクを実行するために必要な機能をオンにする必要があります。
ファイルの問題 ユーザーによって開始されたタスクに必要なファイルまたはフォルダーが見つからないか、既に使用されているか、予期される形式ではありません。	この例では、ファイルまたはフォルダーが見つからなかったため、削除できません。 この例では、プログラムは指定されたファイル形式をサポートしていません。
セキュリティの問題 ユーザーには、リソースにアクセスするためのアクセス許可や、ユーザーによって開始されたタスクを実行するための十分な特権がありません。	この例では、ユーザーはリソースにアクセスするためのアクセス許可を持っていません。 この例では、ユーザーにはタスクを実行する権限がありません。
タスクの問題 ユーザーによって開始されたタスクの実行には、特定の問題があります (システム、ファイルが見つからない、ファイル形式、またはセキュリティの問題以外)。	この例では、クリップボード データをペイントに貼り付けることはできません。 この例では、ユーザーはソフトウェア アップグレードをインストールできません。
ユーザー入力の問題 ユーザーが、他のユーザー入力と間違っているか一貫性のない値を入力しました。	この例では、ユーザーが正しくない時刻値を入力しました。 この例では、ユーザー入力が正しい形式ではありません。

ガイドライン

プレゼンテーション

• 必要に応じてタスク ダイアログを使用 して、一貫した外観とレイアウトを実現します。 タスク ダイアログには Windows Vista 以降が必要であるため、以前のバージョンの Windows には適していません。 メッセージ ボックスを使用する必要がある場合は、メイン命令と補足命令を 2 行区切りで区切ります。

ユーザー入力エラー

• 可能な限り、次の方法でユーザー入力エラーを防止または減らします。
  • 有効な値に制約されているコントロールを使用する。
  • クリック時にコントロールとメニュー項目を無効にすると、コントロールまたはメニュー項目が無効になっている理由が明らかである限り、エラーが発生します。
  • 適切な既定値を指定します。

正しくない:

この例では、制約のないテキスト ボックスを制約付き入力に使用します。 代わりにスライダーを使用します。

• コンテキスト ユーザー入力の問題には、モードレス エラー処理 (インプレース エラーまたはバルーン) を使用します。
• テキスト ボックス内またはテキスト ボックスがフォーカスを失った直後に検出された、重要でない単一点ユーザー入力の問題にバルーンを使用します。バルーンには 、使用可能な画面領域や、インプレース メッセージを表示するために必要な動的レイアウトは必要ありません。 一度に 1 つのバルーンのみを表示します。 問題は重要ではないので、エラー アイコンは必要ありません。 バルーンは、クリックされたとき、問題が解決されたとき、またはタイムアウト後に消え去ります。

この例では、吹き出しは、コントロール内で入力の問題を示します。

• 遅延エラー検出にはインプレース エラーを使用 します。通常は、コミット ボタンをクリックして検出されたエラーです。 (すぐにコミットされる設定には インプレース エラー を使用しないでください。)一度に複数のインプレース エラーが発生する可能性があります。 通常のテキストと 16 x 16 ピクセルのエラー アイコンを使用して、可能な限り問題の横に配置します。 インプレース エラーは、ユーザーがコミットし、他のエラーが見つからない限り、消えません。

この例では、コミット ボタンをクリックして見つかったエラーに対してインプレース エラーを使用します。

• モーダル エラー処理 (タスク ダイアログまたはメッセージ ボックス) を使用して、 複数のコントロールに関連するエラーや、コミット ボタンをクリックして検出された非コンテキスト エラーまたは入力エラーなど、その他のすべての問題に対して使用します。
• ユーザー入力の問題が報告されたら、正しくないデータを含む最初のコントロールに入力フォーカスを設定します。 必要に応じて、コントロールをスクロールして表示します。 コントロールがテキスト ボックスの場合は、内容全体を選択します。 エラー メッセージが何を参照しているのかは、常に明確である必要があります。
• 正しくない入力をクリアしないでください。 代わりに、ユーザーが最初からやり直さずに問題を確認して修正できるように、そのままにします。
  • 例外： ユーザーがマスクされた入力を効果的に修正できないため、正しくないパスワードと PIN テキスト ボックスをクリアします。

トラブルシューティング

• トラブルシューティングの問題を作成しないでください。 複数の異なる検出可能な原因に関する問題を報告するために、1 つのエラー メッセージに依存しないでください。
• 検出可能な原因ごとに異なるエラー メッセージ (通常は異なる補足命令) を使用します。 たとえば、いくつかの理由でファイルを開くことができない場合は、理由ごとに個別の補足命令を指定します。
• 特定の原因を特定できない場合にのみ、複数の原因を含むメッセージを使用します。 この場合は、問題を解決する可能性の高い順に解決策を提示します。 これにより、ユーザーは問題をより効率的に解決できます。

アイコン

• モーダル エラー メッセージ ダイアログにはタイトル バー アイコンがありません。 タイトル バー アイコンは、プライマリ ウィンドウとセカンダリ ウィンドウの視覚的な区別として使用されます。

• エラー アイコンを使用します。 例外:

  • エラーがモーダル ダイアログ ボックスまたはバルーンを使用して表示されるユーザー入力の問題である場合は、アイコンを使用しないでください。 これは、Windows の励ましのトーンに反します。 ただし、インプレース エラー メッセージでは、小さなエラー アイコン (16 x 16 ピクセル) を使用して、エラー メッセージとして明確に識別する必要があります。

    

    

    これらの例では、ユーザー入力の問題にエラー アイコンは必要ありません。

    

    この例では、インプレース エラー メッセージには、エラー メッセージとして明確に識別するための小さなエラー アイコンが必要です。

• (ユーザー入力の問題ではなく) アイコンを持つ機能に問題がある場合は、機能アイコンをエラー オーバーレイと共に使用できます。 これを行う場合は、エラーの件名として機能名も使用します。

  

  この例では、機能アイコンにエラー オーバーレイがあり、機能がエラーの対象となります。

• エラーには警告アイコンを使用しないでください。 これは、多くの場合、プレゼンテーションの厳しさを軽減するために行われます。 エラーは警告ではない。

  正しくない:

  

  この例では、警告アイコンが誤って使用され、エラーの深刻さが軽減されます。

その他のガイドラインと例については、「 標準アイコン」を参照してください。

段階的表示

• [詳細の表示/非表示] プログレッシブ開示ボタンを使用して、エラー メッセージの詳細情報または詳細情報を非表示にします。 これにより、一般的な使用に関するエラー メッセージが簡略化されます。 ユーザーが見つけられない可能性があるため、必要な情報を非表示にしないでください。

この例では、プログレッシブ開示ボタンを使用すると、ユーザーが必要な場合は詳細にドリルダウンしたり、表示しない場合は UI を簡略化したりできます。

• 詳細が表示されない限り、詳細の表示/非表示は使用しないでください。 既存の情報をより詳細な形式で変更しないでください。
• [詳細の表示/非表示] を使用してヘルプ情報を表示しないでください。 代わりにヘルプ リンクを使用してください。

ラベル付けのガイドラインについては、「 プログレッシブ開示コントロール」を参照してください。

このメッセージを再度表示しない

• エラー メッセージにこのオプションが必要な場合は、エラーとその頻度を再考します。 適切なエラーのすべての特性 (関連、操作可能、頻度が低い) がある場合、ユーザーがそれを抑制することは意味がありません。

その他のガイドラインについては、「 ダイアログ ボックス」を参照してください。

既定値

• 既定として、最も安全、最も破壊的、または最も安全な応答を選択します。 安全性が要因ではない場合は、最も可能性の高いコマンドまたは便利なコマンドを選択します。

ヘルプ

• ヘルプの必要性を避けるために、エラー メッセージを設計します。 通常、ソリューションに複数の手順が必要な場合を除き、ユーザーは問題を理解して解決するために外部テキストを読む必要はありません。
• ヘルプ コンテンツが関連性があり、役立っていることを確認します。 これは、エラー メッセージの詳細な再表示ではなく、将来の問題を回避する方法など、エラー メッセージの範囲を超えた有用な情報を含める必要があります。 可能な理由だけでヘルプ リンクを提供しないでください。
• 特定の簡潔で関連性の高いヘルプ リンクを使用して、ヘルプ コンテンツにアクセスします。 この目的では、コマンド ボタンやプログレッシブ開示を使用しないでください。
• 特定の操作を可能にできないエラー メッセージについては、オンライン ヘルプ コンテンツへのリンクを提供することを検討してください。 これにより、プログラムのリリース後に更新できる追加情報をユーザーに提供できます。

その他のガイドラインについては、「 ヘルプ」を参照してください。

エラー コード

• 具体的で実用的にできないエラー メッセージや、ヘルプの恩恵を受けるエラー メッセージについては、エラー コードの提供も検討してください。 ユーザーは、多くの場合、これらのエラー コードを使用して、インターネットで追加情報を検索します。
• 常に、問題と解決策の説明をテキストで指定します。 この目的のエラー コードだけに依存しないでください。

正しくない:

この例では、ソリューション テキストの代わりにエラー コードが使用されます。

• 異なる原因ごとに一意のエラー コードを割り当てます。 これにより、トラブルシューティングが回避されます。
• インターネットで簡単に検索できるエラー コードを選択します。 32 ビット コードを使用する場合は、先頭に "0x" と大文字を含む 16 進数表現を使用します。

正確:

1234

0xC0001234

正しくない:

-1

-67113524

• [詳細の表示/非表示] を使用してエラー コードを表示します。 エラー コードとしてのフレーズ: <error code>。

この例では、エラー コードを使用して、詳細情報を利用できるエラー メッセージを補完します。

サウンド

• サウンド効果やビープ音でエラー メッセージを添付しないでください。 そうすることは耳障りで不要です。
  • 例外： 問題がコンピューターの操作に重要であり、ユーザーが重大な結果を防ぐために直ちにアクションを実行する必要がある場合は、重大な停止サウンド効果を再生します。

Text

全般

• 冗長なテキストを削除します。 タイトル、メイン命令、補足命令、コマンド リンク、コミット ボタンで探します。 一般に、命令と対話型コントロールにフルテキストを残し、他の場所から冗長性を削除します。
• ユーザー中心の説明を使用します。 ソフトウェアが何に不満を持っているかではなく、ユーザーの行動や目標の観点から問題を説明します。 ターゲット ユーザーが理解して使用する言語を使用します。 技術的な専門用語は避けてください。

正しくない:

正確:

これらの例では、正しいバージョンはユーザーの言語を話しますが、正しくないバージョンは過度に技術的です。

• 次の単語は使用しないでください。
  • エラー、エラー (代わりに問題を使用)
  • に失敗しました (代わりに を使用できません)
  • 無効、無効、無効 (代わりに正しくない使用)
  • 中止、強制終了、終了 (代わりに stop を使用)
  • 致命的で致命的な (代わりに深刻な使用)

これらの用語は不要であり、Windows の励ましのトーンに反します。 正しく使用すると、エラー アイコンは問題があることを十分に伝えています。

正しくない:

正確:

正しくない例では、"致命的" と "失敗" という用語は不要です。

• ユーザーを非難したり、ユーザー エラーを意味したりする言い回しは使用しないでください。 言い回しであなたとを使用しないでください。 アクティブな音声は一般的に優先されますが、ユーザーが件名の場合はパッシブ音声を使用し、アクティブな音声が使用された場合にエラーの責任を感じる可能性があります。

正しくない:

正確:

正しくない例では、アクティブな音声を使用してユーザーの責任を負います。

• 具体的にする。 構文エラーや無効な操作など、あいまいな表現は避けてください。 関係するオブジェクトの特定の名前、場所、および値を指定します。

正しくない:

ファイルが見つかりません。

ディスクの空き容量が不足しています。

値が範囲外です。

文字が無効です。

デバイスを使用できません。

これらの問題は、特定の名前、場所、値で解決する方がはるかに簡単です。

• 特定の問題、原因、または解決策を提供しないようにしてください。 正しい可能性がある場合を除き、問題、原因、または解決策を提供しないでください。 たとえば、不正確になる可能性があるエラーよりも、不明なエラーが発生したと言う方が良いでしょう。
• ユーザーが不便な操作をするように求められたり (待機中など)、ソフトウェアが状況の責任を負う場合を除き、"please" という言葉は避けてください。

正確:

Windows がコンピューターにファイルをコピーするまで待ってください。

• "申し訳ありません" という単語は、ユーザーの重大な問題 (データの損失やコンピューターの使用不能など) につながるエラー メッセージでのみ使用します。 プログラムの正常な機能中に問題が発生した場合 (たとえば、ユーザーがネットワーク接続が見つかるのを待つ必要がある場合) は、申し訳ありません。

正確:

申し訳ございませんが、Fabrikam Backup で回復不可能な問題が検出され、コンピューター上のファイルを保護するためにシャットダウンされました。

• 短い名前を使用して製品を参照してください。 完全な製品名や商標記号は使用しないでください。 ユーザーが会社名を製品に関連付けない限り、会社名を含めないでください。 プログラムのバージョン番号は含めないでください。

正しくない:

正確:

正しくない例では、完全な製品名と商標記号が使用されています。

• オブジェクト名を二重引用符で囲みます。 これにより、テキストの解析が容易になり、潜在的に恥ずかしいステートメントを回避できます。
  • 例外： 完全修飾ファイル パス、URL、ドメイン名を二重引用符で囲む必要はありません。

正確:

この例では、オブジェクト名が引用符で囲まれていない場合、エラー メッセージは混乱します。

• オブジェクト名で文を始めないでください。 これを行うことは、多くの場合、解析が困難です。
• 感嘆符や単語をすべての大文字と共に使用しないでください。 感嘆符と大文字は、ユーザーに向かって叫んでいるように感じます。

その他のガイドラインと例については、「 スタイルとトーン」を参照してください。

タイトル

• タイトルを使用して、エラーの発生元のコマンドまたは機能を特定します。 例外:
  • さまざまなコマンドでエラーが表示される場合は、代わりにプログラム名を使用することを検討してください。
  • そのタイトルが冗長であるか、メイン命令と混同される場合は、代わりにプログラム名を使用してください。
• タイトルを使用して、メイン命令の目的である問題を説明したり要約したりしないでください。

正しくない:

この例では、タイトルを誤って使用して問題を説明しています。

• 句読点を終了せずに、タイトルスタイルの大文字を使用します。

主要な命令

• メイン命令を使用して、明確でプレーンな特定の言語で問題を説明します。
• 簡潔に、完全な文を 1 つだけ使用してください。 メイン命令を重要な情報に減らします。 サブジェクトは、プログラムまたはユーザーである場合は暗黙的なままにすることができます。 これを簡潔に行うことができる場合は、問題の理由を含めます。 さらに説明する必要がある場合は、補足命令を使用します。

正しくない:

この例では、エラー メッセージ全体がメイン命令に配置され、読みにくくなっています。

• 関係するオブジェクトがある場合は、名前を付けます。
• メイン命令に完全なファイル パスと URL を含めないでください。 代わりに、短い名前 (ファイル名など) を使用し、完全な名前 (ファイル パスなど) を補足命令に配置します。 ただし、エラー メッセージに補足命令が必要ない場合は、メイン命令に 1 つの完全なファイル パスまたは URL を配置できます。

この例では、ファイル名のみが メイン 命令に含まれています。 完全なパスは補足命令にあります。

• コンテキストから明らかな場合は、完全なファイル パスと URL をまったく指定しないでください。

この例では、ユーザーは Windows エクスプローラーからファイルの名前を変更しています。 この場合、コンテキストから明らかなため、完全なファイル パスは必要ありません。

• 可能な限り、現在の時制を使用します。
• 文章スタイルで大文字と小文字を使い分けます。
• 命令がステートメントの場合は、最後のピリオドを含めないでください。 指示が質問の場合は、最後の疑問符を含めます。

主な命令テンプレート

フレージングには厳密な規則はありませんが、可能な限り次のメイン命令テンプレートを使用してみてください。

• [オプションのサブジェクト名] で [アクションを実行] できない
• [省略可能なサブジェクト名] は [理由] のため [アクションを実行] できません
• [オプションのサブジェクト名] を [アクションを実行] から "[オブジェクト名]" にすることはできません
• [省略可能なサブジェクト名] [理由] のため、[アクションを実行] から "[オブジェクト名]" にすることはできません
• [アクションの実行] に十分な [リソース] がありません
• [サブジェクト名] には、[目的] に必要な [オブジェクト名] がありません
• [デバイスまたは設定] がオフになっているので、[望ましくない結果]
• [デバイスまたは設定] が [使用できない | 見つかりました | オン | 有効]
• "[オブジェクト名]" は現在使用できません
• ユーザー名またはパスワードが間違っている
• "[オブジェクト名]" にアクセスする権限がありません
• [アクションを実行する] 権限がありません
• [プログラム名] 重大な問題が発生したため、直ちに終了する必要があります

もちろん、メインの指示が文法的に正しく、メインの指示ガイドラインに準拠するように、必要に応じて変更を加えます。

補足説明

• 補足命令を使用して、次の操作を行います。
  • 問題に関する追加の詳細を指定します。
  • 問題の原因を説明します。
  • ユーザーが問題を解決するために実行できる手順を一覧表示します。
  • 問題が再発しないように対策を講じます。
• 可能な限り、ユーザーが問題を解決できるように、実用的で役立つソリューションを提案してください。 ただし、提案された解決策が問題を解決する可能性があることを確認してください。 可能だがあり得ない解決策を提案することで、ユーザーの時間を無駄にしないでください。

正しくない:

この例では、問題とその推奨される解決策が可能ですが、可能性は非常に低いです。

• 問題がユーザーが入力した正しくない値である場合は、補足命令を使用して正しい値を説明します。 ユーザーは、別のソースからこの情報を特定する必要はありません。
• 問題のステートメントから簡単に推測できる場合は、ソリューションを提供しないでください。

この例では、補足命令は必要ありません。この解決策は、問題ステートメントから簡単に推測できます。

• ソリューションに複数のステップがある場合は、ステップを完了する順序で提示します。 ただし、ユーザーは 2 つまたは 3 つ以上の簡単な手順を覚えにくいため、マルチステップ ソリューションは避けてください。 さらに手順が必要な場合は、適切なヘルプ トピックを参照してください。
• 補足命令は簡潔にしてください。 ユーザーが知る必要がある情報のみを指定します。 不要な詳細を省略します。 中程度の長さの最大 3 つの文を目指します。
• ユーザーが命令を実行するときに間違いを回避するには、アクションの前に結果を配置します。

正確:

Windows を再起動するには、[OK] をクリックします。

正しくない:

[OK] をクリックして Windows を再起動します。

正しくない例では、ユーザーは誤って [OK] をクリックする可能性が高くなります。

• 問題の最も可能性の高い解決策の 1 つでない限り、管理者に連絡することはお勧めしません。 管理者のみが解決できる問題に対して、このような解決策を予約します。

正しくない:

この例では、ユーザーのネットワーク接続に問題がある可能性が高いので、管理者に連絡する価値はありません。

• テクニカル サポートに連絡することはお勧めしません。 テクニカル サポートに問い合わせて問題を解決するオプションは常に利用可能であり、エラー メッセージを通じて昇格する必要はありません。 代わりに、ユーザーがテクニカル サポートに問い合わせることなく問題を解決できるように、役立つエラー メッセージを記述することに重点を置きます。

正しくない:

この例では、エラー メッセージがテクニカル サポートに連絡することを誤って推奨しています。

• 完全な文、文スタイルの大文字、終了句読点を使用します。

コミット ボタン

• エラー メッセージに問題を解決するコマンド ボタンまたはコマンド リンクが表示される場合は、「 ダイアログ ボックス」のそれぞれのガイドラインに従ってください。
• エラーの結果としてプログラムを終了する必要がある場合は、[プログラムの終了] ボタンを指定します。 混乱を避けるために、この目的には Close を使用しないでください。
• それ以外の場合は、[閉じる] ボタンを指定します。 エラー メッセージには [OK] を使用しないでください。これは、問題が問題であることを意味するためです。
  • 例外： エラー報告メカニズムに固定ラベルがある場合は、OK を使用します (MessageBox API の場合と同様)。

ドキュメント

エラーを参照する場合:

• メイン命令でエラーを参照してください。 メイン命令が長いか詳細な場合は、要約します。
• 必要に応じて、エラー メッセージ ダイアログ ボックスをメッセージとして参照できます。 プログラミングやその他の技術ドキュメントでのみ、エラー メッセージとしてを参照してください。
• 可能な場合は、太字を使用してテキストの書式を設定します。 それ以外の場合は、混乱を防ぐために必要な場合にのみ、テキストを引用符で囲みます。

例： ドライブ メッセージに CD ディスクがない場合は、ドライブに 新しい CD ディスクを挿入して、もう一度やり直してください。