キャンセルのキャンセル問題を解決するための５つのテクニック

よくこういう問題をまとめた記事がありますがこの記事はその解決の手順等々を短くまとめたチェックリストという立ち位置です。

理論を理解したいというよりは理論を軽く知っておいたり、頭が回ってない時に自分の成果物がキャンセルのキャンセル問題を作っていないかを確認するためにお使いください。

目次
キャンセルのキャンセル？
- 1,OKを使わない
- 2,ボタンのキャンセルはそのままで
- 3,実行したらどうなるかを教える
- 4,指示に従わない系ボタンは左、了解系は右
- 5,ダイアログは極力使わない
- おまけ
- まとめ
- おまけのおまけ

**

キャンセルのキャンセル？**

キャンセルのキャンセルってなんだっけ？
画像で示すとこれです。

破壊的行為時(破棄、消去、中断等々)によく出てきます。
これを回避するためには5つのテクニックが必要です。

それを１つ１つ説明していきましょう。

1 OKは使わない**

ダイアログがただの情報を伝えるものでないとしたらOKはあまりよくないです。
OKには了承の意味がありますが、実は
「OK、行為を実行して。」
と
「OK、私はそれを理解したよ。次は実行ページに飛ぶんだね。」
と二つの意味が混在しているのです。
どちらで捉える方が多いのかは分かりませんがappleの公式デザインガイドラインHIGでは以下のように書かれているので無視は出来ません。

デフォルトのボタンのタイトルが、ボタンが実行するアクションを反映していることを確認してください。アラートが単なる情報である場合を除き、デフォルトボタンに[ OK ] を使用しないでください。OKの意味は、ユーザーが何かを実行したいと確信しているかどうかを尋ねるアラートであっても不明確になることがあります。例えば、んOKまたは「OK、私は今、自分の行動が引き起こされていた負の結果を理解する」「OK、私はアクションを完了したい」という意味？Erase、Convert、Clear、Deleteなどの特定のボタンタイトルは、ユーザーが実行しているアクションを理解するのに役立ちます。（HIGをgoogle翻訳）

加えてここにある通り動詞と同意行為は一緒な方が自分の行為の結果が予測しやすいらしいでこれを踏襲しましょう。

以下が例です。

ただ、繰り返しになりますが情報を伝えるためのダイアログにおいてはOKでも大丈夫ですが、また違う問題がありますのでそれは後述します。

2 ボタンのキャンセルはそのままで

HIGでは破壊的行為(まさに今の破棄フローとか)ではキャンセルで統一するようにと書いてあり、またキャンセルはアラートにくっついているので意味としてアラートの否定語として機能するので問題がありません。

ただ、キャンセルは普段のボタンでも使用される文言なのでそれを回避したり、破壊的行為ではないからと文言を分ける場合は閉じるとかが良いと思います。
戻るだとどこに遷移するか分からない人に不安が残りますが、閉じるならそのダイアログが今までのページにかぶさるように表示されていると表現できます。

また、ものによってはヤバいものをいじってしまう時とかはもっと説明が欲しかったりしますよね。

その場合のパターンも一応用意しましょう。

3 実行したらどうなるかを教える

もし上で挙げた例に則る場合、破棄したら何が起こるかを詳しく説明してあげるとキャンセルのキャンセル問題にある「自分がどんな行動を実行するのかわからない」という思いが薄れボタンの着地点が分かりやすくなります。

以下が例です。

しかし、言わずもがな分かるみたいなものは書かない方がいいです。認知不可でググると分かりやすいです。

次に上記のものより大切ではありませんが推奨したいルールです。

4 指示に従わない系ボタンは左、了解系は右

これはHIGもといapple製品の基本原則であり、マテリアルデザインもこれを踏襲しています。
実際HIGにははこう書かれています。

ユーザーが期待する場所にボタンを配置します。
一般的に、人々が選択する可能性が最も高いボタンは右側にあるべきです。デフォルトのボタンは常に右側にあります。通常、キャンセルボタンは左側にあります。

これは個人的見解ですが、人間の前腕の筋肉は螺旋を描いており、いいねの形を手で作った場合に手の平が上になるように回す行為(外転)はやりにくく、手の甲が上になるように回す行為(内転)はやりやすくなっているのですが、その話を適用しているのだと思います。

私としては筋肉の話だけではなく皆がHIGやマテリアルデザインに則ればそれが共通認識になり、より楽にアプリを使えるようになるので推奨したいです。
一応HIGのこれのページをここに貼っておきます。

https://developer.apple.com/design/human-interface-guidelines/macos/windows-and-views/alerts/

５ ダイアログを極力表示しない

基本に立ち返って、ダイアログを表示すべきかを検討するのも一つの手です。
１番目のトピックで情報伝達を目的としたダイアログについて触れましたが、HIGでは直接以下のように書かれています。

情報を提供するためだけにアラートを使用しないでください。ユーザーは、有益ではあるが実行可能ではないアラートによって中断されることに感謝しません。情報アラートを表示する代わりに、情報を表示する他の方法を検討してください。たとえば、メールサーバーの接続が失われた場合、Mailはサイドバーに警告インジケーターを表示します。ユーザーは、状況に関する詳細情報が必要な場合は、警告インジケーターをクリックできます。

アプリやWebサービスを利用する時に一番行いたいのは新機能の確認ではなく、そのプロダクトを使うことであったりします。
また、ボタンを押さないと消えないダイアログに体験を邪魔されるのは純粋に嫌な気持ちになるでしょう。

警告インジケーターと同じく別枠を作りニュース等のテキストとして邪魔せず知らせるのが一番であると思います。

どうしても表示させたい/させないといけない場合はダイアログ外をクリック(タップ)したら消えるマテリアルデザイン的な表現をしたり、勝手に現れて勝手に帰っていくようにするといいでしょう。

まとめ

ダイアログはなるべく使わず、使う場合は分かりやすく誤解を与えないようにしよう。自分の備忘録用なので優しい目で見ていただけると幸いです。
また、goodpatchのusagimaru⌘さんの記事は大変参考になり、それがきっかけでこの記事を書いていますのでご了承してくださればと思います。

参考

usagimaru⌘さんの記事
https://goodpatch.com/blog/dialog-design/#i-8
キャンセルのキャンセルについて別途参考にした記事
https://kudakurage.hatenadiary.com/entry/2015/12/17/215205
HIG
https://developer.apple.com/design/human-interface-guidelines/macos/windows-and-views/alerts/
マテリアルデザイン
https://material.io/components/dialogs/#full-screen-dialog

おまけ

本当に豆知識
マイクロソフトのはキャンセルを右、実行を左と今回書いているのと逆にしているが、これは人が左側から読むのをベースにしていると思われる。

日本語が右から読むのは巻物時代の名残で、左手で紙を抑え右手で書くから。
昔の看板が右から読むのはその名残で、1行1字の縦書きとし右から書いていたからだそう。
逆に英文の縦書きは1行1文字の縦書きで左から書くそうな。

※アカウント移動に際し再掲載いたしました。
もし抜けや他のオススメのテクニックがあった場合はコメント欄で教えていただけると幸いです。