メッセージボックスで「はい/いいえ」または「OK /キャンセル」を使用する必要がありますか？
意味的には、[はい]/[いいえ]ボタンは[OK]/[キャンセル]ボタンとほぼ同じですが、一般的に何を使用することをお勧めしますか？常に[はい]/[いいえ]を使用するか、[OK]/[キャンセル]を常に使用する必要がありますか？それともケースに依存しますか？
代わりに動詞を使用できる場合は、「Yes」または「OK」を使用しないでください。
また、ほとんど常に「はい」または「OK」の代わりに動詞を使用できます。
だれもあなたのダイアログボックスを読み取らない であるというルーカスマティスの仮定に同意します。ボタンは説明文やタイトルとの関連で意味をなさないため、可能な場合は常に「はい」や「OK」の代わりに動詞を使用してください。これは、さらに強化されたビューです Microsoftのユーザーインターフェイスガイドライン ：
ユーザーがアクションに関連する特定のテキストを確実に読むようにしたい場合は、それをインタラクティブコントロールに配置します。
可：
この例では、ユーザーが確認している内容を説明するテキストをユーザーが読まない可能性があります。
Better：
この例では、少なくともユーザーがディスクをフォーマットしようとしていることを理解していることを確認できます。
Appleの ヒューマンインターフェイスガイドライン これをさらに拡張し、「OK」または「はい」ボタンの代わりに複数単語の動詞を推奨し、アラートボックスの推奨領域を明確に定義します。
アクションを元に戻せない場合は、最初に警告ボックスのみを使用することをお勧めします。ボタンラベルについては、次のようになっています。
デフォルトのボタン名が、説明するアクションに対応していることを確認してください。特に、デフォルトボタンに[OK]を使用しないことをお勧めします。 OKの意味は、ユーザーが何かを実行したいかどうかを確認する警告でも不明確になる可能性があります。たとえば、OKは「OK、私はアクションを完了したい」または「OK、私はアクションが引き起こしたであろう否定的な結果を理解した」という意味ですか？
消去、変換、クリア、削除など、より焦点を絞ったボタン名を使用すると、ユーザーが実行しているアクションを確実に理解できます。
つまり、ユーザーに「はい」または「いいえ」ボタンを提供することが唯一のまたは最も論理的なオプションであると思われる場合でも（たとえば、「ログアウトしてもよろしいですか？」）、ほとんどの場合、代わりに動詞または句。
「ログアウトしますか？」
[ログアウト]-または-[キャンセル]
このようにして、ユーザーはタイトルや説明文を読んで進む方法を理解する必要がなく、どちらかのボタンをクリックする意味が誤って解釈されることはありません。
また、「いいえ」と「キャンセル」のどちらかを選択した場合、「キャンセル」の方が上記とまったく同じ理由でほとんど常に優れています。「キャンセル」の意味は、ユーザーが残りの部分を読んでいない場合でも明らかですダイアログボックス。 「いいえ」の意味はおそらく明確ですが、動詞と組み合わせると意味がなくなります（たとえば、「ログアウト」と「キャンセル」は、「ログアウト」よりも単独で読む方が意味があります。 'および'いいえ '）。
ボタンの[はい]/[いいえ]のような短い単語を使用すると、ユーザーがダイアログのメッセージを読み間違えた場合、特にメッセージの記述が間違っている場合、混乱を招く可能性があります。 （そのため、最初はメッセージを簡潔で明確にしてください）
yes/nook/cancelを実際に強制するオプションが何に適用されるかを知る前に、メッセージを読んで理解する必要があります。製品に慣れているユーザーは、メッセージを読むのではなく、ボタン自体をスキャンするほうがよいでしょう。
したがって、私が好むアプローチは、アクションの確認をOKよりも少し冗長にすることです（例：Save changes、Add user、Update password）あなたがやろうとしていることを非常に明確にするようにします。そして、Cancelをそのままにします-短くて使い慣れたエスケープルート（特に、それが 'であることを明確にする必要があるため） [アクションを実行しない]オプション。
などの簡単な質問でも、ログアウトしますか（実際に最初に必要な場合）ボタンLog outおよびCancelではなく、Yes/CancelまたはYes/No。
このようにして、ユーザーはボタンをすばやくスキャンし、メッセージを読んでいなくても、クリックする必要があるものの要点を取得できます。
編集-グリーンギットの回答に関する上記のコメントを参照して、Skypeからの例を以下に示しますnotを実行する：
確認ダイアログ（質問をし、入力を含まないもの）には、yes/noが必要です。例えば...
アカウントをキャンセルしますか-
yesnoログアウトしますか-
yesno
一方、「アクション」を表し、ユーザー入力を期待するダイアログには、ok/cancelまたは<action>/cancelが必要です。例えば...
イベントの日時を設定...
okcancel新しい連絡先を追加...
addcancelパスワードを更新してください...
updatecancelタイムゾーンを変更...
donecancel
[OK]/[キャンセル]および[はい/いいえ]ボタンは、アクションのより適切なラベルを考えるのが面倒である場合にのみ使用できます。
適切な確認ダイアログの例：
- 保存されていないドキュメントを閉じようとしたときのLibreOffice/OpenOfficeは次のとおりです。
ボタンのラベルは、実行されるアクションを反映する必要があります。
また、アカウントの「登録解除」/「閉じる」などのアクションは、キャンセルボタンのあいまいさを避けるために「キャンセル」として呼び出さないでください。つまり、キャンセルボタンは、ユーザーが何も問題を起こすことなく反射をクリックできるセーフハーバーであり、「キャンセル」ボタンをクリックすることをユーザーに恐れさせないでください。
Greengitの例をとると、これは私が彼らそれぞれに提案するものです：
Do you want to delete your account -- "Delete account" "Cancel"
Do you want to sign out -- don't even ask this since signing out
is a non-destructive action, if the user
has an unsaved work and signing out could
lead to loss of unsaved work, then you have
two options: ask whether they want to discard
the unsaved work, or automatically save the
work as a draft.
Set event date and time -- "Set time" "Cancel". Although since this is a
non-destructive action, you should probably not
need to ask confirmation and just apply the
action immediately with a "Revert" button.
Add a new contact -- Don't ask for confirmation to "Add", when the user
entered the "Add contact" form and doesn't quit
immediately, they already confirmed that they wanted
to add a contact; automatically save the contact's
information when the user finish entering the
contact's information. Also you might want to have a
"Revert" or "Discard" button.
Update your password -- "Update Password" "Cancel"
Change your timezone -- "Set Timezone" "Cancel". The same with setting
time, if this is non-destructive then don't ask for
confirmation.
一部のUIガイドラインでは、はい/いいえではなく常に[OK]/[キャンセル]ダイアログの使用を推奨しています。
しかし、これは大きな間違いだと思います。たとえば、最近、「本当にアカウントをキャンセルしますか？」という質問のダイアログが表示されました。 「OK」と「キャンセル」というラベルの付いたボタン。この場合、「OK」は「キャンセル」を意味し、「キャンセル」は「キャンセルしない」を意味します。
少なくとも私の意見では、これは完全に狂気にかなり近いです。もちろん、「アカウントを閉鎖する」のような質問に言い換えることも可能です。それでも、たとえそのWordを使用/提案していなくても、一部の人々はアカウントをキャンセルしたと考える可能性があります。この状況では、「キャンセル」というラベルの付いたボタンはお粗末な考えです。一部の人々は必然的にそれをアカウントを閉じるアクションをキャンセルするものと考えるつもりですが、他の人々はアカウント自体をキャンセルするものと考えています。
「はい」/「いいえ」に対する偏見にもいくつかのメリットがあることを認めざるを得ません。この場合、「在庫」ラベルを避け、「アカウントを閉じる」、「アカウントを開いたままにする」などを使用する方が良いと思います。
ユーザーに質問をして、ユーザーに応答するためのオプションを提供することを考えている場合、どちらも非常に良い解決策ではありません。はい/いいえはアンケートに参加している場合に機能しますが、モーダルダイアログの場合は最小限です。 OK/Cancelは、画面の解像度が低く、ボタンを簡潔にする必要があった昔のホールドオーバーのようなものです。
重要なのは、ボタンのラベルはマイクロコピーと見なされるため、ユーザーインターフェイスの他の要素に注意を払う必要があるということです。何に同意または反対しますか？何をOKまたはキャンセルしますか？その情報がボタンにないのはなぜですか？
したがって、戻って、ラベルをより明確に変更する方法を考えてください。 「この行を削除しますか？はい/いいえ」は、ボタンが「この行を削除する」/「何も削除しない」とだけ言った場合、スキャンがはるかに簡単になります（特に破壊的なアクションであるため）。ユーザーに実行を促す大きなアクションとしてスタイリングし、キャンセルボタンを小さくする（おそらくボタンを小さくする）ことも、大きな助けになります。
モーダルダイアログが含まれているため、[OK]/[キャンセル]に2つのボタンが導入される場合があります。モーダルダイアログが必要かどうか、またはそれを削除してエクスペリエンスを簡素化できるかどうかを自問してください。たとえば、ユーザーのログアウトダイアログがある場合は、モーダルダイアログで「サインアウトしますか？OK /キャンセル」と尋ねるのではなく、「サインアウト」と書かれたボタンがあれば、ユーザーはそれをクリックするかどうか。
決定に役立つ関連質問：
一般的に、@ Nickに同意しますが、言及する価値のあることがもう1つあります。
できる限りダイアログを避けてください-ダイアログはほとんどの場合煩わしいだけです-確信があるかどうかユーザーに尋ねます。私はあなたのことは知りませんが、私はこの種の抗議を本当に嫌いです-コンピュータは私に他の方法では役に立たないためにここにいます！
だから-削除ボタンはどうですか？この種の行動の前に尋ねることは理にかなっていますよね？まあ、それは確かにありますが、はるかに良い解決策もあります-元に戻す機能を提供します
ごみ箱、トレイ通知のリンクを元に戻す、アカウントをキャンセルした後に送信された「レスキューメール」、同じドキュメントの複数のバージョンなど。怠惰にしないでください。UIの簡素化に時間をかけ、UIをよりまっすぐにします。ユーザーは高速で動作する能力に値します。ユーザーがミスを犯した場合は、安全ロープを用意するだけです-それだけです。それが完全に必要でない限り、それらを気にしないでください。
また、削除を他のボタンと分離して配置し、少し細かくすることで、これらの間違いを最小限に抑えることができます。 iPhoneアプリは通常、画面の上部に保存/キャンセル（両方とも潜在的に危険）を備えています-タップするのが難しいためです。
編集： Aza Raskinからの「確認の取り消し」に関する記事 もあります。
ほとんどのユーザーは3 mしか探しません。
正の1つ-
Yes、OK、Add、Retry、Wait..etc。マイナス1つ-
No、Abort、Quit、Exit
そして3つ目は：
- 「このメッセージボックスからの脱出」-
Cancel
したがって、Yes、NO、およびCancelを使用すると3つの異なるタイプの考え。
つまり、使用方法はケースによって異なります。
配合によります。 「はい/いいえ」の回答を期待している質問に対して、「はい/いいえ」以外は必要ありません。質問ではないもの（または「はい/いいえ」が有効な回答にならないように作成された質問）に対して「はい/いいえ」を使いたくありません。
次の主張を証明する統計はありませんが、個人的にはボタンにカスタムテキストを設定する方が常に良いとは限りません。
[OK]/[キャンセル]/[はい]/[いいえ]は非常に一般的であり、私たちの脳はすでに一瞬で認識して対処するように訓練されていますが、カスタムラベルはユーザーが情報を停止して積極的に処理する必要があるため、使用すると煩わしい場合があります。一般的なアクション。
ユーザーが開始する期待されるアクションとダイアログが同じロジックに従う限り、単純なはい/いいえは素晴らしいです。私はすでに何をしているのか知っています。確認するだけです。追加の説明は、単なるノイズのようなものです。
1つの例は、ゴミ箱を空にするアクションです。偶発的なクリックを避けるために毎回プロンプトが表示されるようにしたいのですが、わざとクリックしたときは、できるだけ早くそれを使いたいと思っています。クリックするだけです-クリックして、ダイアログのテキストを読みたくありません。質問の内容はすでに予想していて、「はい」または「いいえ」（または「OK」/「キャンセル」）と答えると予想されます。これが通常の答えのセットです。
このIMHOの良い解決策の1つは、ボタンラベルを「はい、何かしてください」という形式で使用することです。このようにすれば、テキストをスキャンして意味を理解するのは簡単ですが、ダイアログについて混乱している場合は、すべてを読んでボタンの機能を確認できます。
他のほとんどの回答に同意します。ほとんどの場合、[はい/いいえ]ボタンではなく特定の応答を表示するほうが良いのほうがよいと思います。
ただし、ダイアログボックスの Microsoftデザインガイドライン（2018年5月） は、はい/いいえが適切である場合があると述べています。
- 確認するには思考が必要です
- 長いまたは扱いにくい言い回しを避けるために
（同意するかどうかはわかりませんが、これらの例で「はい/いいえ」を使用することが意図的な設計の決定であったことは興味深いことでした。）
- 確認が必要です
Microsoft設計ガイドラインの確認に関するセクション は、Yes/Noの使用が確認に重要な結果をもたらす場合に適切である可能性があると主張しています。
ユーザーがミスをする可能性があるという理由だけで確認を使用しないでください。 むしろ、確認は、重大または意図しない結果をもたらすアクションを確認するために使用される場合に最も効果的です。[...]
確認に価値があるためには、ユーザーは続行しない理由を理解する必要があります。保存されていない変更を含むドキュメントをユーザーが閉じるときなど、理由が明白な場合があります。
この例では、確認の理由は明らかです。
他の状況では、理由はそれほど明白ではないかもしれません。
ダイアログボックスのコミットボタンラベルを選択するときの一般的なガイドラインは、メインの指示に対する特定の応答であるラベルを選択することです。ユーザーは続行するために最小限のテキストを読む必要があるため、効率的な意思決定につながります。ただし、この効率目標は、確認には逆効果になる場合があります。この例を考えてみましょう：
不正：
この例では、正しい応答には考慮が必要です。
ユーザーがUninstallコマンドを発行した直後にこの確認を提示すると、ユーザーの応答は「もちろんアンインストールしたいです！」ユーザーは、何も考えずに[アンインストール]をクリックします。
確認のために、ユーザーが急いで感情的な決定を下すことは望ましくありません。ユーザーが自分の反応について考えるように促すには、意思決定の速度を少し上げる必要があります。実用的な場合、通常は、コミットボタンを慎重にフレージングすることでこれを行うことをお勧めします。たとえば、追加の言語を使用して、続行しない理由があることを示すことができます。
Better：
この例では、確認が続行しない理由を示していることを示すために、コミットボタンラベルに「とにかく」が追加されています。
そのアプローチが実用的でない場合は、[はい/いいえ]コミットボタンを使用できます。
さらに良い：
この例では、[はい/いいえ]コミットボタンを使用すると、ユーザーは少なくともメインの指示を読む必要があります。
- 長いまたは不自然な表現を避けるため
特定の言い回しのあるコミットボタンが長くて扱いにくい場合は、主な指示を「はい」または「いいえ」の質問として言います。または、コマンドリンクを使用して、メイン命令に対するより長い応答（5ワード以上）を使用することもできます。
不正解：
正しい：
正しくない例の具体的なフレーズは長すぎるため、正しい例では「はい」と「いいえ」を使用しています。
ワークフローでどの方法を実行するかを決定する必要がある場合は、ダイアログで[はい]/[いいえ]を使用します。 OK /キャンセルは「続行しますか？」の意味で使用する必要があります通常、キャンセルは、キャンセルを押すと何かが停止または中断されることを意味するため、処理/ワークフローを使用します。 「ここで中止しますか？」などの質問と組み合わせてOK /キャンセルダイアログを使用しません...これは、はい/いいえの決定です（ワークフローと決定を参照）。したがって、正しい選択は常に質問にも依存します。さて、ユーザーを苛立たせる質問を作成することは可能ですが、なぜこれを行う必要があるのでしょうか。
@Nickで説明されているように、私はVerbを使用してキャンセルすることを好みます。たとえば、ウィンドウを閉じる場合、ユーザーに「ウィンドウを閉じますか？」と尋ねると、 「はい/いいえ」と「閉じる/滞在」の2つのタイプのオプションがあります。「OK /キャンセル」は意味がありません。
したがって、最初に優先されるのは動詞で、次にイエス/ノーです。
[はい/いいえ]および[OK /キャンセル]ボタンラベルの時代は終わりました。この記事で提案されているように、ダイアログボックスでアクション固有のボタンラベルを使用するときが来ました。
これは、ダイアログボックスのテキストを読まないパワーユーザーが間違ったボタンをクリックするのを防ぐのに役立ちます。それらはインターフェースをすばやく移動する傾向があるため、ボタンをアクション固有のWordでラベル付けすることにより、ボタンラベルを読み取ってクリックするボタンを知るだけで済みます。 「OK」はあいまいで、ユーザーが実行しているアクションやタスクを説明していません。