Дизайн
Ян Австрейх
2396

Как попросить пользователя открыть приложению доступ к данным Материал редакции

Указывайте конкретную причину и пишите простым языком — советует UX-специалист Nielsen Norman Group Мария Росала.

В закладки

Перед получением доступа к устройству пользователя (камере, геолокации, микрофону) приложение должно запросить разрешение. Оно отправляет запрос в виде модального диалогового окна.

Чтобы применить голосовой ввод в «Google Переводчике», пользователю нужно открыть приложению доступ к микрофону. Запросы на доступ в iOS (слева) и Android (справа) отличаются

Как видно на примере выше, в iOS приложение просит у пользователя доступ к микрофону, а в Android запрашивает разрешение на запись звука.

Кроме того, в iOS в диалоговом окне есть пояснение, зачем приложению нужен доступ к микрофону. В запросе на Android такой информации нет. Но это не обязательно плохо: возможно, Android-дизайнер позаботился о том, чтобы пользователь узнал причину запроса ещё до появления модального окна.

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

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

Дизайн запросов на доступ во многих приложениях по-прежнему оставляет желать лучшего, несмотря на большое количество рекомендаций от сообщества разработчиков iOS и Android.

Одна из возможных причин — запросы на доступ часто находятся вне компетенции UX-дизайнеров, внешний вид таких окон определяет система. Также, возможно, UX-дизайнеры и разработчики не считают запросы на доступ чем-то важным и делают их наспех.

Тем не менее запросы на доступ сказываются на общем впечатлении от работы в приложении и должны следовать тем же принципам юзабилити, что и другие функции:

  • Понятность и простота в использовании.
  • Соответствие представлениям пользователя.
  • Помощь пользователю в совершении самостоятельного и осознанного выбора.
  • Стойкость в проверках регуляторов.

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

На что обратить внимание дизайнеру

Эти три фактора значительно влияют на качество оформления запроса на доступ:

  1. Текст в запросе на доступ.
  2. Момент появления запроса.
  3. Возможность изменить решение позже.

Текст в запросе на доступ

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

В исследовании 15 мобильных приложений Джошуа Тан из Университета Северной Дакоты и его коллеги обнаружили, что пользователи на 12% чаще соглашались открыть доступ к ресурсам устройства, если знали причину запроса.

Заинтересовавшись, исследователи проверили результативность разных причин для доступа к контактам в приложении Party Planner, которое они создали. Разница оказалась внушительной.

Оказалось, что пользователи, видевшие в запросе убедительную причину, открывали доступ к контактам на 81% чаще тех, кто видел в запросе слабую причину.

  • Убедительно: «Разрешите Party Planner доступ к вашим контактам, чтобы приложение запомнило адреса электронной почты ваших друзей и вводило их автоматически».
  • Слабо: «Party Planner хотел бы получить доступ к вашей адресной книге, чтобы показать вам самые недорогие места для развлечений неподалёку от местоположения ваших контактов».

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

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

Что делать, чтобы помочь пользователям:

  1. Не используйте в тексте запроса профессиональную речь и акцентируйте внимание на пользе для пользователя. Нельзя просто сообщать, что системе нужен доступ к ресурсам.
  2. Чётко сообщайте пользователям, что они получат, если разрешат приложению доступ к данным.
  3. Не запрашивайте доступ к ресурсам устройства, если он бесполезен. В противном случае это может вызвать подозрения насчёт вашего приложения и бренда.
Instagram чётко объясняет, что пользователь получит, если разрешит приложению доступ к галерее: возможность обмениваться фотографиями с другими людьми и сохранять фотографии, отредактированные в приложении

В приложении United Airlines для iOS поясняющая строка написана плохо: «Использование камеры и галереи для считывания проездных документов и деталей оплаты».

Из-за такой формулировки приложение выглядит нелепо и вызывает недоверие. Кроме того, в запросе не объясняется, чем полезно открытие доступа для пользователя. К примеру, «считывание проездных документов» — просто название функции приложения. Польза — пользователю не придётся вводить данные своего паспорта вручную, если он его сфотографирует.

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

  • Как можно сделать — «Skyscanner запрашивает доступ к вашей геолокации для поиска наиболее подходящих авиарейсов».

  • Как лучше сделать — «Skyscanner запрашивает доступ к вашей геолокации, чтобы вы быстрее смогли выбрать ближайший аэропорт для вылета».
  • Как можно сделать — «Откройте Snapchat доступ к вашей камере, чтобы делать фото в приложении».
  • Как лучше сделать — «Разрешите Snapchat доступ к вашей камере, чтобы вы могли делать моментальные снимки в приложении и делиться ими с друзьями».

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

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

Заголовок: «Никогда не забывайте перезвонить». Текст: «Any.do может напомнить вам перезвонить. Не дайте важному звонку ускользнуть от вас снова». Кнопки:  «Не сейчас» и «Разрешить»

Any.do, планировщик задач для Android, при запуске приложения показывает модальное окно с объяснением, что полезного получит пользователь, если откроет доступ к своим контактам. В данном случае — напоминания, что надо кому-то перезвонить.

Когда пользователь выбирает опцию «Разрешить», запускается обычный запрос на доступ в Android. Если бы при запуске приложения это окно не появилось, запрос на доступ стал бы для пользователя Android неожиданностью и, возможно, насторожил. Пользователь задался бы вопросом: зачем планировщику нужен доступ к моим контактам?

Как написать хороший текст в запросе:

  • Пишите в активном залоге, простым языком, понятным вашим пользователям.
  • Объясните, зачем приложению понадобился доступ к ресурсам и чем это полезно для пользователя. Как правило, формула написания хорошего текста для запроса на доступ выглядит так: [название приложения] хочет получить доступ к вашему [название ресурса], чтобы вы могли [польза для пользователя или задача, которую он сможет выполнить].
  • Когда вы объясняете, для чего нужен запрос на доступ, избегайте расплывчатых фраз вроде «...это сделает вашу работу в приложении более комфортной». Пользователи весьма скептически относятся к туманным обещаниям и начинают подозревать, что разработчики — мошенники, и таким образом маскируют свою преступную схему.
  • Если вы дизайнер Android-приложений, создавайте окна с дополнительной информацией о причине запроса перед появлением запросов на доступ, которых пользователь не ожидает. Так он ещё до появления диалогового окна узнает, зачем система просит доступ к его ресурсам и какую пользу это принесёт.
  • Протестируйте свои запросы на пользователях, чтобы выяснить, понятен ли в них текст.

Момент появления запроса на доступ

От момента зависит, посчитает пользователь запрос на доступ естественным или настораживающим.

Есть два типа запросов на доступ: связанные с контекстом происходящего и инициируемые системой. Запросы на доступ, связанные с контекстом, реже оказываются для пользователя сюрпризом: пользователи нажимают на значок в приложении (например, значок камеры или микрофона) или нажимают на поле, где нужно ввести адрес (для определения геолокации), и система реагирует на эти действия запросом на доступ.

Пользователь сам поймёт назначение запроса, когда вспомнит, какое действие он выполнил перед появлением окна.

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

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

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

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

В приложении Waze для Android, когда пользователь нажимает на красную кнопку микрофона, появляется запрос на доступ к записи звука. Это пример полезного запроса, который пользователь ожидает увидеть в контексте совершаемых действий

Когда пользователь устанавливает и запускает Viber на своём Android-устройстве, приложение встречает его пятью запросами на доступ подряд. Это может серьёзно утомить.

Приложение запрашивает доступ к контактам, фотографиям, камере, микрофону и геолокации. Насчёт того, зачем Viber нужен доступ к контактам, пользователь ещё может догадаться, назначение других запросов интуитивно понять сложно.

Лучше отправить часть запросов в другое время: например, запрашивать доступ к галерее и камере, когда пользователь пытается загрузить изображение со своего телефона или сделать снимок из приложения.

Если приложение в момент запуска не даёт пользователю спокойно работать, это может запутать и сильно озадачить. Запрашивать сразу доступ ко всем ресурсам (как делает Viber на Android) — это как просить у людей денег на «благое дело», но не уточнять, на какое именно.

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

Когда отправлять запрос на доступ:

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

Возможность изменить решение позже

Сначала, бывает, пользователь отказывает приложению в доступе, а затем хочет изменить свой выбор. Например, он может отказать мессенджеру в доступе к контактам, но позже поймёт, что вносить контакты вручную слишком сложно.

Если пользователь сначала отклонил запрос на доступ, а потом попытался получить доступ к связанной с ним функции, не показывайте ему сообщение об ошибке. Лучше объясните, почему та или иная функция недоступна, и подскажите, что можно сделать.

Дайте возможность напрямую зайти в настройки, где можно разрешить приложению доступ к своим ресурсам.

«Нет доступа к камере. Чтобы считывать коды и делать фотографии для вашего профиля, разрешите нам использовать вашу камеру через “Настройки” → “Приватность” → “Камера”». Ниже надпись «Открыть настройки», на которую можно нажать

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

Единственное, что здесь можно поправить, — оформление ссылки «Открыть настройки». Она кликабельна, но это неочевидно: ссылка выглядит как простой текст.

Как дизайнеру помочь пользователю:

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

Не используйте «тёмные паттерны»

С момента вступления в силу GDRP некоторые разработчики начали использовать «тёмные паттерны», чтобы подтолкнуть пользователей согласиться с запросами на доступ.

Иногда запрос на доступ отображают в виде информационного диалогового окна (как можно увидеть на примере с WeChat ниже). Такие запросы часто появляются в момент, когда пользователь находится в процессе решения задачи. Дизайнеры подталкивают разрешить доступ, не вникая в смысл запроса.

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

WeChat нужен доступ к контактам устройства. У пользователя есть два варианта: нажать на «Ок» (под этой кнопкой есть сноска «Рекомендуется») либо нажать на «Узнать больше»

Это уведомление от WeChat использует «тёмный паттерн»: маскирует запрос на доступ под информационное диалоговое окно. Под кнопкой «Ок» есть подпись «Рекомендуется», а возможности прямо отклонить запрос вообще нет.

Если пользователи захотят отказать приложению в доступе к своим контактам, им придётся выполнить ещё больше действий, потому что надо нажать на кнопку «Узнать больше», которая ведёт к ещё более «тёмным паттернам», затрудняющим отклонение запроса.

Не используйте «тёмные паттерны».

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

Заключение

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

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

Наконец, дизайнеры не должны использовать «тёмные паттерны», а вместо этого честно давать пользователю выбор и возможность изменить его.

{ "author_name": "Ян Австрейх", "author_type": "self", "tags": ["\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0439\u043e\u043f\u044b\u0442","ux"], "comments": 2, "likes": 19, "favorites": 63, "is_advertisement": false, "subsite_label": "design", "id": 79627, "is_wide": false, "is_ugc": true, "date": "Wed, 21 Aug 2019 14:02:07 +0300", "is_special": false }
0
{ "id": 79627, "author_id": 192524, "diff_limit": 1000, "urls": {"diff":"\/comments\/79627\/get","add":"\/comments\/79627\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/79627"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199114, "last_count_and_date": null }
2 комментария
Популярные
По порядку
1

Приложение МойМТС этим грешило одно время: не открывалось, пока не дашь доступ к памяти, контактам и камере. Писал в поддержку, отвечали, что это необходимо для установки аватара(!), поиска контактов и считывания данных карты. На мой вопрос, почему бы не спрашивать доступы в момент использования функционала, ответа не было.

Ответить
1

Хорошая статья. Спасибо.

Не совсем согласен с автором по поводу текста с просьбой о доступе. Во втором варианте текста стало больше, смысл не поменялся, добавилось только лишнее.

"Как можно сделать — «Откройте Snapchat доступ к вашей камере, чтобы делать фото в приложении».
Как лучше сделать — «Разрешите Snapchat доступ к вашей камере, чтобы вы могли делать моментальные снимки в приложении и делиться ими с друзьями»."

К тому же сама формулировка «дайте доступ, чтобы...» не очень удачная. На мой взгляд, лучше сперва что-то предлагать, а потом уже просить. То есть на скорую руку я бы сделал так:

Делайте фото прямо в приложении. Для этого откройте Snapchat доступ к камере.

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ] { "page_type": "default" }