冗長な「キャンセル」オプションを追加する必要がありますか？
ユーザーがアクションを開始すると、システムは、ユーザーからの確認が必要な特別な状態が存在すると判断します。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
上記の例では、「いいえ」は「キャンセル」とまったく同じです。 「キャンセル」ボタンはまだ表示されますか？
これを含めない理由：これは冗長であり、ユーザーは「いいえ」と「キャンセル」の違いに疑問を感じるでしょう。
含める理由：ユーザーに「簡単な方法」を許可します：「邪悪な恐ろしいメッセージボックスを読み、考え、理解したくありません。アクションをまったく開始しなかったふりをしてください。 」
注：私は別の提案（完全に異なるメッセージボックスのデザインなど）を高く評価していますが、これら2つのオプションのどちらが好ましいか（たとえば、 UIライブラリが提供するオプションが限られている状況）。
[キャンセル]で[いいえ]を使用しないでください。彼らは幾分同じ機能をします。
一歩先に進み、提供するオプションで正確であることをお勧めします。モーダルダイアログのメッセージを読まずに、[はい]/[いいえ]を何度もクリックします。特に、アプリケーションをインストールしているとき、またはいくつかの警告/アラートポップアップが表示されているとき。責任あるデザイナー/開発者として;ユーザーに十分な情報に基づいた決定をしてもらいたい。
以来、いいえとキャンセルは幾分同じ機能を実行します。いいえの代わりにキャンセルを使用します。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
そのプロンプトの私の読書は、（おおよそ）次の意味を示しています。
I see you are trying to [fizzbuzz the main Foo].
That isn't recommended because [the main foo has already been fizzbuzzed].
I suggest instead [frobnicate a secondary foo].
このようにフォーマットされたプロンプトが表示された場合、[はい]、[いいえ]、および[キャンセル]ボタンに対する期待は次のとおりです。
- はい：提案されたアクションに従います
- いいえ：提案を無視して、元のアクションを続行します
- キャンセル：何もせず、このアクションを試みる前の状態に戻ります
「いいえとキャンセルは同じことをする」という説明が両方ともキャンセルについて説明したことを意味すると仮定すると、ボタンのテキストをカスタマイズしない場合はYesとCancelを使用します。 DPSの例のように、または2つのボタンのオプションのみがYes/No次に、プロンプトの各ボタンの効果をはっきりと示します。たとえば、「メインのFooは既にfizzbuzzされています。2番目のFooを妨害するには「はい」をクリックし、キャンセルするには「いいえ」をクリックしてください。」
アクションがまったく同じ場合は、アクションを1つに減らす必要があります。同じアクションに別の言い回しを追加すると、ユーザーが混乱し、ダイアログを読み直し、システムが両方のアクションを提供する前に自分が何をしたかを考えて完了時間を増加させ、最後にフラストレーションを引き起こします。
ダイアログボックスには、3つのオプションではなく2つのオプションを使用することをお勧めします。
はい、ダイアログをキャンセルする冗長な方法を提供できますが、noは、テキスト付きの冗長なボタンであってはなりません。
私はこれに同意する：
これは、ユーザーにとって「簡単な方法」を可能にします。「私は、邪悪な恐ろしいメッセージボックスを読み、考え、理解したくありません。アクションをまったく開始しなかったふりをしてください。」
ただし、表示されているように、ユーザーはを読んで考えなければなりません。これは、3つのボタンすべてが同じように表示されており、理解するために読み取り/考える必要があるためです。これは何をするか（Pectoralisが指摘したように、ユーザーはnoまたはcancelの違いによって混乱します）。赤[x]ボタンは、しかし、すぐに認識可能であり、何も考える必要はありません。
モーダルダイアログをキャンセルする3つの方法（Webまたはデスクトップアプリのいずれか）を常にサポートする必要があります。
- あなたが示したように明示的な「いいえ」または「キャンセル」ボタン
- 赤
[x]（理想的には、オペレーティングシステムにネイティブ） - キャンセルする
Escキーのサポート
@DPSが気づいたように、私はユーザーにボタンが実行する正確なアクションと2つの間の視覚的な違いを通知することも選択しました。これらは役立つはずです（特に最初のリンク）：
プライマリアクションとセカンダリアクションのどちらを選択するかを視覚的に区別することは、人々が適切な選択を行うのに役立つ便利な方法です。
この区別は、オプションAのボタンとリンクのようにもっと目立つのでしょうか、それともオプションCの2つの異なる色のボタンのようにもう少し微妙なのでしょうか。オプションAは、完了までの時間、固定の平均数、および固定の平均合計長が少し良くなり、人々はフォームをより速く完了しましたが、それほどではありませんでした。
もちろん、これらの区別の必要性は、二次的なアクションが存在しない場合には、問題になります。フォームの各2次アクションが本当に必要であり、無差別に追加しないでください。
https://uxplanet.org/primary-secondary-action-buttons-c16df9b3615http://uxmovement.com/buttons/visual-weight-of-primary-and-secondary- action-buttons /https://www.smashingmagazine.com/2016/11/a-quick-guide-for-designing-better-buttons/
ダイアログを自由に設計する自由を考えると、@ DPSの答えは素晴らしいです。ただし、UIライブラリがダイアログボタンの選択に対して制限されたオプションを提供する場合に、これを処理する方法についても尋ねます。
この場合、「はい/いいえ」ではなく、「OK /キャンセル」ダイアログを選択することをお勧めします。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
これは、[キャンセル]を押しても何も起こらないことを明確に示していますが、[はい/いいえ]オプションでは、いいえがセカンダリfooを乱さずに何かを行うかどうかがあいまいです。 （「はい/いいえ/キャンセル」では、「いいえ」と「キャンセル」が異なることをするという誤った意味があり、「いいえ」はおそらく元のfooで何らかの方法で続行しようとする必要があるという結論につながります）。
使いやすさの意味では、異なるラベルや説明で同じ効果をもたらす異なるアクショントリガーを使用することはできません。
モーダルダイアログや通知バナーなど、非表示の方法で通知を表示することを検討してください。この方法で、標準を使用できます X 通知を却下するためのボタン、 Frobnicate a Secondary Item within通知自体。
3つのオプションは、物事を混乱させます。
簡単な方法が必要な場合は、おそらくこのダイアログボックスを完全に削除する必要があります。
Fooファブの後に、ユーザーが簡単に見たり操作したりできる明白なアイコンを表示し、必要のないものでワークフローを中断するのではなく、アニメーションが注目を集めるでしょう。
「標準」ダイアログボタンには常に問題がありました。一つの問題は彼らの感覚がしばしば曖昧であるということですが、もう一つの問題は彼らが実際よりも明確に選択をすることができるということです。
間違いなく、例外的な状況が発生した場合、ユーザーが質問を理解するまで、ユーザーすべきは混乱します。ダイアログをよりシンプルでルーチンにすることは、ユーザーが必要とする注意の量を軽視しているだけです。
「はい」、「いいえ」、「OK」、「キャンセル」に制限されている場合は、「はい」/「いいえ」がユーザーに質問を読んでもらう可能性が最も高いことをお勧めします（明確に表現する必要があります） ）。 「キャンセル」を1つのオプションとして含むダイアログが表示されている多くのユーザーは、他のボタンを反射的にクリックして続行します。
理想的には、ユーザーが意図的で情報に基づいた選択を行うことを保証するために、「文字の多い」ボタン/ハイパーリンクを使用します。もちろん、ここでのもう1つのモラルは、ユーザーが注意を払うのをやめるため、ダイアログボックスを使いすぎないことです。