キャンセルのキャンセル

photo by wootam!

キャンセルのキャンセルについて社内ブログに書いたので、こっちにも書いておこうと思います。

confirm, dialogのdesignは案外と難しいものです。
どのタイミングで表示すべきか？
どのようなメッセージを書くべきか？
どのようなアクションをユーザーに提示すべきか？
そもそも本当に必要なのか？

いろいろと考えることは多いですが、「そもそも本当に必要なのか？」という問からスタートして、ではなぜ必要なのか？と考えていけば最適な解決方法にたどり着けるように思います。基本的にDialogは邪魔なものだと思うので、表示しないのが一番です。
confirm, dialogのdesignはどうあるべきなのかというのは、基本的にはiOSやAndroidのDesign Guidelineにも書かれているのでまずはそれを読んでおけば多くの場合、最適な解を見つける指針になると思います。

ただ、今回考えてみたい「CancelのCancel」という条件下ではどうあることが最適なのかというのは、みんな試行錯誤しているという印象を受けます。
iOSやAndroidのDesign Guidelineにも具体的な方法は示されていませんが、それは提供するサービス・ツールのコンテキストによってもどうデザインすべきかが変わってきてしまうため当然であるとも思えます。
私自身、実際にこの問題に直面して改めてどのようにデザインすることがBestであるかを考えてみました。

CancelのCancel問題とは？

いわゆる「CancelのCancel」というものは何かを簡単に説明します。
例えば、何かを投稿しようと投稿画面に遷移し、何かを入力した後にBackボタンを押した場合に「このまま戻った場合、入力された内容は破棄されます。破棄してもよろしいですか？【キャンセル｜破棄する】」というようなConfirm Dialogが出るとします。
この時、Backボタンは投稿のキャンセルを表し、そのキャンセルというアクションに対してキャンセルしますか？どうしますか？というDialogを出しており「CancelのCancel」という状態が発生します。

ちゃんとテキストを読めば理解できる内容であっても、Cancel的な行動にCancelという選択肢を含んだConfirmが重なることによって、ユーザーにとっては複雑な印象にとられてしまいます。
多くのユーザーはすべてのテキストきちんと読んでいるとは限らない（多くの場合ほとんど読んでいない）ので、どんなにメッセージを簡潔にしたとしても、このような問題は生じてしまうように思います。

解決方法1（Dialogを表示しない）

解決方法はいくつか考えることができますが、まずは「そもそも本当に（Confirm Dialogが）必要なのか？」という問からスタートすべきです。
入力のキャンセル時にConfirm Dialogを表示しなくても良い状況は以下が考えられます。

• 簡単な入力なため、キャンセルしても後で簡単にやり直せる
• キャンセル時（または入力中）に自動的に（下書き）保存される
• キャンセルボタンを間違えてタップすることがほぼない
  • ユーザーが意識してBack（Cancel）ボタンを押している
  • Androidの場合は指に近い位置にBackボタンがあるためタップしやすいが、iOSの場合は左上など指から遠い位置にCancelボタンがあることが多いので、ある程度の長さの入力までなら確認せずに戻ってしまっても良いかもしれない（内容によりそう）

このような状況であれば、何も表示せずに元の画面に戻る、もしくは戻って下書きに保存しておけば良いと思います。

• Instagramの場合は入力がstep by stepのため、Cancel時の確認はなくひとつ前に戻るという感じです
• MediumはCloseすると自動的に下書き保存されます
• AllthecooksのAndroid AppではCloseボタンを押した時は確認をせずに戻りますが、deviceのbackボタンで戻ろうとした場合はConfirm dialogを表示しています

解決方法2（Dialogをわかりやすく表示する）

Dialogを表示するべきかを検討したうえで、下書き機能を提供できないなどといった場合にはDialogを表示することを検討する必要が出てきます。
その場合、どのような表示にするべきなのかを他のアプリを参考に考えてみました。

Android

LINE, Google+では選択肢を「Yes/No」で提示しています。Design Guidelineでは通常「Yes/No」のようなそれ単体で何をするアクションなのか分からないラベルはよくないとされていますが、この場合は再度削除（キャンセル）してもよいかの確認のため、これが分かりやすいと判断されて使われているのだと思います。とは言え、やはりBestな方法ではないように思います。

Twitterは下書き機能があるためSaveするのかどうかを確認するためのDialogを提示していますが、確認するまでもなく残しておくのが良い気もしますが、サービスの特性上、中途半端な下書きがたくさん生成されてしまう可能性があるため確認しているのだろうか。
私の考えではこの場合、確認せずに残しておくのですが下書きのリストとしては残さず、次書くときのプリセットとして残しておくのが良いのではと思います。その場合、すぐにリセットできるように入力内容をクリアできるボタンも用意しておくと良いかもしれません。

FacebookとYoutubeでは入力した内容に対して破棄するのか？維持するのか？という選択肢を提示しています。これは「Yes/No」に比べて明確にそのアクションを伝えているので優れていると思います。Cookpad Globalの場合も同じように「破棄する」という選択肢を用意していましたが、もう一つの選択肢が「（破棄の）キャンセル」だったためキャンセルにキャンセルが重なってしまい、ユーザーの混乱につながりやすくなっていたように思います。

iOS

iOSの場合も各サービスAndroidと同じような選択肢を用意していますが、表示のさせ方が少し違っています。
LINE, Youtubeの場合はAndroidと同じDialogで表示していますが、それ以外はAction Sheetで表示させています。iOSのDesign Guidelineではユーザーのした行動に対して選択肢を提示する場合はAction Sheetを使うことを推奨しています（Dialogはユーザーの操作と関係なく表示させたい場合に使用する）。なのでこの場合はAction Sheetを使うのが良いと思います。
Facebookのように通常キャンセルが表示されることが多い場所に「Keep」を表示するのは少し違和感があり結局キャンセルにしたという迷いがGoogle+のdesignに見て取れる気がします。
この場合、表示するならFacebookのパターンが一番良いのではないかと思いますが、そもそも必要ないとも思えます。

まとめ

なにか問題を解決しようと思ったとき、考える手順として例えば次のように考えると良いと思います。

• （観察やインタビューなどから）何が問題であるかを深く理解し言葉で説明できるようにする
• 問題となっている直接的な部分の「根源（メタ領域）」に問題がないか、または別の側面から見た場合にどういった問題や課題などがあるのかを検討する（プロブレム・リフレーミング）
• 同じような事例でどのように解決を試みているかを数多くリサーチし、それぞれのアプローチ方法を分析・研究する
• （調べた情報を元に）デザインの対象としているもののコンテキストに応じて、最も最適な解を導き出す
• 試すことのできるプロトタイプを使って、問題が解決できているかを確認する（次の改善点を見つける）

まずは「そもそも本当に必要なのか？」「無くても良い方法はないのか？」というところをしっかり考えることが重要だと思います。
これはなにもDialogに限った話ではなくすべてに当てはまる話だと思います。
それでもやはりConfirm Dialogが必要だと判断した場合は、FacebookのようにClose/Back/Cancelなどのユーザーのアクションによって入力内容が破棄されてしまう旨を簡潔に伝えて「維持する（Keep）・破棄する（Discard）」という選択肢を表示するのが良いと思いました。

ちなみに。。。
日本語で「Keep/Discard」がどのように表示されるのか見てみました。

Facebook (iOS)は「Keep=保存」！　…ちなみに保存を押しても下書きに保存などされません
Youtube (Android)は「書き込みを続ける」　…長いけど意味は分かる気がします
Facebook (Android)は「キャンセル」！　…諦めたのか…。。

ニホンゴムズカシイ…。

Reference

• iOS Human Interface Guidelines
• Google design guidelines
• Confirming & Acknowledging | Android Developers
• Deletion: Confirm or Undo? Which is the better option and why?
• Improving destructive action confirmation in iOS7