Как правильно запрашивать у пользователей разрешения в iOS

В TechCrunch вышел очень интересный и полезный пост, в котором подробно обсуждаются практические вопросы такого аспекта взаимодействия приложений и пользователей, как получение разрешений на определенные действия. Не секрет, что многие эппы пытаются выклянчить для себя самые разные права. Иногда права им на самом деле и не нужны, но бывают и случаи, в которых отказ просто убивает весь смысл приложения.

Бренден Маллиган (Brenden Mulligan), кофаундер и дизайнер мобильного приложения Cluster, рассказал о том, как команда его проекта работала над такими просьбами — так, чтобы число отказов стремилось к нулю.

Cluster — это первое нативное мобильное приложение, для которого я делал дизайн, и в ходе проекта мне пришлось изучать многие вещи, которые в вебе как-то не сильно важны. В случае веб-приложения вы просто создаете страницу, на которую заходит пользователь. Когда же речь идет о нативном опыте, то вы не только просите их скачать что-то, но еще и запрашиваете доступ к каким-то персональным или локационным данным. То есть отношения с людьми строятся совсем по-другому.

Во многом поэтому мы в Cluster уделяли много внимания небольшим взаимодействиям, с помощью которых можно было бы повысить комфорт пользователей и завоевать их доверие. И тут одной из важнейших областей, на которой мы сфокусировались, было то, как именно мы просим наших пользователей предоставить нам доступ к разным вещам на их телефоне.

Сразу главный вывод — никогда не запрашивайте разрешений до того момента, как они действительно вам понадобятся, и сделайте так, чтобы пользователю было кристально понятно, зачем это все нужно, и что он получит взамен.

Очень важно получить доступ в первый раз

Для многих приложений отказ в доступе к некоторым сенсорам или данным телефона может полностью поменять пользовательский опыт. Например, если функционирование приложения зависит от того, где находится пользователь, то отказ в получении локационных данных может сделать использование такого эппа просто бессмысленным. Можно сказать и так — если push-оповещения критически важны для того, чтобы у человека сформировалась привычка пользования вашим приложением, то отказ в доступе в самый первый раз, фактически, означает, что такого пользователя вы потеряли навсегда.

Важный момент здесь еще и в том, что разок тапнув "Don't Allow", пользователь потом не так-то легко сможет откатить это действие. Чтобы вновь выдать приложению доступ, надо будет сделать аж пять шагов, и никаких особенных подсказок для этого нет, потому просто перечислим все экраны, что ему придется пройти.

Короче говоря, если пользователь отказал в доступе, то приложение нормально работать не будет, и откатить это действие практически нереально. Это значит, что разработчики должны лезть из кожи вон, чтобы пользователь в нужный момент нажал "Allow".

Два главных подхода

Обычно приложения, пытясь получить разрешения, идут одним из двух путей.

Блицкриг (не рекомендуется)

Ну, мы все это видели. Вы открываете приложение в первый раз и затем "А можно мы будем отправлять вам push-оповещения?" и "Можно нам доступ к вашей камере?" а потом "И еще давайте доступ к контактам". Это как встретить на улице незнакомую девушку и пристать с ней с просьбой пойти с вами на свидание.

Первая версия нашего приложения Cluster делала именно так, как описано выше, и соглашались дать нужные права только 30-40 процентов пользователей.

Объяснение преимуществ (неоптимально)

Данный метод существенно лучше предыдущего, но все же не так эффективен, как мог бы быть. Вот типичный пример того, как приложение "объясняет" пользователю, почему он должен все ему разрешить. В конце объяснения показывается сообщение с запросом прав.

Подобный подход для Cluster работал хорошо. Когда мы начали объяснять людям, зачем мы хотим от них разрешения на те или иные действия, то процент тех, кто соглашался с нашими доводами, вырос с меньше чем 40% до 60%.

Динамика некоторых приложений может позволять им действовать, только выбирая один из двух описанных выше методов. Если так, то уж лучше тогда объяснить пользователю, почему он что-то вам должен, чем просто с ходу начать требовать разрешить все подряд.

Альтернативный метод Cluster

С течением времени мы научились просить у наших пользователей доступ к данным тогда и только тогда, когда нам решительно это необходимо, одновременно с этим объясняя человеку, какие он получит выгоды, дав нам нужный доступ.

Мы полностью переработали Cluster согласно этому подходу и научили систему показывать диалоговое окно с запросом прав только тогда, когда пользователь уже дал понять, что ответ будет положительный.

Диалог до запроса разрешений

Мы добились немалых успехов, с помощью собственного UI показывая пользователям сообщения о том, что скоро попросим доступы, еще до вызова диалога iOS. Как уже говорилось выше, нет ничего хуже, чем отказ пользователя предоставить права на системном уровне, потому что обратить это действие в iOS будет очень трудно. Но если мы спросим их и нам откажут еще до того, как система сможет это понять, у нас все еще останется шанс все исправить и в будущем получить нужные разрешения.

Только для одних фотографий 46% пользователей, которые отказали нам до вызова диалога iOS, в будущем, когда мы попросили доступ в более подходящий для этого момент, в итоге нам его предоставили.

Это проще, чем может показаться. Вы можете разрабатывать собственные диалоговые окна или использовать дополнительные iOS-диалоги для этих задач.

Двойные запросы

В более старых версиях Cluster, когда мы запрашивали разрешение доступа к фотографиям, обычно это делалось два раза.

Первый диалог (на картинке расположен в середине) в случае отрицательного ответа устанавливал соответствующий внутренний флаг в приложении, но не помечал отказ в iOS. Это значит, что если нам захочется спросить еще раз в будущем — мы еще не истратили свой единственный шанс.

Только лишь 3% пользователей, нажавших "Give Access", после этого выбрали "Dont' Allow" — это значит, что на системном уровне нам отказали всего-то 2% от общего числа пользователей.

Даже несмотря на то, что такая манера спрашивать по два раза может казаться раздражающей, мы практически свелю к нулю вероятность того, что пользователь нажмет "Don't Allow", оставляя себе черный ход, который может привести к победе в будущем. Кроме того, когда мы проводили живые тестирования, никого второе диалоговое окно не взбесило и не поставило в тупик.

Образовательный оверлей до запроса прав

При запросе доступа к контактам, мы хотели включить побольше информации, которая бы объясняла цель этого действия, и стандартный системный диалог не давал нам необходимой гибкости для подробного объяснения. Поэтому нам пришлось создать свой собственный, в который можно было включать картинку.

Получается, сначала мы показывали диалог о том, зачем нам нужен доступ, и давали выбор использовать адресную книгу или вбить информацию о контакте вручную. И само собой, системное диалоговое окно выводилось только в том случае, когда пользователь выбирал вариант "Использовать адресную книгу".

Да, немного неудобно просить дважды, но в результате при появлении второго, уже системного диалога, ни единая душа не нажала "Don't Allow". Более того, люди выбравшие вариант "Я введу информацию вручную", осознав, какая это боль, хотели уже дать нам доступ к адресной книге — и такую возможность мы им тоже дали.

Использование до-системных диалогов позволило нам избавиться от проблемы "Don't Allow" — случаи отказа на системном уровне были сведены почти к нулю. Это была большая победа, и очень приятная, надо сказать.

Запускаемые пользователями диалоги (самый успешный метод)

Тут надо сказать, что несмотря на то, что проблему с отказом на системном уровне нам решить удалось, все еще оставался определенный процент пользователей, которые не давали нам права еще на предварительном этапе. Они не хотели давать нам доступ. Но мы знали, что можем действовать лучше.

Когда мы разобрали проблему по косточкам, то поняли, что пользователи все еще не ожидали, что мы начнем что-то у них запрашивать, так что мы нашли способ сделать так, чтобы они могли сами запускать подсказки. В результате, нам стали разрешать доступ почти в 100% случаев.

Фотографии

В предыдущих версиях приложения первым шагом пользователя Cluster было добавление фотографий. Это значило, что нам надо было запросить доступ к фотогалерее сразу после того, как пользователь нажмет "Create Cluster". На этом шаге нам давали нужные права 67% людей, но это число можно было увеличить.

Мы решили сдвинуть шаг по загрузке фотографий немного поглубже, чтобы просить права на доступ к фото, когда люди уже слегка разберутся в том, что за приложение скачали. Кроме того, мы сделали иконку камеры и кнопку "Добавить фото" перед тем, как выводить запрос доступа.

Это увеличило показатель разрешения с 67 до 89 процентов. На этом этапе пользователи уже понимали, что им надо будет загрузить фотографии, поэтому дать приложению доступ к галерее на этом этапе было само собой разумеющимся шагом.

Контакты

Мы задали себе вопрос — в чем главный профит пользователя от предоставления нам доступа к контактам? Здесь мы также добавили вариант "Я введу контактную информацию позже" в нашем до-системном запросе. Но в таком случае, они не сразу могли прочувствовать всю боль такого варианта, поэтому профит предоставления нам доступа был неочевиден.

В конце концов, мы решили явно показать им, как печально вручную забивать контакты, не предоставив нам доступ. Теперь, когда они не могли сходу найти имя друга в поиске, снизу выводилась подсказка "Показать результаты из книги контактов iPhone". Естественно, когда друга во френдлисте почему-то нет, практически любой человек нажмет на такую подсказку.

Тут мы выяснили, что так как они пытаются получить доступ к данным из своей адресной книги, то 100% пользователей на этом этапе соглашаются дать приложению доступ к ней, — после того, как мы об этом попросим.

Push-оповещения

Задача Cluster состоит в создании небольших приватных пространств, которые можно разделить с друзьями. Мы спросили себя, какая польза нашим пользователям от push-оповещений? Ответ — это нужно для того, чтобы узнавать, когда их друзья активны в созданном и разделенном с ними пространстве.

Поэтому, когда пользователь создает свое пространство и приглашает туда людей, мы задаем ему логичный вопрос: "Хотели бы вы получать оповещения, когда друзья примут ваше приглашение присоединиться?". Если пользователь нажмет "Сообщить мне", ему показывается стандартное диалоговое окошко iOS. Если он говорит "Спасибо, нет", то мы позволяем ему двигаться дальше без этого.

В процессе пользовательского тестирования мы увидели, что после тапа на вариант "Сообщить мне", 100% пользователей в итоге дают доступ.

Чему нас это учит: контекст важнее всего

Все приложения разные, но если действительно задумываться о том, когда пользователю на самом деле понадобится доступ к разным частям своего телефона, и убедиться в том, что в этот момент они ожидают, что у них спросят разрешения, — то можно добиться ошеломляющей эффективности системных диалогов.