確認

確認は、ユーザーがアクションを続行するかどうかを確認するモーダル ダイアログ ボックスです。

一般的な確認。

確認には、次の重要な特性があります。

• これらは、ユーザーによって開始されたアクションの直接の結果として表示されます。
• ユーザーがアクションを続行することを確認します。
• 単純な質問と 2 つ以上の回答で構成されます。

確認は、アクションでユーザーが後で行えない、関連性のある個別の選択を行う必要がある場合に最も役立ちます。 多くの場合、この選択には、ユーザーには明らかではないリスクの要素が含まれますが、リスクは確認に不可欠ではありません。 これらの要素は、モーダル ダイアログへの応答の中断を正当化するために必要です。

これに対し、警告メッセージ、将来問題を引き起こす可能性のある状態が示されます。 彼らの基本的な特徴は、リスクが伴うということです。

• これには、次の 1 つ以上の損失が発生する可能性があります。
  • データ損失や財務損失などの貴重な資産。
  • システム アクセスまたは整合性。
  • 機密情報のプライバシーまたは制御。
  • ユーザーの時間 (30 秒以上など、かなりの量)。
• 予期しない結果や意図しない結果が生じる。
• 間違いを簡単に修正できないし、元に戻せない可能性があるため、現在は正しい処理が必要です。

確認にリスクが含まれている場合は、警告と見なすことができます。 したがって、警告メッセージのガイドラインも適用されます。

注:ダイアログ ボックスの、エラー メッセージの、レイアウト、および 警告メッセージ に関連するガイドラインについては、別の記事で説明します。

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

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

• ユーザーは、2 つ以上の応答を持つアクションを続行するための質問を受けますか? そうでない場合、メッセージは確認ではありません。
• UI にエラーまたは発生した問題が表示されていますか? その場合は、代わりに エラー メッセージ を使用します。
• アクションを続行するには、適切な既定値がない選択をユーザーが行う必要がありますか? その場合は、確認が適切な場合があります。
• 確認の必要性を排除する代替設計はありますか? 確認が必要な場合は、設計上の欠陥を示している場合があります。 多くの場合、確認を必要としないより優れた設計の代替手段があります。
• ユーザーが危険なアクションを実行しようとしているか。 その場合、アクションに重大な影響がある場合、または簡単に元に戻すことができない場合は、確認が適切です。
• ユーザーはタスクを破棄しようとしているのですか? その場合は、確認しないでください。 ユーザーがタスクを完了しなかった場合の結果を理解しているとします。
• アクションには、ユーザーが認識していない可能性がある結果がありますか? その場合は、確認が適切な場合があります。
• 現在のコンテキストを考えると、ユーザーはエラーでアクションを実行している可能性がありますか? その場合は、確認が適切な場合があります。
• ユーザーはアクションを頻繁に実行しますか? その場合は、別の設計を検討してください。 ユーザーが考えずに応答することを学ぶので、頻繁な確認は迷惑であり、ほとんど価値がありません。
• このアクションはセキュリティに影響しますか? その場合は、前のテストでそうでないと示されている場合でも、確認が必要になることがあります。

設計の概念

不要な確認は迷惑です

これまでに作成された最初の Windows の確認は、間違いなく次のようになります。

のスクリーン ショット

元の迷惑な確認。

これは非常に悪いスタートでした。 ユーザーがプログラムを嫌う場合は、全体にこのような確認を振りかけるだけです。 その理由を理解するには、ユーザーの観点を考慮してください。 ユーザーは確認の定義によってアクションを実行するように求められたので、何らかの方法で何らかの方法でクリックまたは押された場合を除き、もちろんユーザーは続行したいと考えています。

不要な確認は迷惑であるだけでなく、ユーザーを間違いから保護するのに効果的ではありません。 ユーザーは、プログラムに不要な確認があり、自然な応答ができるだけ早く(多くの場合、読まずに)無視することをすぐに発見します。 その結果、このような確認は、これらのタスクに追加の手順を追加する以外にはほとんど実行しません。

ユーザーが間違いを犯す可能性があるからといって、確認を使用しないでください。 むしろ、確認は、重大または意図しない結果をもたらすアクションを確認するために使用する場合に最も効果的です。 良い確認は決して明白な状態ではありません。ユーザーは、続行しない正当な理由をユーザーが認識する必要があることを伝える必要があります。 また、ユーザーに変更を保存するよう求めるなど、アクションで本当に必要な場合にのみ使用されます。たとえば、保存する価値のある変更がある場合にのみ変更を保存します。 そうすることで、本当に保証されている場合にのみユーザーの注意が必要になります。

他の種類の確認では、多くの場合、ユーザーに質問への回答を強制するよりも優れた設計方法があります。

設計上の代替案を検討する

定期的な確認の必要性を排除する設計上の代替手段を次に示します。

• エラーを防止します。 大きな間違いを誤って行うのが困難になるようにタスクを設計します。 たとえば、破壊的コマンドを他のコマンドから物理的に分離し、複数のアクションを完了する必要があります。
• [元に戻す] を指定します。 アクションを元に戻す機能を提供します。 たとえば、削除されたファイルはごみ箱から回復できるため、通常、Microsoft Windows でファイルを削除しても確認は必要ありません。 アクションが非常に簡単に実行できる場合は、ユーザーがアクションをやり直すだけで十分な場合があることに注意してください。
• フィードバックを提供します。 望ましくない結果を明らかにします。 ユーザーが間違いを犯したときに気付かない場合は、元に戻すだけでは十分ではありません。 たとえば、直接操作 (ドラッグ アンド ドロップ操作など) の効果は常に明白である必要があります。
• 考えられる結果を想定しますが、簡単に変更できます。 ユーザーが何を望んでいるかわからないが、安全で安全な選択肢が存在する可能性がある場合は、その選択を想定し、何が起こったかを明確にし、コンテキスト メニューを使用して簡単に変更できるようにします。 たとえば、Microsoft Word では、ユーザーが単語のスペルを正しく入力することを前提としています。 スペルミスを認識し、正しい可能性が高いスペルを認識している場合、Word は自動的に修正を行いますが、ユーザーは元に戻すことができます。
• 選択を完全に排除します。 選択が重要でない場合、ユーザーは気にしません。 プログラムの を簡素化し、選択を排除 方が良いです。

確認を行うには、考える必要があります

確認に値を設定するには、続行しない理由をユーザーが理解する必要があります。 ユーザーが保存されていない変更でドキュメントを閉じているときのように、理由が明らかになることがあります。

この例では、確認の理由は明らかです。

他の状況では、理由がそれほど明白ではない可能性があります。

ダイアログ ボックスのコミット ボタン ラベルを選択する場合、 一般的なガイドラインは、メイン命令に対する特定の応答であるラベルを選択することです。 これにより、ユーザーは最小限のテキストを読んで続行する必要があるため、効率的な意思決定が行われます。 ただし、この効率の目標は、確認のために逆効果になる可能性があります。 次の例を考えてみましょう。

不正解:

アンインストール ボタンスクリーン ショット

この例では、正しい応答には思考が必要です。

ユーザーが Uninstall コマンドを実行した直後にこの確認を提示した場合、ユーザーの応答は "もちろんアンインストールする必要があります。ユーザーは、それを再考を与えることなくアンインストールをクリックします.

確認のために、ユーザーが急いで感情的な意思決定を行うことを望んでいません。 ユーザーが自分の対応について考えるのを奨励するには、小さな意思決定速度のバンプを提供する必要があります。 実用的な場合は、通常、コミット ボタンを慎重に言い回すことでこれを行う方が良いです。 たとえば、追加の言語を使用して、続行しない理由があることを示すことができます。

良い:

[とにかくアンインストール] ボタンのスクリーン ショット

この例では、"anyway" がコミット ボタン ラベルに追加され、確認によって続行しない理由が示されます。

この方法が実用的でない場合は、[はい] または [いいえ] コミット ボタンを使用できます。

も良い:

[はい] ボタンまたは [いいえ] ボタンを使用した確認の

この例では、[はい] または [いいえ] コミット ボタンを使用すると、ユーザーは少なくともメイン命令を読み取る必要があります。

すべての情報を指定する

質問する場合は、ユーザーがその質問にインテリジェントに答えるのに十分な情報を提供する必要があります。 Windows XP の [ファイルの置換の確認] ダイアログを検討してください。

[ファイルの置換の確認] ダイアログ ボックスのスクリーン ショットを

Windows XP の [ファイルの置換の確認] ダイアログ ボックス。

この確認では、ユーザーが質問に回答するために必要なすべての情報が提供されますか? 回答する前に、最も一般的なユーザー シナリオを検討してください。

• 既存のファイルを置き換えて、もう一方のファイルをコピー (または移動) します。
• 他のファイルをコピーまたは移動せずに、既存のファイルを保持します。
• 新しいファイルを保持またはコピーします (上位のシナリオ)。
• ファイルの内容やサイズなどの条件に応じて、既存のファイルを保持するか、他のファイルをコピーします。
• 既存のファイルを保持し、別の名前を使用して他のファイルをコピーします。
• 何か問題がある場合や予期しない場合は、操作を取り消します。

ユーザーは、[はい] をクリックし、[いいえ] をクリックしてシナリオ 2 をクリックすることで、シナリオ 1 を実現できます。 ファイルの日付を比較し、適切なボタンをクリックすることでシナリオ 3 を実現できますが、新しいファイルを決定し、特に最も一般的なシナリオである可能性が高いものに対して適切なボタンを決定するために必要な考え方に注目してください。

シナリオ 4、5、6 も驚くほど困難です。 ファイル サイズは丸められます。そのため、たとえば、これらのファイルのサイズが同じかどうか、または同じファイルであるかどうかを判断することはできません。 アイコンはファイルを開くために使用されるアプリケーション用であるため、ユーザーはファイルを開いてコンテンツを検査および比較する必要があります。 ファイルコンテンツのサムネイルを持つことは、質問に答えるのにはるかに役立ちます。

Windows Vista からの [ファイルのコピー] 確認では、より多くの情報を提供し、両方のファイルを保持するオプションを追加することで、これらのシナリオを処理する作業が大幅に向上します。

[ファイルのコピー] ダイアログ ボックスのスクリーン ショットを

Windows Vista のファイルのコピーの確認。

特定の有用な情報を提供する

質問する場合は、ユーザーが質問と代替応答の影響を理解していることを確認します。 次の Windows Internet Explorer のセキュリティ確認を検討してください。

あいまいな質問スクリーン ショット

あいまいなセキュリティ確認。

この確認では、ユーザーがインテリジェントに回答できない可能性がある質問が表示されます。 ユーザーは、Windows Internet Explorer にページを表示するよう要求しました。このメッセージは、テキストの文言と既定の選択肢として [いいえ] を強調表示することで、暗黙的にページに対して推奨します。

ページで発生する特定のセキュリティの問題は十分に説明されていないため、続行のリスクは明確ではありません。 確認の中で、ユーザーが [いいえ] をクリックする原因となる情報は何ですか? メッセージのあいまいさが原因で、確認はユーザーの続行を妨げる可能性はありませんが、ユーザーに悪い気持ちになります。

この確認を役立てるには、ユーザーが続行しないことを決定する原因となる可能性のある詳細情報を提供する必要があります。 一般に、確認の各応答について、それを必要とするシナリオを検討し、ユーザーが選択できるように十分な情報が提供されていることを確認します。 ジレンマではなく、選択肢を提供します。

確認が必要かどうかを判断する方法

シナリオを検討し、各応答を選択する可能性は、確認が必要かどうかを判断する体系的な方法を示唆しています。 ユーザーがすべての応答を選択する可能性が高い場合は、確認が必要であり、役立ちます。 ただし、応答が 1 つだけである可能性が高い場合 (たとえば、98% の時間)、確認は明らかに不要であり、削除する必要があります。 セキュリティ、法律、および安全性の問題に関連する確認は、例外として考えられる点に注意してください。

[設定を変更しますか?] のスクリーン ショット

この確認は必要ですか? ユーザーは [いいえ] を選択しますか? それは可能ですが、非常にあり得ない。 この確認は削除する必要があります。

3 つの操作のみを行う場合...

1. 確認が本当に必要であることを確認してください。 続行しない正当で明確な理由と、ユーザーが進まない可能性が存在する必要があります。

2. 確認の理由がすぐに明らかでない場合は、ユーザーが自分の応答について考えるのを促すコミット ボタンを選択します。 通常、これは、確認を "はい" または "いいえ" の質問として言い回し、完全にわかりやすい回答または "はい/いいえ" の回答を提供することによって行われます。

3. すべてのシナリオを検討し、インテリジェントに質問に答えるために必要な情報を提供します。

使用パターン

確認には、いくつかの使用パターンがあります。

使い	例
ルーチンの確認 ユーザーが定期的なリスクの低いアクションを続行することを確認します。	これらの確認は通常、"確認しています...?" と表現され、多くの場合、迷惑を最小限に抑えるために、このメッセージを再び表示しないチェック ボックスが表示されます。 [フォルダーをごみ箱に移動しますか?] のスクリーン ショット のスクリーン ショット ルーチン確認の例。 注: このパターンは通常不要であり、避ける必要があります。
危険なアクションの確認 ユーザーが何らかのリスクがあり、簡単に元に戻すことができないアクションを続行することを確認します。	リスクがあるため、通常、これらの確認には警告アイコンが表示されます。 危険なアクションの確認の例。
意図しない結果の確認 を する 予期しない、または意図しない結果を伴うアクションをユーザーが続行することを確認します。	これらの確認は、質問に加えて、意図しない結果を指摘します。 意図しない結果が発生するため、通常、これらの確認には警告アイコンが表示されます。 [すべてのタブを閉じる]の確認 意図しない結果確認の例。 ただし、このパターンでは、結果が本当に意図しないものである必要があります。 正しくない : [キー ロガーをオフにする]の確認 結果はここで意図されているため、これは日常的な確認です。
の説明 は、あいまいまたは予期しない結果を招く可能性のあるアクションをユーザーがどのように進めたいかを明確にします。	ドラッグ アンド ドロップ操作は、操作の効果が誤って解釈される可能性がある場合に明確になる可能性があります。 "常に終了時に保存しますか?" 確認のスクリーン ショットを 明確化の例。 注: このパターンは、あいまいな結果を伴わずにアクションを設計し、最も望ましい結果を想定することをお勧めします。
セキュリティの確認 ユーザーがセキュリティ上の影響を伴うアクションを続行することを確認します。	[パスワードを記憶しますか?] 確認 セキュリティ確認の例。
の動機の確認 アクションに関する情報を提供しますが、確認として提示します。	これらのダイアログ ボックスは確認として表示されますが、実際の目標はユーザー教育または機能の広告です。 下心的な動機の確認の例。 注: 通常は、より直接的な代替手段が存在するため、このパターンはお勧めしません。 たとえば、 アニメーションは、原因と効果の関係を示す優れた方法です。

ガイドライン

全般

• [変更の保存] の確認は、大幅な変更がある場合にのみ使用します。 ドキュメントの自動再フォーマットなど、ユーザーが直接行っていない変更を確認しないでください。

不正解:

この例は、ユーザーが変更しなかった空の電子メールまたはドキュメントに対して使用した場合に正しくありません。

アイコン

• 確認では、タイトル バーアイコンは使用されません。

• 確認用のコンテンツ領域アイコンは、そのデザイン パターンに基づいています:

  パターン	アイコン
  定期的な確認	[いいえ] アイコン。
  危険なアクションの確認	警告アイコン。
  意図しない結果の確認	リスクがある場合は警告アイコンを使用し、使用可能な場合は機能アイコンを使用します。それ以外の場合はアイコンなし。
  説明	確認にドキュメントが含まれている場合は、ドキュメントのサムネイルを使用します。それ以外の場合は、機能アイコン (使用可能な場合) を使用するか、アイコンを使用しません。
  セキュリティの確認	警告アイコン。
  下心の動機の確認	[いいえ] アイコン。

• 日常的な質問には警告アイコンを使用しないでください。 そうすることは、Windows の励まし トーンに反し、プログラムの使用が危険なアクティビティのように感じさせます。 完了する前にタスクを取り消した結果をユーザーが理解しているとします。

不正解:

この例では、警告アイコンを使用して日常的な質問をします。

コミット ボタン

• 確認の理由が明らかであるか、または自明にすることができる場合は、メイン命令に対する特定の応答を使用します。

この例では、確認の理由が明らかであるため、[保存] と [保存しない] が適切に機能しません。

• それ以外の場合は、確認応答に [はい] ボタンと [いいえ] ボタンを使用します。 そうすることで、ユーザーは応答する前に確認を少し考える必要があります。 確認に [OK] と [キャンセル] を使用しないでください。

正解:

この例では、[はい] または [いいえ] コミット ボタンを使用すると、ユーザーは少なくともメイン命令を読み取る必要があります。

不正解:

この例では、OK/キャンセルを使用するとわかりにくいです。

• プログラムを閉じるか、Windows を再起動するには、メイン命令に対する特定の応答を使用します。 誤解を防ぐには、この目的で Close または Yes/No を使用しないでください。

正解:

不正解:

[はい] ボタンのスクリーン ショット

正しくない例では、はいを使用して Windows を再起動します。

コマンド リンク

• 説明パターンについては、コマンド リンクを使用して代替手段を明確にすることを検討してください。

受け入れ可能:

"1 つまたはすべての出現箇所を変更しますか?" のスクリーン ショットを

良い:

コマンド リンクする

より良い例では、コマンド リンクを使用すると、代替候補が明確に表示されます。

• 最も一般的に使用されるコマンド リンクを最初に提示します。 結果の順序は、ほぼ使用の可能性に従う必要がありますが、論理フローもあります。
• コマンド リンクでさらに説明が必要な場合は、補足説明 提供します。 補足説明では、ユーザーがオプションを選択する理由、またはオプションを選択した場合の動作について説明します。

その他のガイドラインと例については、「コマンド リンク を参照してください。

既定値

• 確認の既定の応答は、その設計パターンに基づいています:

  パターン	既定の応答
  定期的な確認	進む。
  危険なアクションの確認	続行しないでください (または安全な選択)。
  意図しない結果の確認	結果が重要な場合は、続行しないでください。それ以外の場合は、続行します。
  説明	最も可能性の高い応答。
  セキュリティの確認	続行しないでください。
  下心の動機の確認	進む。

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

• このオプションは、ルーチンと下心の動機の確認パターンにのみ使用します。 その他のパターンでは、情報が必要な場合は、常に表示する必要があります。
• 不要な確認を表示することを正当化するために、このオプションを指定しないでください。 代わりに確認を取り除くだけです。

不正解:

まだ正しくありません:

[メッセージをもう一度表示しない] のスクリーン ショットを

これらの例では、[このメッセージをもう一度表示しない] オプションを追加しても、不要な確認は修正されません。

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

一括操作

• 一括操作に適用される確認については、操作全体に確認を適用するオプションを指定します。

[do this for all items?]\(すべてのアイテムに対してこれを実行しますか?\) チェック ボックスのスクリーンショットを

この例には、一括操作のオプションがあります。

• 一括操作で確認を排除または延期します。

不正解:

[ファイルの削除の確認] ダイアログ ボックスのスクリーン ショットを

この例では、Windows XP の Windows エクスプローラーは、一括ファイルの移動中に各読み取り専用ファイルを確認します。 要求せずに読み取り専用ファイルをコピーするか、これらのファイルの処理を延期し、タスクの最後に確認を提示する方が適しています。

段階的な開示

• 確認メッセージに詳細情報を含める必要がある場合は、プログレッシブ開示ボタン ("詳細の表示" など) を使用して表示します。 これにより、一般的な使用の確認が簡略化されます。 ユーザーが見つけられない可能性があるため、必要な情報を非表示にしないでください。
• 詳細が表示されない限り、"詳細の表示" は使用しないでください。 既存の情報を別の形式で変更しないでください。

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

ユーザー アカウント制御

• 確認の代わりに、ユーザー アカウント制御 (UAC) 昇格 UI を使用しないでください。 アクションに確認が必要な場合は、別のダイアログ ボックスを使用します。 昇格 UI中に、ユーザーはタスクを開始したかどうか、およびプログラムが信頼できるかどうかを重視する必要があります。
• 昇格 UI の前に確認を表示します。 これにより、不要な昇格がなくなります。

テキスト

全般

• 冗長テキストを削除します。 タイトル、メイン命令、補足命令、コンテンツ領域、コマンド リンク、コミット ボタンの冗長テキストを探します。 一般に、命令と対話型コントロールに完全なテキストを残し、他の場所から冗長性を削除します。
• テキストに "警告" または "注意" を使用しないでください。 ユーザーが注意して続行する必要がある場合は、代わりに警告アイコンを使用してこれを指定します。

不正解:

ボリュームフォーマット確認スクリーン ショット

この例では、"warning" という用語は不要です。

タイトル

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

ただし、確認が実行時間の長いタスクからのものであり、タスクの開始後に適切に表示される場合は、常にコマンドまたは機能を使用してコンテキストを明確に識別します。

• メイン命令の目的であるダイアログ で何を行うかを説明するためにタイトルを使用しないでください。
• わかりやすくする場合は、タイトルを Confirm という単語で開始します。
• 危険なアクションの確認のために、関連するオブジェクトの名前を追加して強調することができます。

[ドライブのフォーマット] ダイアログ ボックスのタイトルスクリーン ショット

この例では、フォーマットするドライブがタイトルに含まれています。

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

主な手順

• 確認のための主な指示は、その設計パターンに基づいています:

  パターン	メイン命令
  意図しない結果の確認	意図しない結果が示されます。 例外: ユーザーが意図しない結果を明確に意味するかどうかを尋ねる質問がある場合は、代わりに質問します。 [すべてのタブを閉じる]の確認 この例では、操作の結果を十分に伝えるためにユーザーに依頼します。
  その他のすべて	1 つの質問をして、ユーザーが続行するかどうかを判断します。

• 簡潔に、完全な文を 1 つだけ使用してください。 メイン命令を重要な情報まで削除します。 さらに説明する必要がある場合は、補足命令を使用します。

• 関連するオブジェクトがある場合は、その完全な名前を付けます。

• 正のフレージングを使用します。 肯定的な言い回しは、ユーザーが理解しやすくなります。

正解:

ファイルとプリンターの共有を有効にしますか?

不正解:

ファイルとプリンターの共有を無効にしますか?

ただし、フレージングは、コマンドの語句が負の場合でも、関連付けられているコマンドと一致する必要があります。そのため、たとえば、disable を使用して Disable コマンドを確認します。

• フレージングに関する厳密な規則はありませんが、これらの一般的な確認語句 、示された意味合いがあります。

  フレーズ	含蓄
  [アクションを実行しますか?]	ユーザー要求の直接の結果を確認する。
  [アクションを実行しますか?	ユーザー要求の副作用の確認。
  [結果を選択しますか?	明確化が必要です。
  [アクションの実行]?	意味がありません。

• 危険なアクションの確認の場合は、この用語を永続的に使用して、アクションを元に戻すことができないことを示します。

完全削除の確認スクリーン ショット

この例では、"永続的" は、操作を元に戻すことができないことを示します。

• 文形式の大文字を使用します。

補足手順

• 確認のための補足命令は、その設計パターンに基づいています:

ラベル	価値
パターン	補足命令
意図しない結果の確認	1 つの質問をして、ユーザーが続行するかどうかを判断します。
その他のすべて	ユーザーが続行したくない理由について説明します。 このような理由は次のとおりです。 次の 1 つ以上の損失の可能性があります。 データ損失や財務損失などの貴重な資産。 システム アクセスまたは整合性。 機密情報のプライバシーまたは制御。 元に戻せないアクション。

• 少し異なる文言でメイン命令を繰り返さないでください。 追加する必要がない場合は、代わりに補足命令を省略します。
• 意図しない結果の確認については、ユーザーがメイン命令を見過ごした場合に を続行しない理由があることを簡潔に示すために、この用語を使用することを検討してください。 詳細については、「設計概念」を参照してください。
• 完全な文、文スタイルの大文字化、終了句読点を使用します。

ドキュメンテーション

確認を参照する場合:

• タイトルが確認に固有の場合は、タイトルによる確認を参照してください (つまり、プログラム名ではありません)。それ以外の場合は、メイン命令で参照してください。
• 必要に応じて、確認ダイアログ ボックスをメッセージとして参照できます。
• 大文字と小文字を含む正確なテキストを使用します。
• 可能な場合は、太字を使用してテキストの書式を設定します。 それ以外の場合は、混乱を防ぐために必要な場合にのみ、テキストを引用符で囲みます。

例: ファイルのコピー メッセージで、新しいファイルをクリックします。