キャンセルのキャンセル問題から考えるダイアログデザイン

UIというものは大半がテキスト要素で構成されています。テキスト要素の設計はUIの要といっても過言ではないほどに重要な領域です。今回はそのテキスト要素、すなわち「文言」をテーマに、iOSにおけるダイアログ設計を考察してみます。題材はiOSの例が中心になりますが、ここで紹介・解説する内容はWebやAndroidなど他のプラットフォームのUIデザインにも活かせるはずですので、ぜひ参考にしていただければと思います。

ダイアログとは

ダイアログとは、ユーザーと文章で対話するユーザーインターフェース要素です。それらのうち、アラートはエラーや警告をユーザーに知らせて、それに続く行動（同意・否定など）を問いかけるために使用します。ユーザーは自身の作業を他の誰かに奪われたいとは思っていないので、アラートの多用には十分に気をつける必要があります。

『キャンセルのOK』と『キャンセルのキャンセル』

まずはこちらの画像をご覧ください。

このアラートは、説明文で作業の中断の是非をユーザーに問うた上で、アクションとして「キャンセル」と「OK」の二択を示しているアラートの例です。これを見て何か違和感はありませんか？

この文脈では、「編集内容のキャンセル」という処理を続行しても良いかをユーザーに確認しています。続行に同意したい多くのユーザーは直感的に同じ表記の「キャンセル」を押したくなるでしょう。しかしそれでは編集のキャンセルが実行されません。

このキャンセルボタンが意味するのは、「『編集内容をキャンセルする』のキャンセル」なのです。つまり、ユーザーが望み通りに編集内容を破棄するためには、反対側のOKボタンを選ぶべきなのです。このような「キャンセルのキャンセル」は二重否定で意味がややこしくなるので避けなければなりません。

ここで「キャンセルのキャンセル」にならなければ良いということで、次のようにボタン名を変えてみました。

これでもう迷うことは無くなりましたか……？

私はこの修正は誤りだと判断します。「はい」「いいえ」は結果を予想しにくい表現なので、ダイアログのアクションボタンに用いることはあまり適切ではありません。

さらにアラートあるあるを攻めてみたいと思います。『これでは説明が足りない！』という周りからのツッコミに応える形で、次のように説明文を拡張してみました。

はい。いや、いいえ？

このアラートは最終的に『保存することをおすすめします』と問いかけているので、そうしたいユーザーはきっと直感的に「はい」を選ぶでことしょう。しかし、「はい」を選択すると本来の問いかけの内容である『編集内容をキャンセル』が実行されてしまうので、これでは編集内容の保存どころか逆に破棄が実行されてしまいます。これはユーザーにとって最悪の展開です。

短く論理的、かつ適切な文言をデザインする

先のアラートの例は、文言が不適切であることに由来する文言バグです。UIデザインのプロセスにおいて文言デザインは比較的軽視されがちにあるようですが、いくつかの点に注意すれば文言バグは防ぐことができます。

もういちど始めのアラートを見てみましょう。

このアラートはそもそも説明文が適切ではありません。そして選択肢のボタン名も間違っています。

まず、説明文中に「キャンセル」という言葉が堂々と使われている事が不適切です。キャンセルは否定的ボタンの名前によく使われる言葉であるため、これと混同するような問いかけは避けるようにしてください。

キャンセルの意味を混同する例としてよくあるのは、通販アプリでの注文のキャンセル処理において『注文をキャンセルしますか？』という問いかけです。ここでいう「キャンセル」が意味するものは問いかけの否定ではなく「注文の取り消し」になります。意味を混同するならこれをわざわざ横文字にする必要はなく、ここは素直に「取り消し」と日本語で表記すれば良いのです。「キャンセル」はGUIの予約語のようなものであるため、キャンセルボタン以外の用途では「キャンセル」という語句を用いることは避けた方が良いでしょう。

次に、ボタン名は説明文に対応した動詞にするべきです。先ほどの例で採用した「はい」「いいえ」は動詞ではないため、ユーザーはそのアクションの先の結果を予想しにくく、意味を理解するのに動詞表記よりも時間がかかってしまいます。

このような論理的でない文言をボタン名として採用するのは適切ではありません。そして先ほど述べた通り、否定的アクションの名称は可能な限り「キャンセル」に統一しましょう。この「キャンセル」という言葉はプラットフォーム（iOS, macOSなど）で統一の否定表現です。

同意的ボタンは文脈として「OK」で違和感がなければそれを、もう少し具体的に表記する必要がある場合は、「説明文が問うている内容を表す動詞」をそのままボタン名に採用しましょう。

「〜する」表現をなるべく避け、簡潔に表記する

ボタンの文言デザインで注意したいのが、日本語の「〜する」という表現を“なるべく”避けることです。「キャンセルする」「破棄する」「削除する」「選択する」「ダウンロードする」……これらはいずれも「する」が余計にあり冗長に感じられます。文脈次第だとは思いますが、たいていは「〜する」の形でなくても意味は通じるので短く表記しましょう。

一方で、アプリのデザイン言語によっては「〜する」表記などが望ましい場合もあるかもしれません。例えば、「続行」よりも「続ける」の方が柔らかい印象を与えますし、実際にこちらが用いられることが多い印象があります。

説明文には丁寧語などまわりくどい表現は多用しないことが望ましいでしょう。先の例では『〜してもよろしいですか？』という問いかけでしたが、この文脈を読み解くと、編集内容を破棄することを決定するのはユーザーなので主語はユーザーになります。この説明文は『（あなたは）〜しますか？』と短縮することができます。

ユーザーは文章を読みたいのではなく、自身が望むコンテンツにアクセスしたいだけなのです。回りくどい言い回しはユーザーをコンテンツから遠ざけてしまいます。

以上のことから、このアラートは『キャンセルしてもよろしいですか？』を『破棄しますか？』と書き換えることができます。そして同意的ボタンの名前は「破棄」とすることができます。

いかかでしょう？ 最初のアラートに比べてかなりわかりやすくなりましたが、まだ改善の余地がありそうです。

破壊的アクションを考慮する

このアラートの同意的アクション「破棄」は同時に破壊的アクションでもあるので、Destructive スタイル（赤色のボタン）とします。

するとこのようになります。

「破棄」は破壊的ですが、同時にこの文脈では同意的でもあるので、HIGに従って右側に配置します。破棄の否定である「キャンセル」は左側に配置します。
（古いiOSでは破壊的アクションを左側に置き、逆にキャンセルを右側に置くパターンも見られましたが、iOS 10ではホーム画面のアプリ削除確認アラートがそうであるように、Destructive Styleを採用しているなら破壊的アクションは右側配置でも良いと思われます。）

それっぽくなりましたが、実は大きな間違いがあります。

アクションシートの役割

アラートはこれで完璧にも見えますが、実はアラートであることがそもそも間違っていました。アラートは、ユーザーが意図せずに発生したイベント（エラーなど）に対してどう対処するか、ユーザーの判断を仰ぐために利用するモーダルビューの一種です。それを踏まえると、今回の「編集内容の破棄」という文脈には当てはまりません。このアラートはユーザーが能動的に閉じるボタンなどを押した際に現れる確認アラートなので、「ユーザーが意図せずに発生したイベント」とは言えないのです。

ここでアクションシートの出番となります。アクションシートはユーザーに二つ以上のアクションを提示してその判断を仰ぐことができるダイアログです。今回のように、ユーザーアクションに連動したコンテンツ破棄を問うような場面では最適です。また、アラートの利用が考えられる場面であったとしても選択肢が多い場合にはアクションシートの利用を検討してください。

アクションシートは必ずキャンセルに相当するボタンを一つ持っていて、選択肢はキャンセルを含め二択以上になります。ユーザーはいつでもアクションの実行を中断する権利を有しています。

かなりそれっぽくなってきましたね。

アクションシートのボタン配置を考える

先ほど完成したアクションシート。さらに保存するかどうかを同時に問うても良いかもしれません。そのためのボタンを一つ追加しようと思いますが、以下のように二通りが考えられます。

A	B
破棄（破壊的アクション）が上、第三選択肢が下	破棄（破壊的アクション）が下、第三選択肢が上

「破棄」を上に配置する方が良いか、あるいはその逆か。参考としてAppleのMail, Twitter, Facebookでの事例を比較してみるとこのようになります。

Apple Mail	Twitter	Facebook
破棄（破壊的アクション）が上、第三選択肢が下	破棄（破壊的アクション）が上、第三選択肢が下／Mailと共通	破棄（破壊的アクション）が下、第三選択肢が上／Mailと逆、キャンセルボタン名が独自表現

AppleのMailとTwitterでは、破壊的アクションである破棄ボタンがキャンセルから最も遠い位置に配置されていることがわかります（これは同時に指からも最も遠い位置になります）。一方でFacebookでは保存と削除の配置が逆転しています。さらにキャンセル（Cancel）ではなく「Go Back」となっているところが大きく異なります。

Facebookのこの意図はよくわかりませんが、一般的には削除と保存を並べるアクションシートはAppleのやり方に倣うのが正しいでしょう。キャンセルボタンも「Go Back」といった独自表現ではなく、ここは素直に「キャンセル」とした方が安全だと考えます。私はFacebookのアクションシートを見たとき、とてつもない違和感を覚えしばらく考えてしまいました。その違和感の正体は標準的なMailやTwitterとは異なるボタン配置からくるもので、特に削除という危険な処理が伴う場面においては慎重にならざるを得ませんでした。

以上のことから、今回のアクションシートのデザインは「A」が正解になります。アプリのデザイン言語を定義して独自性を演出することも重要ですが、まずはプラットフォームのデザイン言語に倣うべきでしょう。

選択肢のないアラートのボタン文言を考える

アラートは時に情報を伝えるのみの役割で完結する場合があります。新機能の情報だとかを示す際にアクションボタン一つのみのアラートが用いられることがあります。このとき、アクションボタンの文言はどうあるべきかを考える余地がありそうです。「OK」ボタンにするのが一般的でしょうが、文脈によっては違う文言も検討できます。

アクションボタン一つのみの場合のボタンはデフォルトスタイル（太字）で良いと思われます。

アラートそのものに対するアクションを避ける

アラートから脱出する意味でアクションボタンを「閉じる」や「戻る」とすることは避けましょう。

「閉じる」「戻る」の文脈を考えたとき、これらの目的語は「アラート」そのものを指します。文章に直すと「アラートを閉じる」「アラートを閉じて、アラートを表示する前の状態に戻る」という意味になりますが、アラートを閉じることなんて当たり前で、わざわざ「アラート閉じる」という選択肢をユーザーに示してそれを押させる必要はありません。同意でも否定でもどんな選択肢であろうと、いずれかのアクションボタンを押したらアラートは絶対に閉じるので、ボタンを押した結果どうなるのかを説明できる言葉が望ましいです。

もしもアクションボタン名に「閉じる」「戻る」という文言を使いたくなったら、踏み止まって「OK」を採用するようにしてください。ほとんどの場合「OK」で問題なく成立します。

ダイアログを多用しすぎない

ダイアログはユーザーの作業や意識に強制介入する“モード”です。ユーザーの自由を守るためにも、システムから発せられるアラートはなるべく使わないことが望ましいでしょう。例えば起動時に表示されるお知らせアラートや、アクションの結果をただフィードバックするためのアラートなど、安易にダイアログを使用することは避けましょう。

むすび

アプリにダイアログを取り入れる場合には、次のことに注意してデザインしましょう。

☞ 簡潔で分かりやすく、一貫した文言表現を意識する

『キャンセルのキャンセル』に代表されるような二重否定表現を避けるようにしましょう。プラットフォームで用いられる表現を尊重し、表記がぶれないように注意しましょう。「キャンセル」は問いかけの否定アクションとしてシステムで広く用いられる予約語のようなものです。「キャンセル」をこれ以外の用途で使用しないようにしましょう。

アクションボタン名は結果が予測できるように動詞で表記しましょう。多くの場合、「〜する」を語尾に付ける必要はありません。

アラートのタイトルを補足する文章を記入する場合は、タイトルラベルではなくメッセージラベルに追記しましょう。

☞ プラットフォームのルールに従う

iOSやmacOSでは『同意的アクションは右側に、否定的アクションは左側に配置する』と定義されているため、情報の配置ルールを意識するようにしましょう。Windows OSや古いAndroid OSではこれが逆になるので注意してください。

またiOSでは、『破壊的アクションのボタンにはDestructive Style（赤色ボタン）を用いる』というルールがあります。削除を実施するアクションボタンが現れたらDestructive Styleを検討してください。

ユーザーが能動的に行動する場面では、アラートではなくアクションシートを用いるようにしましょう。

☞ 主役はユーザーとコンテンツである

ダイアログに限らず、ユーザーインターフェイスは主役ではありません。ユーザーとコンテンツを結ぶ橋渡し役として、彼らを邪魔せずに透過的に機能することを目指しましょう。『アラートを閉じる』のではなく、ユーザーが能動的に行動したついでにアラートも消滅する挙動が正解です。ダイアログそのものを閉じる行為をわざわざユーザーに意識させないようにしましょう。

☞ アラートを多用しすぎない

何でもかんでもアラートにすることは避けましょう。サービスからのお知らせ、お気に入り登録に成功した旨の通知、起動時の新機能の紹介など、ユーザーのコア体験を考えたときに本当にそれらが必要なのかをよく検討してください。

システム障害や通信エラーなど、予期しない致命的な場面においてアラートを用いるようにしましょう。