素朴な疑問。システム系デザインにおける「確認ダイアログ」の扱い デザイン覚書

日々、管理画面やらアプリやらを作成している私です。
日々いろんな方と、お話をしていて気づきを得ております。自分では当たり前すぎて全く気がつけないので、本当にありがたいです。

で、タイトルなのですがアプリ開発に携わるときに、タイトルの疑問を聞かれました。

「キャンセル」に絶対ダイアログを挟みますよね。なぜですか？

ユーザーは、キャンセルを選んだのだからすぐにキャンセルにしたいはずだし、確認事態がそもそも面倒なのですが。なるほどwわかる。
しかし、実際はキャンセル選択で「本当にキャンセルしますか？OK/キャンセル」ばかりと。

開発を行っている会社で働くデザイナー的に、最初から思考にセットされていたので、気が付きませんでしたが記載していきます。

理由としては、下記が考えられます。他にもあるかもしれません。
●ユーザーさんへの、行動に対しての結果の提示
●ユーザーのデータが消えることと、お客様対応

ユーザーさんへの、行動に対しての結果の提示

まずは簡単に調べてみましょう。標準を知ること、既存サービスを調べるのは大事なスキルです。

Instagram:記事を作成してキャンセルした場合「このまま戻ると、編集内容は破棄されます」「破棄/下書きを保存」「キャンセル」

facebook:記事を作成して、キャンセルした場合「この投稿の下書きを保存しますか？」「今破棄すると、投稿が失われます。」「下書きを保存/投稿を破棄/編集を続ける」

Twitter: 何か記載して、キャンセルした場合「削除/下書きを保存」「キャンセル」

「ユーザーが行った行動＝記載した」を、「キャンセルする＝システム的にデータを削除する」ときに確認している　になります

この行動を行った結果どうなるかを教えている状態です。
キャンセルに限ったことではないのですが、ユーザーさんがなにかのアクションをおこなったときに、結果がどうなるかを教えているデザインとなります。

ダイアログにするのか、アクションシートにするのかは、トレンドや、画面の状態によるので、そこは別の話として一旦除外します。

キャンセルにより、「データが消える＝ユーザーさんの不利益」と考えて表示していると考えているのです。

この対策として、「下書きを保存しますか？」というトリガーが用意されています。このトリガーをもとにユーザーは、下書きを保存できるのだなと意識し、自分の意思で自分の作成したデータを削除・保存の選択が行えるという状態になっているからです。

ただ開発と考えると、下書き保存が必要であるという要件が絶対に必要でない場合、削除される可能性があります。
下書きを保存するという行為は、アプリないしサーバー側にユーザーの下書きデータを保持する必要があるため、記事の投稿とは別の機能となるのです。現在ではアプリやサービスに当たり前に、新規作成、編集、投稿、下書き保存があるため、開発会社以外の方にとっては、記事を投稿するという機能には、この下書きまでがセットであるという認識がある場合があるため、要件定義でちゃんと定義します。

ユーザーのデータが消えることと、お客様対応

私が携わるアプリサービスは、B to B to C であることが多いのですが、そこに必ず入ってくるのはアプリの運営コストがかかるということです。

ユーザーデータが消えると起こる現象 → サポートへの連絡が増える

アプリ運営側としては、運用コストをあげることはあまり歓迎していない。ということもあげられます。

書き方に誤解が生まれそうなのですが、お客様の対応をしたくないということではありません。

人員をそんなにさいていない初期サービスの場合、運用担当者が少数で対応している場合もあり、1日に対応できる数がかぎられている。無理ゲーになる可能性を防ぎたいという事情があったりします。

なので、あらかじめユーザーに不利益が起こりそうと判断したものの場合には、ダイアログで確認を促しているのです。

具体的に確認ダイアログをだすのはどんなとき？

では、具体的にどういうときにダイアログ確認をするのか？わたしの主観ですが以下となります。思い出せていないだけで、他にもあるかもしれません。

1. ユーザーデータを削除するとき
2. お金の支払いが発生するとき
3. 退会などの手続き（ここには、データ削除と支払いが絡む場合があるので、上と同じかもしれません）

「キャンセル」に絶対ダイアログを挟みますよね。なぜですか？のちゃんとした回答になっているのかはわかりませんが、このような事情があるということでした。

また、ターゲットによってユーザーのストーリーや価値が変わる、もしくはなにか変化があると、またこう言ったものは変わっていくのかもしれません。