Мобільний UX-дизайн: Як правильно запитувати користувачів дозволу

Ви знали, що середньостатистичний додаток втрачає 80% своїх щоденних активних користувачів протягом 3 днів після установки? У більшості випадків люди встановлюють додаток, відкривають його і видаляють. Користувачі пробують багато програм, і протягом декількох днів вони вирішують, які залишити, а які видалити.

Чи означає така поведінка користувачів, що ці програми погано опрацьовані? Не завжди. Але перший досвід взаємодії з додатком відіграє ключову роль у створенні враження в цілому (поганого або хорошого). Останнє, що хочуть побачити користувачі, відкриваючи новий додаток, це нескінченна низка спливаючих вікон, які запитують дозволу:

• доступу до даних про місце розташування
• доступ до контактів
• доступу до камери

Це негативно впливає на досвід взаємодії і викликає бажання видалити додаток. Щоб утримати користувача, додаток повинен почати взаємодіяти з ним до того, як доведеться запитувати дозволу. Ця стаття вкаже вам правильний шлях і допоможе уникнути поширених помилок в організації запитів дозволів.

Розробте стратегію

Найгірше, що ви можете зробити для своєї програми - це бомбардувати користувача запитами дозволів без будь-яких коментарів і пояснень. Поширеними помилками є як занадто ранні, так і занадто часті запити. І все ж, багато додатків так і роблять: видають користувачеві запит на дозвіл відразу, як тільки він відкриває додаток. Наприклад, Inbox від Gmail запитує дозволу ще до знайомства з сервісом, без особливої необхідності, не даючи ніякої додаткової інформації.

Зображення: Inbox від Gmail

Надсилаючи запит на дозвіл, ви очікуєте, що всі користувачі дадуть позитивну відповідь. Щоб досягти цієї мети, вам потрібна стратегія запитів. Вона залежить від прозорості та актуальності вашого запиту. Важливі дозволи слід запитувати відразу, другорядні можна запросити в ході роботи з додатком.

Схема складання запитів дозволів. Зображення: Material Design

Коли запитувати роздільну здатність

Одним з ключових факторів, що визначають відповідь користувача на запит, є момент, коли він з'являється.

Просте правило: Не запитуйте доступ, коли в цьому немає реальної необхідності.

На початкових етапах запитуйте тільки важливі дозволи

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

Зображення: Google Hangouts

Якщо для роботи функцій необхідно більше одного дозволу, запитайте тільки ці дозволи і нічого більше.

Вивід: Зробіть так, щоб користувачеві було зрозуміло, що робить додаток (з опису або попереднього схожого досвіду) і запитуйте на початкових етапах тільки важливі, очікувані для користувача дозволу.

Запитуйте дозволи під час роботи

У більшості випадків, коли користувацький досвід починається з ряду запитів на дозвіл, ви ризикуєте втратити можливість залучити користувача. Додаткам краще запитувати дозволу в ході роботи і пояснювати, що вони дадуть. Коли користувачі вже залучені, вони з більшою ймовірністю дадуть дозвіл.

Зображення: thinkwithgoogle

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

Як запитувати роздільну здатність

Додаток повинен при кожному запиті пояснювати, навіщо йому потрібна та чи інша роздільна здатність, або в назві функції, або в коментарі. Запам'ятайте: якщо ви хочете отримати позитивну відповідь, потрібно просити ввічливо.

Просте правило: Зробіть так, щоб користувачеві було гранично ясно, що він отримає, якщо дасть дозвіл.

Додаткові пояснення

Про дозволи, мета яких не очевидна, потрібно розповісти детальніше. Якщо ваш додаток має підручник з покроками, використовуйте його, щоб пояснити, що робить додаток і навіщо знадобляться ті чи інші дозволи.

Зображення: Material Design

Інший хороший спосіб - пояснювати призначення дозволів в ході роботи. Це дозволяє підтримувати інтерес користувача і допомагає йому зрозуміти мету запиту. Постарайтеся пояснити користувачеві, що йому дасть цей дозвіл.

Зображення: Google Maps

Підготуйте користувача до запиту

Це можна зробити, додавши фонове зображення, яке пояснюватиме запит на роздільну здатність. Foursquare готує користувачів за допомогою фонового зображення, яке пояснює, навіщо програмі потрібна роздільна здатність.

Зображення: Foursquare

Попереджувальне повідомлення перед безпосереднім запитом

На iOS ви можете запитувати роздільну здатність за замовчуванням тільки один раз для кожної функції. Найгірше, що може статися, це якщо ваш користувач відмовить у роздільній здатності на системному рівні, оскільки змінити це рішення на iOS дуже непросто. Найкраще «попередити» користувача про майбутній запит до того, як він з'явиться на екрані.

Cluster - хороший приклад програми, що використовує цей прийом. Cluster дотримується наступної послідовності: подача контексту, попередження і нарешті сам запит на дозвіл. Використання попередніх діалогів практично вирішило проблему відмов для Cluster.

«Попередження» - це система діалогових вікон, що дає поняття про майбутній запит. Зображення: Cluster

Запитуйте у момент дії

Діалогове вікно з користувачем працює краще, ніж подача контексту. Він робить запит очікуваним для користувача і тим самим спонукає його дати згоду, щоб забезпечити роботу відповідної функції. Дочекайтеся активації функції, щоб попросити роздільну здатність. Коли користувач захоче скористатися функцією, наприклад, камерою в Cluster, за її активацією послідує запит доступу до фотографій.

Запитуйте у користувачів дозвіл, тільки коли вони намагаються використовувати функцію. Зображення: Cluster

Що робити з відмовами в дозволі

Відмова у дозволі може перешкодити нормальній роботі функції. Це потрібно доводити до відома користувача, коли він дає відмову.

Просте правило: у разі відмови у дозволі завжди потрібно давати зворотний зв'язок.

Критично важливі дозволи

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

Нижче ви бачите приклад екрану Google Hangouts, який пояснює, що роздільна здатність необхідна для роботи програми.

Зображення: Google Hangouts

Ув'язнення

Всі програми різні, але нам завжди потрібно думати, в який момент користувачеві знадобиться доступ до різних частин телефону і даних, і зробити так, щоб запит був очікуваним. Покращувати користувацький досвід можна нескінченно. Не втрачайте можливості підготувати користувача так, щоб він дав дозвіл! Завжди проводьте тестування, щоб з'ясувати, що вам найбільше підходить.