Image credit: Dadapixel
サイトやアプリにおける典型的なフォーム（もしくはダイアログボックス）には、通常いくつかのボタンがあります。ほとんどのケースで、ユーザーは２つの選択肢を目にします。１つはユーザーの主となるタスクを表し、一方は付随する副次的なタスク（フォームに入力した内容の取り消しやキャンセルなど）を表します。
この記事ではアクションボタンに関する基本的なUXについて概観し、デザイナーの間でよくある質問である「OKかキャンセル、どちらのボタンが最初にくるべきか」に答えます。
エラー防止
Jakob Nielsen氏のユーザビリティ・ヒューリスティックによると、「丁寧なデザインによって、最初の段階で問題が起こることを防止する」とあります。ユーザーが突発的に間違ったものを選択してしまうかもしれない状況を排除できるように努力する必要があります。
濃淡で視覚的な区別をつける
２つのボタンの違いを明確にするために、ボタンに視覚的な区別をつける必要があります。より注目を集めたいボタンの方を濃いトーンにしましょう。
「Submit（登録）」ボタンの視覚的区別。Image credit: Lukew
明瞭で識別可能なラベル
良いダイアログボックスはユーザーに実行したいアクションを問う事についてだけではありません。それぞれの選択肢を可能な限り明瞭にする事でもあります。それぞれのオプションに識別可能なラベルを持たせる事が重要である理由がここにあります。
- そのボタンが何であるかを説明するためにボタンに名前をつける事は、しばしば一般的なラベル（「OK」のような）を利用するよりも良いです。
- いつでも「Yes」や「OK」の代わりに動詞を使いましょう。なぜならボタンが説明文やタイトルの文脈の外でも意味をなすであろうからです。
下記はやってはいけない事の良い例です。
動詞を使えるときは、「Yes」や「OK」は使わないようにしましょう
ダイアログボックスに関する別の例をご紹介します。最初の例では、「Discard draft?（下書きを破棄しますか？）」という否定的な質問に対し「No」が答えになりますが、しかしその後何が起こるのかを提示していません。より良いアクションの組み合わせは明確な「Cancel」と「Discard（破棄する）」です。積極的な行動を示す「Discard（破棄する）」は明確に決断の結果を示しています。
Image credit: Material Design
ボタンがポジティブな内容の場合（送信ボタンなど）
先ほど述べたように、主となるボタンは視覚的な区別をつけるため、濃い色をつけます。２つ目のボタンはより薄いトーンにするべきです。２つ目のアクションの視覚的な存在感を減らす事は、潜在的エラーのリスクを減らし、よりユーザーを正しい結果に導きます。
「Save（保存）」はポジティブな行動
ボタンがネガティブな内容の場合（削除など）
取り返しのつかない行動に視覚的な重みを持たせる事は危険です。ユーザーは安全な選択肢として取り返しのつかない行動を選択してしまい、誤って先にすすんでしまいます。例えば、ファイルを置き換える場合、そのタスクにかかる手間や時間は重要ではありません。本当に重要なのは、ユーザーが自身の決断を後悔しない適切なアクションを選択する事です。
「Cancel（取り消し）」はこのダイアログでは副のアクションですが、より視覚的な重み付けがされています。
「Delete」や「Erase」の作業はさらなる注意を必要とします。誤って何かを削除して、元に戻せないと気付いた事はありませんか？ しばしばユーザーは確認メッセージを読まずに、ボタンを押してしまいます。そしてたとえ彼らが注意書きをちゃんと読んだとしても、それでもなお、誤ったボタンをうっかりクリックしてしまうものです（「Cancel」のつもりで「Delete」など）。
アクセシビリティや文化バイアスなどによる決断の混乱に邪魔されることなくユーザーが利用できる、単一で明確な選択肢を提供するべきです。
LinkedInのダイアログは大変明確で曖昧さがありません
しかしながら、ユーザーの重要なデータにまつわる致命的な操作については、根本的に異なるメカニズムをデザインすべきです。ユーザーがうっかり押してしまうようなアクションボタンを利用する代わりに、テキスト欄を用意し、操作確認のため「delete」という文字を入力してもらう方式などを採用すべきでしょう。
副のアクションを無効なボタンとする場合
非アクティブ（もしくは無効化された）ボタンはユーザーにその操作が可能である事を知らせる必要がある時に有用です。ボタンが文脈になくても、ユーザーはその選択肢がいつか利用可能になる事を知ることができます。
無効化されたボタンの使用条件がメモとして記載されていることもあります
もう一つの無効化ボタンの良いユースケースはユーザーが立ち入ってしまった状況からの「緊急脱出」です。「Undo（やり直し）」オプションはユーザビリティについての最も偉大な進化の一つです。なぜならユーザーは通常、望ましくない状況から脱出したい場合に「Back（戻る）」ボタンの利用を好むからです。
やり直しは望ましくない状況からの緊急脱出
「OK」と「キャンセル」、ボタンの順序はどうするべき？
「OK」と「Cancel」ボタンの順序の議論はデザイナーの間でとても有名です。「主のアクションボタンが副ボタンの前にくるべきか、後ろにくるべきか？」。実際のところパフォーマンスについてもユーザーの好みについても、重要な違いはありません。
Apple、GoogleとMicrosoftのガイドライン
プラットフォーム内での一貫性はダイアログボタンをデザインするときに最も考慮すべき重要な事です。悲しい事に、「OK」/「Cancel」ボタンの順序についてはWindows User Experience Guidelines、Apple Human Interface Guidelines、Google Android Guidelinesとそれぞれ異なります。
MicrosoftのWindows向けガイドラインでは以下の順序を提案しています。
・「OK」/ [Do it] /「Yes」
・ [Don’t do it] /「No」
・「Cancel」
※Do it/Don't do itは任意の行動
つまりWindowsのプラットフォームでは「Cancel」が常にOKボタンの右側にあるという事です。
Microsoft Windowsのダイアログボックス
Apple MacOSガイドラインでは
処理を開始するボタンは一番右に配置する。キャンセルボタンはそのボタンの左に配置する
となっています。MacOSユーザーにとって「Cancel」は「OK」ボタンの左にあるのです。
アップルのMacOSのダイアログボックス。Image credit: Apple
Google Androidガイドラインでは
ダイアログにおいて拒否するようなアクションは常に左に配置する。拒否するようなアクションはユーザーを一つ前の状態に戻す。肯定的なアクションは右側に配置する。肯定的なアクションはダイアログを開いたユーザーの目的に向けて先へ進める
と記載されています。つまりAndroidでは、「Cancel」ボタンは「OK」ボタンの左にあるという事です。
Google Androidのダイアログボックス。Image credit: MaterialDesign
もしあなたがこれらのプラットフォームの一つでアプリケーションをデザインしているなら、選択肢はとても明白です。プラットフォーム側が指示する通りにしましょう。
なぜでしょうか？ それはあなたのアプリのちょっとした工夫よりも、一貫性のあるデザインでユーザーの期待に沿った方がはるかに時間の節約になるからです。基準から逸脱してしまった場合、彼らがボタンの使い方を誤った際などに、数分間（致命的な間違いであれば数時間）の不要なコストを生じさせてしまう事になります。
Webベースのプラットフォーム
もしあなたがWebベースのアプリケーションをデザインしているなら、決断はより難しいものとなります。ほぼ確実にあなたのユーザー層を見て一番使われているものに寄せていくことになるでしょう。そのためにWebの統計を利用する事もできるでしょう。
しかしどのようなボタン配置をあなたが選択したとしても、OSの違いによりすべてのユーザーにとって一貫したものにはなり得ません。この場合ボタン配列はユーザビリティの観点に基づいて選択されるべきです。ユーザーによる情報の理解についての基本的な瞬間を把握してみましょう。
OK―Cancelの順序での指示は西洋においての読み書きの文章構造に即しています。「私に同意しますか？ー はい / いいえ」といった質問をされた場合に。
前向きな選択肢が最初にきて、後ろ向きな選択肢はその次になります。さらには、ユーザーが「Cancel」よりも「OK」を必要としているという推測があるので、ボタン選択にtabキーを使うようなキーボード重視のユーザーが１つ少ないキーストロークで好ましい選択を得る事ができるように、「OK」の選択肢が最初に配置される事はより良い事です。
一方、Cancel―OKの順序は論理的流れという観点で筋が通ります。なぜならダイアログはその結論を持って「終わる」ので、その最後の要素は主となるアクションボタンであるからです。
緑の矢印が視線の流れを示しています。
どちらの選択もそれぞれの主義主張で議論は可能ですし、どちらを選んだとしてもユーザビリティの崩壊を招くほどのことではありません。
つまり、ほとんどのケースでプラットフォームのGUIガイドラインを従うべきですが、Webベースのアプリケーションとなると、あなたはどちらの配置がユーザーにとって最も最適か考える必要があり、それを知るためにはユーザーに向けてテストしていくしかありません。
まとめ
ユーザーにとってほしい行動を起こすようにユーザーを誘導するのがボタンの役目です。ボタンのUXデザインのほとんどの議論が「認識しやすさ」と「明白さ」に収束していくのはそのためです。
サイトやアプリを考える際、忙しいユーザーと会話をするようなイメージで考えてみて下さい。ボタンはその会話にとって極めて重要な役割を果たすものです。
