🚨

効果的にアラートを使おう

2024/01/31に公開

はじめに

ゆめみiOS研修に APIのエラーハンドリング のセッションがあります。

https://github.com/yumemi-inc/ios-training

このセッションでは次のような課題があります。

APIエラーが発生したらUIAlertControllerを表示する

このセッションをレビューする過程で、アラートの表示はこれで良いのだっけと疑問に感じることが増えて、ヒューマンインターフェースガイドラインを読み直し、アラートに対する考えが深まりました。

ヒューマンインターフェースガイドライン

ヒューマンインターフェースガイドラインのアラートのページを繰り返し読みました。

https://developer.apple.com/jp/design/human-interface-guidelines/alerts

このページに書いてあることはガイドラインとしてとてもよくまとまっています。
特に重要な部分とガイドラインだけではわかりにくかった部分について書き出しています。

ベストプラクティス

一番重要な指針は次のメッセージであると感じました。

ユーザがアラートを軽視する

社内LTでのフィードバック

この記事の元になるスクラップをゆめみ社内でLTしました。

https://zenn.dev/ykws/scraps/1bd34b3f414206

そこで頂いた様々なフィードバックの一つとして、「これが一番重要な指針だと思う」というもので、その着眼点が印象的で、しっくり来ています。

ガイドラインを読めば読むほど、実際のところ具体的にどうすべきかということに関しては触れていないと感じました。それはなぜかというとアプリごとにコンテキストが異なるからだと考えます。ユーザがアラートを軽視するようにならない、という指針が重要であり、特定のユースケースでアラートを表示することの良し悪しを絶対評価するのは難しいという観点を持っています。ユースケースに注目するのではなく、そのアプリの中でユーザにとって立ち止まって欲しい部分で表示して欲しいという願いがあります。ユーザがアラートが表示されることに慣れてしまわないように表示するタイミングや頻度について設計すべきだとこのガイドラインは示していると解釈します。

アラート以外の情報提供の方針についてもガイドラインは示しています。

情報のみを提供する必要がある場合は、関連するコンテキスト内で情報を伝達する別の方法を検討してください。

キャッシュされたデータやプレースホルダのデータを表示したり、ユーザの操作を中断しない形で問題について説明するラベルを表示することができます。

アラートは OS 標準の UI を提供し、便利な側面もありますが、ユーザの操作を中断する効果があり、その頻度が多いと慣れてしまい、アラートが表示されたけど、内容を読まずにボタンをタップしてしまい、何が書いてあったか覚えていない、といったケースを生んでしまいます。

なお、 Apple 純正のアプリを確認するとその対応方針に一貫性は見られませんでしたが、アラートを利用するケースは少なく感じました。
例えば、通信エラーが発生した場合、キャッシュがあればそれを表示し、なければ、プレースホルダーに機内モードであることを表示するなどし、アラートは表示されないケースがほとんどでした。

コンテンツ

簡潔かつ明確に状況を説明するタイトルにする

タイトルについて詳しくガイドラインを示してくれてはいるものの、具体例がなくてよくわかりませんでした。
過去のヒューマンインターフェースガイドラインに触れた記事からヒントを得ました。

https://postd.cc/how-to-write-an-error-message/

図より次のような内容がタイトルの一例になっています。

Secure Empty Trash permanently erases the items in the Trash. Are you sure you want to permanently erase them?

“確実にゴミ箱を空にする”を使用すると、“ゴミ箱”にある項目が完全に消去されます。完全に消去してもよろしいですか?

macOS 向けなので iOS 向けにはもう少し情報を削る必要があるかもしれません。こういう方向性で捉えておくと、タイトルに「エラー」とつける発想は生まれにくくなる気がしています。

ボタン

ボタンについてはガイドラインを読んでもらえたら理解しやすいと思うのでこの記事では触れません。

プラットフォームの考慮事項

ユーザが意図したアクションに関連する選択肢を提示する場合は、アラートではなくアクションシートを使用する

この指針があると選択のためにアラートを表示する選択肢を除外できると思います。

おわりに

このガイドラインに準拠することをアプリ単体で実践されるだけでは不十分で、モバイル全体でどのアプリも足並みを揃えることで効果が増していきます。仮に、自分の関わるアプリ以外がアラートを頻繁に表示していたとすると、どんなに自分のアプリで気をつけていても、ユーザの体験としてはアラートは軽視することになってしまうと思います。

デザインを考える人は別にいて、上がってきたデザインを実装するといった担当分担をしているチーム構成も多いと思います。そういったケースでもガイドラインをベースに根拠を示して、アラートを効果的に利用できるようにデザインへのフィードバックも行えるようになったら嬉しく思います。

大事なのは、特定のユースケースに注目するのではなく、アプリ全体でアラートの数が増えるようなら、その中で優先度をつけて、より重要でユーザの操作を中断して欲しい箇所にアラートの頻度やタイミングを見直し続ける活動が必要になっていると考えています。

GitHubで編集を提案
株式会社ゆめみ

Discussion