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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#ux #пользовательскийопыт