確認

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

一般的な確認。

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

• これらは、ユーザーによって開始されたアクションの直接の結果として表示されます。
• ユーザーがアクションを続行することを確認します。
• 単純な質問と 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 インターネット エクスプローラーセキュリティ確認を検討してください。

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

この確認では、ユーザーがインテリジェントに答えることができないという質問が表示されます。 ユーザーは、Windows インターネットエクスプローラーページを表示するように要求しました。このメッセージは、テキストの文言を使用し、既定の選択肢として [いいえ] を強調表示することで、暗黙的にページに対して通知します。

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

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

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

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

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

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

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

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

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

使用パターン

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

使用法	例
ルーチンの確認 ユーザーが、リスクの低いルーチンアクションを続行することを確認します。	これらの確認は通常、"確認しています...?" と言われ、多くの場合、迷惑を最小限に抑えるためにチェックボックスにこのメッセージを再び表示しません。 ルーチン確認の例。 メモ： 通常、このパターンは不要であり、避ける必要があります。
危険なアクションの確認 ユーザーが何らかのリスクがあり、簡単に元に戻すことのできないアクションを続行することを確認します。	リスクがあるため、通常、これらの確認には警告アイコンが表示されます。 危険なアクションの確認の例。
意図しない結果の確認 予期しない、または意図しない結果をもたらすアクションをユーザーが続行することを確認します。	これらの確認では、質問に加えて、意図しない結果が指摘されます。 意図しない結果になるため、通常、これらの確認には警告アイコンが表示されます。 意図しない結果の確認の例。 ただし、このパターンでは、結果が本当に意図しない必要があります。 誤った： 結果はここで意図されているため、これは定期的な確認です。
説明 ユーザーがあいまいまたは予期しない結果を招く可能性のあるアクションを続行する方法を明確にします。	ドラッグ アンド ドロップ操作では、操作の効果が誤って解釈される可能性がある場合に明確になる可能性があります。 説明の例。 メモ： このパターンは、あいまいな結果なしでアクションを設計し、最も可能性の高い望ましい結果を想定する方が良いため、避ける必要があります。
セキュリティの確認 ユーザーがセキュリティ上の影響を受けたアクションを続行することを確認します。	セキュリティ確認の例。
下心動機の確認 アクションに関する情報を提供しますが、確認として提示します。	これらのダイアログ ボックスは確認として表示されますが、実際の目標はユーザー教育または機能の広告です。 下心動機の確認の例。 メモ： 通常は、より優れた直接的な代替手段があるため、このパターンはお勧めしません。 たとえば、 アニメーション は原因と効果の関係を示す優れた方法です。

ガイドライン

全般

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

正しくない:

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

アイコン

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

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

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

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

正しくない:

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

コミット ボタン

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

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

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

正確:

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

正しくない:

この例では、OK/キャンセルを使用すると混乱します。

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

正確:

正しくない:

正しくない例では、Windows を再起動するために [はい] が使用されています。

コマンド リンク

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

普通：

より適切な例:

より良い例では、コマンド リンクによって代替手段が明確になります。

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

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

既定値

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

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

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

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

正しくない:

それでも正しくありません。

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

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

一括操作

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

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

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

正しくない:

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

段階的表示

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

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

ユーザー アカウント制御

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

Text

全般

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

正しくない:

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

タイトル

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

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

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

この例では、書式設定するドライブがタイトルに含まれています。

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

主要な命令

• 確認のメイン指示は、その設計パターンに基づいています。

  Pattern	メイン命令
  意図しない結果の確認	意図しない結果を示します。 exception: ユーザーが意図しない結果を明確に意味するかどうかを尋ねる質問がある場合は、代わりに質問してください。 この例では、アクションの結果を十分に伝えるために、ユーザーに続行を依頼します。
  その他すべて	1 つの質問をして、ユーザーが続行するかどうかを判断します。

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

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

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

正確:

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

正しくない:

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

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

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

  フレーズ	含蓄
  [アクションを実行] してもよろしいですか?	ユーザー要求の直接の結果の確認。
  [アクションを実行しますか?	ユーザー要求の副作用の確認。
  [結果を選択しますか?	説明が必要です。
  [アクションを実行する]?	意味なし。

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

この例では、"永続的" は、アクションを元に戻すことができないことを示します。

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

補足説明

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

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

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

ドキュメント

確認を参照する場合:

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

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