Windows 7 のエラー メッセージ

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

の名前を変更できません

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

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

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

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

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

決定するには、次の質問を検討してください。

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

設計の概念

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

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

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

不要なエラー メッセージ を する

不正解:

に失敗しました

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

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

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

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

"Success" エラー メッセージを

不正解:

エラー メッセージの

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

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

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

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

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

不正解:

エラー メッセージの

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

問題: エラー メッセージに特定の問題が発生せず、ユーザーが問題を解決することはできません。

主な原因: 最も可能性の高いプログラムは、エラー処理が不十分です。

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

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

不正解:

この例では、問題の記述は明確ですが、補足的な説明は完全に困惑しています。

問題: 問題の説明または解決策は理解できません。

主な原因: ユーザーの代わりにコードの観点から問題を説明します。

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

をオーバーコミュニケーションするエラー メッセージを する

不正解:

非常に詳細なメッセージscreen shot of extremely verbose message のスクリーン ショット

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

問題: 情報が多すぎます。

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

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

不必要に厳しいエラー メッセージを

不正解:

メッセージの が見つかりません

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

問題: プログラムのトーンは不必要に厳しいか劇的です。

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

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

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

不正解:

メッセージの

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

問題: エラー メッセージは、ユーザーがエラーを発生させるような表現で表現されます。

主な原因: 問題の代わりにユーザーの動作に焦点を当てた非依存フレージング。

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

silly エラー メッセージ を する

不正解:

この例では、問題の記述は非常に皮肉であり、解決策は提供されていません。

問題: ばかげたか、または非セキテーターであるエラー メッセージ ステートメント。

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

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

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

不正解:

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

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

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

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

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

不正解:

メッセージの

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

問題: エラーメッセージのプレゼンテーションで間違ったすべての詳細を取得します。

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

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

良好なエラー メッセージの特性

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

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

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

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

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

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

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

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

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

不正解:

メッセージの を削除できません

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

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

不正解:

を完了できません

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

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

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

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

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

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

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

必要なエラー メッセージ を提供する

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

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

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

不正解:

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

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

優れたエラー処理 の設計

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

不正解:

メッセージの

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

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

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

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

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

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

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

不正解:

正解:

の原因を示す 3 つのメッセージの図

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

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

不正解:

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

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

正解:

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

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

不明なエラー を処理する

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

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

不明なエラーを抑制できない場合は、情報の不足を前もって確認することをお勧めします。

一方、ほとんどの場合に役立つ可能性がある場合は、具体的で実用的な情報を提供します。

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

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

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

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

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

エラー メッセージの表示

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

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

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

している操作を停止する

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

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

の過剰な通信を避ける

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

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

不正解:

詳細メッセージscreen shot of verbose message のスクリーン ショット

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

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

正解:

メッセージの

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

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

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

8つのことしかやらないと

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

使用パターン

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

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

ガイドライン

プレゼンテーション

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

ユーザー入力エラー

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

不正解:

スピーカーの音量ラベルがscreen shot of text box with speaker volume label されたテキスト ボックスのスクリーン ショットをする

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

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

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

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

メッセージの

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

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

トラブルシューティング

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

アイコン

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

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

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

    

    メッセージ コンピューター名が長すぎるscreen shot of message computer name too longのスクリーン ショット

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

    メッセージの電話番号の

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

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

  を再生できない

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

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

  不正解:

  のスクリーン ショット

  この例では、警告アイコンが誤って使用され、エラーの重大度が低下します。

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

段階的な開示

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

にログオンできません

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

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

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

このメッセージをもう一度表示しない

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

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

既定値

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

ヘルプ

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

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

エラー コード

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

不正解:

を開くことができません

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

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

正解:

1234

0xC0001234

不正解:

-1

-67113524

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

を初期化しませんでした

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

音

• サウンドエフェクトやビープ音でエラーメッセージを添付しないでください。 そうすることは、厄除けで不要です。
  • 例外: 問題がコンピュータの操作に不可欠であり、ユーザーが重大な結果を防ぐために直ちに行動する必要がある場合は、クリティカルストップサウンドエフェクトを再生します。

テキスト

全般

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

不正解:

メッセージの

正解:

の受信中

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

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

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

不正解:

正解:

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

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

不正解:

を入力したメッセージのスクリーン ショット

正解:

が正しくありません

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

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

不正解:

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

ディスクがいっぱいです。

範囲外の値。

文字が無効です。

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

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

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

正解:

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

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

正解:

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

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

不正解:

正解:

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

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

正解:

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

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

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

タイトルの

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

不正解:

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

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

の主な手順

• 主な指示を使用して、明確でわかりやすい特定の言語で問題を説明します。
• 簡潔に、完全な文を 1 つだけ使用してください。 主要な指示を重要な情報に絞り込みます。 対象がプログラムまたはユーザーの場合は、暗黙的なままにすることができます。 簡潔にできる場合は、問題の理由を含めてください。 さらに説明する必要がある場合は、補足命令を使用します。

不正解:

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

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

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

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

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

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

主な命令テンプレート

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

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

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

補足手順

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

不正解:

メッセージの

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

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

メッセージの

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

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

正解:

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

不正解:

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

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

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

不正解:

メッセージの

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

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

不正解:

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

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

コミット ボタン

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

ドキュメンテーション

エラーを参照する場合:

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

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