モバイルアプリの効果的なアクセス許可要求のためにデザインで考慮すべき3つのこと
モバイルのアクセス許可要求が適切にデザインされていないことがよくある。アクセス許可を要求する際は、コンテンツとタイミングをよく考え、ダークパターンは使わないようにし、さらに、ユーザーが自分のおこなった判断を変更できるようにしよう。
アクセス許可要求とは何か、そしてなぜあるのか
アプリは、ユーザーのモバイルデバイスでカメラや現在地、マイクなどのリソースにアクセスする前にアクセス許可を要求しなければならない。そのために、アプリは（オペレーティングシステムを介して）モーダルダイアログの形で要求を送信し、ユーザーにアクセスを許可または拒否するように依頼する。
要求の表示方法はモバイルオペレーティングシステムによって若干の違いがある。上記の例からわかるように、iOSでは、ユーザーはマイクへのアクセスを求められる。一方、Androidでは、音声を録音する許可が求められる。さらに、iOSでは、モーダルダイアログに目的説明の文字列（purpose string）と呼ばれているものも入っていて、アプリがアクセスを要求する理由の説明がある。こうした情報の表示はAndroidにはない。したがって、モーダルダイアログが表示される前にアクセスを要求する根拠を入れるかどうかはそのAndroidアプリのデザイナー次第ということになる。
アクセス許可要求により、ユーザーは自分の個人的な（かつ、機密情報の可能性のある）データを認識して、実際にコントロールできる。しかし、アクセスを許可するかどうかは重大な決断となりうる。というのも、ユーザーがそのアプリをアンインストールするか、デバイスのアクセス許可設定で自分から許可を無効にしない限り、多くの場合、アプリはリソースへのアクセスを継続するからだ。そのため、ユーザーはそのアプリが絶対に悪意をもってリソースにアクセスすることはないと信頼する必要がある。
アプリのアクセス許可要求は、いまだに適切にデザインされていないことがよくある。かなり広範なガイダンスがiOSやAndroidの開発コミュニティから提供されているにもかかわらず、だ。その理由の1つは、アクセス許可要求がUXデザインの一部とは見なされない傾向があることによる。アクセス許可自体のUIコンポーネントは、オペレーティングシステムによって決まっているからだ。また、アクセス許可要求が非常に重要である理由をUXデザイナーやアプリの開発者が腑に落ちていないというのもあるだろう。つまるところ、彼らは皆、すべてのリソースにアクセスして、そこにある優れた機能を利用したいと思っているからである。
しかしながら、アプリのアクセス許可要求も全体的なユーザーエクスペリエンスに寄与するので、他の機能と同じく、以下のユーザビリティ原則に従う必要がある：
アクセス許可要求は適切にデザインされていれば、理にかなっていて、押し付けがましくないように見える。その結果、その要求を処理する際、ユーザーはあまり考えずに済む。一方、アクセス許可要求のデザインが適切でないと、ユーザーが違和感を覚えたり、戸惑いを感じたり、イライラしがちだ。そうなると、彼らはアプリをアンインストールして、競合アプリに目を向けようとすることもある。アプリにブランド力がなく、効果的な機能を提供できていない場合はとりわけそうだろう。
デザインで考慮すべき3つのこと
アクセス許可要求の質に大きな影響を及ぼすデザインの検討事項は以下の3つである：
- アクセス許可を要求する文言
- タイミング
- 判断の変更
1. アクセス許可を要求する文言
最も良いアクセス許可要求とは、要求の背後にある根拠が明らかになっているものである。Tanと同僚は、15個のモバイルアプリについての調査で、アクセス要求の理由が説明されていると、ユーザーがその要求を許可する可能性が12％高くなることを発見した。この数値は、それぞれの要求に入っている目的説明の文字列を、説明があまり適切でなくても、ベンダーがそうデザインしたかのように、無作為に表示したり消したりすることで導き出された。
さらに興味深いのは、この研究者たちが自分たちで作成したパーティー企画アプリを使って、連絡先へのアクセスを要求するさまざまな理由についてもテストしていることだ。そこでは、最も説得力のある理由（「連絡先に入っているEメールアドレスを自動的にリストに追加するために、Party Planner（：パーティ企画アプリの名前）に連絡先の利用を許可してください」）は、最も説得力のない理由（「Party Plannerが、あなたの連絡先の位置情報によって、最も安い費用のアトラクションを示すなどの目的のために、あなたのアドレス帳へのアクセスを求めています」）に比べて、要求を許可される割合が、実に81％も上昇する結果となっている。これまで何度も述べてきたように、UXの文言は意思決定を促す。したがって、アクセス許可要求の言い回しによって、要求の承認率が2倍近くになったことはまったく驚くことではない。言葉というのはユーザーエクスペリエンスの最も重要な要素の1つだからだ。
アクセス許可要求を読むとき、ユーザーはそれとなく費用便益分析をおこなっている。この要求に許可を与えることでどれだけの利益が得られるか、また、アクセスを許可するためにどの程度アプリを信頼すればいいのかと自問するのである。つまり、デザイナーはアクセス許可要求の文言をわかりやすいものにする必要がある。とりわけ、ユーザー側が予想していなかったアクセス許可要求についての根拠を伝える場合はそうだ。ユーザーを警戒させずに、アプリがデバイスのリソースへのアクセスを必要とする理由を彼らに理解してもらわなければならない。
ユーザーが情報に基づいた選択をおこなえるように支援するには：
- コンテンツでは、専門用語を使わないようにし、システム指向の機能ではなく、ユーザー側の利点に焦点を当てよう。
- アクセス要求を許可した見返りに何が得られるのかを明確にユーザーに伝えよう。
- ユーザーに何の価値も提供せずに、リソースへのアクセスを求めてはならない。あなた方のアプリやブランドが不審に思われる可能性もあるし、監督機関からも必要以上にデータを収集していると判断されかねないからだ。
ユーザーの利点に焦点を当てた要求を書こう。アクセス許可に依存する機能について言及するだけではなく、その機能がユーザーにどう役立つかという観点から要求を組み立てよう。そうした情報があれば、ユーザーも要求を容易に理解でき、受け入れやすい。
例：
OK：Skyscanner（：格安航空券検索アプリ）があなたに合わせた航空便検索のために位置情報へのアクセスを求めています。
さらに良い：Skyscannerが位置情報へのアクセスを求めています。許可すると、最寄りの空港をすぐ選択できるようになります。
例：
OK：写真を撮影するには、Snapchatにカメラへのアクセスを許可してください。
さらに良い：Snapchatにカメラへのアクセスを許可してください。許可すると、スナップを撮って、アプリ内で友人とシェアできるようになります。
あまりにも多くのAndroidアプリが、アクセス許可要求の理由とユーザーの利点を説明することを怠っている（一方、同じアプリのiOSバージョンは完璧な説明を提供している）。Android向けのデザインをしているUXチームは、アクセス許可要求が表示される前に、画面を追加して、要求の目的を伝えることを検討するべきだ。そうでなければ、ユーザーの同意は適切な情報を得ておこなわれたものとは言えないだろう。
書き方についてのアドバイス：
- 能動態で書こう。
- ユーザーが理解できるわかりやすい言葉を利用しよう。
- アプリがアクセスを必要とする理由を説明し、ユーザーにとっての利点を伝えよう。一般的に、コンテンツの適切な表現はこんなふうになる：[アプリ]は[リソース]へのアクセスを求めています。許可すると、[利点/タスク]ができるようになります。
- アプリがアクセスを必要とする理由を説明する際には、「より優れたユーザーエクスペリエンスを提供するために」のような、あいまいな言い回しは使わないようにしよう。（ユーザーはあいまいなうたい文句には極めて懐疑的であり、不正な悪巧みをごまかそうとしているのではないかと感じることが多い）。
- Androidの場合、ユーザーが予想していない要求向けの新たな画面をデザインしよう。そうすれば、アクセス許可要求ダイアログが表示される前に、その画面で、要求の根拠と利点をユーザーに伝えられる。（そして、あなたがGoogleの社員である場合、アクセス許可のAPIのデザイン変更をして、要求をおこなうちょうどそのときに説明を入れやすくしてほしい）。
- アクセス許可要求のテストをユーザーを対象にして実施し、彼らがテキストを理解できるかどうかを確認しよう。
2. アクセス許可要求のタイミング
アクセス許可の要求は、タイミングが重要だ。表示されるタイミングによって、その要求が通常のものなのか、警告なのかをユーザーが知ることができるからだ。
アクセス許可要求には、コンテキスト関連型とシステム起動型の2種類がある。コンテキスト関連型のアクセス許可要求は、ユーザーを驚かす可能性が低い。たとえば、ユーザーがアプリで（カメラやマイクのシンボルなどの）アイコンを選択するか、住所欄をタップすると、システムからの反応として、アクセス許可要求が表示されるというものだからだ。ユーザーの行動というコンテキストに基づき、タイムリーにモーダルダイアログが表示されるため、ユーザーは要求の意図を論理的に判断できるのである。
一方、システム起動型の要求は、ある特定の時間にアクセス許可を要求するようにプログラムされているもので、多くの場合、追加のコンテキストを必要とする。システム起動型の要求の例は、ユーザーが初めてアプリを開くと、現在地へのアクセスを求めるダイアログが表示されるというものだ。システム起動型の要求は、どんなときでも表示されるようにプログラムされているので、ユーザーにとって不都合なタイミングで出てくる可能性も高い。
ユーザーはタスクの開始時に中断させられると、圧倒されたり、戸惑う可能性がある。第一印象は、ユーザーがアプリをインストールするときに形成される。それなのに、（AndroidでViberがおこなったように）そこですべての許可を求めるというのは、その慈善活動について何も説明せずに寄付を求めるようなものだ。最初の起動時には、（アプリの中核的な機能に必須の）主要なアクセス許可のみを要求し、ユーザーに追加的な機能を提供するために必要な場合にのみ、さらなるアクセス許可を求めるのがうまいやり方だろう。
アクセス許可要求のタイミングについてのアドバイス：
- すべてのアクセス許可要求を一度に表示してはならない。アプリが初めてインストールされたときに、すべてのアクセス許可を前もって要求することはやめよう。
- 可能な限り、ユーザーがアクセス許可を必要とする機能を選択したときに、それについてのアクセス許可要求を起動させよう。こうしたやり方をすることで、その要求には重要なコンテキストを、そして、ユーザーには自分でコントロールしているという感覚を与えることができる。さらに、ユーザーがアプリがその要求を必要とする理由を理解しやすくなり、許可に同意する可能性も上がる。
- ユーザーがアプリでタスクを完了しようとしているときに、無関係なシステム起動型アクセス許可要求で彼らの邪魔をしてはならない。おせっかいなモーダルダイアログはユーザーをいらつかせるからだ。また、すぐに退けられてしまうことにもなる。
- 重要性の低いアクセス許可は、ユーザーに価値を提供した後で、許可を求めよう。
3. アクセス許可の判断の変更
最初、リソースへのアクセスを拒否しても、後でその判断を変更したくなることがユーザーにはある。たとえば、メッセージアプリの電話帳へのアクセスを拒否したが、その後、連絡先を手入力で追加するのはあまりにたいへんだと気づいて、最初の判断を変更したいと思うような場合だ。
拒否したアクセス許可に依存する機能にユーザーがアクセスしようとしたときには、エラーを通知するのではなく、その機能を利用できない理由を明確に説明して、ユーザーがアクセスを許可しやすいようにしよう。アクセス許可と機能との関係がユーザーの頭の中でつながっていない場合もあるので、こうしたメッセージを提供すれば、ユーザーがそのアプリの働きについての適切なメンタルモデルを形成することを助けることもできる。
次に、そのアクセス許可の設定をオンに切り替えることのできるリンクを提供しよう。そうすれば、アクセス許可の設定内でユーザーが迷子にならずに済む。
判断の変更のためのデザインのヒント：
- 最初に拒否してしまったアクセス許可が必要になるアプリの機能にユーザーがアクセスしようとしたところで、彼らにその機能が利用できない理由を明確に説明しよう。
- ユーザーのおこなった判断を変更できる、デバイスの設定内の正確な場所へのリンクを提供しよう。
ダークパターンは使わないようにしよう
GDPRの実施により、EU市民の明確な同意が必要になったため、一部のアプリ開発者は、許可要求に同意するようにユーザーをナッジするダークパターンを実装し始めている。アプリ開発者の中には、（以下のWeChatの例のように）アクセス許可要求を情報提供のためのダイアログのように表現しようとするところもある。これらの要求は、多くの場合、ユーザーがタスクをおこなっている最中にポップアップとして出てくる。ユーザーが要求を拒否することが難しくなるようにデザイナーが意図的に仕向けている場合もある。こうしたたちの悪い手口によって、許可要求をより多くのユーザーに受け入れてもらえることもあるかもしれない。しかし、このやり方は倫理的にも法的にも怪しいものだ。その上、信頼を損ねて、長期的なユーザーロイヤルティにも影響が出るだろう。
ダークパターンは使わないようにしよう。ユーザーには十分な情報を提供して、彼らが自分自身で選択できるようにしよう。彼らの意思を尊重しよう。また、ユーザーが後で判断を変えられるようにいつでもサポートできるのだということを覚えておこう。
要約
アプリのアクセス許可要求によって、ユーザーは自分のデータをコントロールし続けることが可能だ。ユーザーは、アクセス許可要求を受け入れるかどうかを判断するときに費用便益分析をおこなう。彼らがイライラしたり、警戒したりせず、状況をコントロールしていると感じられるように、デザイナーは利点を伝える方法と要求をおこなうタイミングを考えることが重要だ。また、ダークパターンを避け、代わりに公正な選択肢と、後で判断を変更できる機能をユーザーに提示すべきである。
モバイル通知と関連するトピックについて、さらに詳しくは、我々のレポート、『UX for Mobile Applications and Websites』を読んでほしい。
参考文献
Tan, J., Nguyen, K., Theodorides, M., Negrón-Arroyo, H., Thompson, C., Egelman, S. and Wagner, D. (2014). The effect of developer-specified explanations for permission requests on smartphone user behavior. In Proceedings of the 32nd annual ACM conference on Human factors in computing systems – CHI ’14 (Toronto, Ontario, Canada, 2014), 91–100.
Android developer guidance: https://material.io/design/platform-guidance/android-permissions.html
iOS developer guidance: https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/requesting-permission/
