ボタンのラベルや配置順序のベストプラクティスとは

Nick Babich

Nickはロシアのセントピーターズバーグ出身のソフトウェアデベロッパー/ブロガーです。彼による他の記事はこちらをご参照ください。

この記事はNick Babichからの翻訳転載です。配信元または著者の許可を得て配信しています。

Primary & Secondary Action Buttons (2016-05-08)

Image credit: Dadapixel

サイトやアプリにおける典型的なフォーム(もしくはダイアログボックス)には、通常いくつかのボタンがあります。ほとんどのケースで、ユーザーは2つの選択肢を目にします。1つはユーザーの主となるタスクを表し、一方は付随する副次的なタスク(フォームに入力した内容の取り消しやキャンセルなど)を表します。

この記事ではアクションボタンに関する基本的なUXについて概観し、デザイナーの間でよくある質問である「OKかキャンセル、どちらのボタンが最初にくるべきか」に答えます。

エラー防止

Jakob Nielsen氏のユーザビリティ・ヒューリスティックによると、「丁寧なデザインによって、最初の段階で問題が起こることを防止する」とあります。ユーザーが突発的に間違ったものを選択してしまうかもしれない状況を排除できるように努力する必要があります。

濃淡で視覚的な区別をつける

2つのボタンの違いを明確にするために、ボタンに視覚的な区別をつける必要があります。より注目を集めたいボタンの方を濃いトーンにしましょう。

1xsiaj6mv5sk6yidubhafza

「Submit(登録)」ボタンの視覚的区別。Image credit: Lukew

明瞭で識別可能なラベル

良いダイアログボックスはユーザーに実行したいアクションを問う事についてだけではありません。それぞれの選択肢を可能な限り明瞭にする事でもあります。それぞれのオプションに識別可能なラベルを持たせる事が重要である理由がここにあります。

  • そのボタンが何であるかを説明するためにボタンに名前をつける事は、しばしば一般的なラベル(「OK」のような)を利用するよりも良いです。
  • いつでも「Yes」や「OK」の代わりに動詞を使いましょう。なぜならボタンが説明文やタイトルの文脈の外でも意味をなすであろうからです。

下記はやってはいけない事の良い例です。

1da5joqxwvxjug47kxm-toa

動詞を使えるときは、「Yes」や「OK」は使わないようにしましょう

ダイアログボックスに関する別の例をご紹介します。最初の例では、「Discard draft?(下書きを破棄しますか?)」という否定的な質問に対し「No」が答えになりますが、しかしその後何が起こるのかを提示していません。より良いアクションの組み合わせは明確な「Cancel」と「Discard(破棄する)」です。積極的な行動を示す「Discard(破棄する)」は明確に決断の結果を示しています。

19hoeshnyzhlljnqgrqfydq

Image credit: Material Design

ボタンがポジティブな内容の場合(送信ボタンなど)

先ほど述べたように、主となるボタンは視覚的な区別をつけるため、濃い色をつけます。2つ目のボタンはより薄いトーンにするべきです。2つ目のアクションの視覚的な存在感を減らす事は、潜在的エラーのリスクを減らし、よりユーザーを正しい結果に導きます。

14mduzwtg4iyuy6jhjqkcaq

「Save(保存)」はポジティブな行動

ボタンがネガティブな内容の場合(削除など)

取り返しのつかない行動に視覚的な重みを持たせる事は危険です。ユーザーは安全な選択肢として取り返しのつかない行動を選択してしまい、誤って先にすすんでしまいます。例えば、ファイルを置き換える場合、そのタスクにかかる手間や時間は重要ではありません。本当に重要なのは、ユーザーが自身の決断を後悔しない適切なアクションを選択する事です。

1z80r8r4lgznwnzuaxg9ogq

「Cancel(取り消し)」はこのダイアログでは副のアクションですが、より視覚的な重み付けがされています。

「Delete」や「Erase」の作業はさらなる注意を必要とします。誤って何かを削除して、元に戻せないと気付いた事はありませんか? しばしばユーザーは確認メッセージを読まずに、ボタンを押してしまいます。そしてたとえ彼らが注意書きをちゃんと読んだとしても、それでもなお、誤ったボタンをうっかりクリックしてしまうものです(「Cancel」のつもりで「Delete」など)。

アクセシビリティや文化バイアスなどによる決断の混乱に邪魔されることなくユーザーが利用できる、単一で明確な選択肢を提供するべきです。

1e-yevrbovp3xftjghm38ua

LinkedInのダイアログは大変明確で曖昧さがありません

しかしながら、ユーザーの重要なデータにまつわる致命的な操作については、根本的に異なるメカニズムをデザインすべきです。ユーザーがうっかり押してしまうようなアクションボタンを利用する代わりに、テキスト欄を用意し、操作確認のため「delete」という文字を入力してもらう方式などを採用すべきでしょう。

0hakjdlmvqtiuuant

副のアクションを無効なボタンとする場合

非アクティブ(もしくは無効化された)ボタンはユーザーにその操作が可能である事を知らせる必要がある時に有用です。ボタンが文脈になくても、ユーザーはその選択肢がいつか利用可能になる事を知ることができます。

1zxrprwxt92dhobga2tlshg

無効化されたボタンの使用条件がメモとして記載されていることもあります

もう一つの無効化ボタンの良いユースケースはユーザーが立ち入ってしまった状況からの「緊急脱出」です。「Undo(やり直し)」オプションはユーザビリティについての最も偉大な進化の一つです。なぜならユーザーは通常、望ましくない状況から脱出したい場合に「Back(戻る)」ボタンの利用を好むからです。

1qmk8lg1a2dovyfbq_xb74g

やり直しは望ましくない状況からの緊急脱出

「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ボタンの右側にあるという事です。

1tm8whka3nzumid4wvir0yq

Microsoft Windowsのダイアログボックス

Apple MacOSガイドラインでは

処理を開始するボタンは一番右に配置する。キャンセルボタンはそのボタンの左に配置する

となっています。MacOSユーザーにとって「Cancel」は「OK」ボタンの左にあるのです。

1rsgwrwvqa0ubbg7bw8rz8w

アップルのMacOSのダイアログボックス。Image credit: Apple

Google Androidガイドラインでは

ダイアログにおいて拒否するようなアクションは常に左に配置する。拒否するようなアクションはユーザーを一つ前の状態に戻す。肯定的なアクションは右側に配置する。肯定的なアクションはダイアログを開いたユーザーの目的に向けて先へ進める

と記載されています。つまりAndroidでは、「Cancel」ボタンは「OK」ボタンの左にあるという事です。

12etxyym3sok_abchqvskpa

Google Androidのダイアログボックス。Image credit: MaterialDesign

もしあなたがこれらのプラットフォームの一つでアプリケーションをデザインしているなら、選択肢はとても明白です。プラットフォーム側が指示する通りにしましょう。

なぜでしょうか? それはあなたのアプリのちょっとした工夫よりも、一貫性のあるデザインでユーザーの期待に沿った方がはるかに時間の節約になるからです。基準から逸脱してしまった場合、彼らがボタンの使い方を誤った際などに、数分間(致命的な間違いであれば数時間)の不要なコストを生じさせてしまう事になります。

Webベースのプラットフォーム

もしあなたがWebベースのアプリケーションをデザインしているなら、決断はより難しいものとなります。ほぼ確実にあなたのユーザー層を見て一番使われているものに寄せていくことになるでしょう。そのためにWebの統計を利用する事もできるでしょう。

しかしどのようなボタン配置をあなたが選択したとしても、OSの違いによりすべてのユーザーにとって一貫したものにはなり得ません。この場合ボタン配列はユーザビリティの観点に基づいて選択されるべきです。ユーザーによる情報の理解についての基本的な瞬間を把握してみましょう。

OK―Cancelの順序での指示は西洋においての読み書きの文章構造に即しています。「私に同意しますか?ー はい / いいえ」といった質問をされた場合に。

前向きな選択肢が最初にきて、後ろ向きな選択肢はその次になります。さらには、ユーザーが「Cancel」よりも「OK」を必要としているという推測があるので、ボタン選択にtabキーを使うようなキーボード重視のユーザーが1つ少ないキーストロークで好ましい選択を得る事ができるように、「OK」の選択肢が最初に配置される事はより良い事です。

一方、Cancel―OKの順序は論理的流れという観点で筋が通ります。なぜならダイアログはその結論を持って「終わる」ので、その最後の要素は主となるアクションボタンであるからです。

1lixa8bdrpo_kggt0faxa8g

緑の矢印が視線の流れを示しています。

どちらの選択もそれぞれの主義主張で議論は可能ですし、どちらを選んだとしてもユーザビリティの崩壊を招くほどのことではありません。

つまり、ほとんどのケースでプラットフォームのGUIガイドラインを従うべきですが、Webベースのアプリケーションとなると、あなたはどちらの配置がユーザーにとって最も最適か考える必要があり、それを知るためにはユーザーに向けてテストしていくしかありません。

まとめ

ユーザーにとってほしい行動を起こすようにユーザーを誘導するのがボタンの役目です。ボタンのUXデザインのほとんどの議論が「認識しやすさ」と「明白さ」に収束していくのはそのためです。

サイトやアプリを考える際、忙しいユーザーと会話をするようなイメージで考えてみて下さい。ボタンはその会話にとって極めて重要な役割を果たすものです。