«Сразу показывайте, как вы собираетесь применять информацию пользователя»
Перевод статьи маркетолога по продукту Chargebee Йоханна Кундерса о том, как получить доступ к местоположению и личным данным пользователя после установки приложения.
Есть два подхода к вопросам, касающихся адаптации пользователя: какие вопросы вы задаёте и как вы их задаёте. Хороший вопрос — это не то же самое, что хороший запрос.
Позвольте объяснить.
При адаптации пользователей в Chargebee есть три исходные точки в любом обсуждении (как и в большинстве других компаний модели b2b SaaS):
- у нас есть сложная проблема, которую нужно решить;
- решение должно подходить для командной работы;
- решение влияет на запутанную экосистему технологий растущего бизнеса (и в некоторой степени зависит от неё).
Это значит, что нам нужно разработать вопросы для адаптации пользователей. Хотим ли мы изменить приложение, стать более человечными или понимать лучше тех, кто приходит к нам, — мы в любом случае нуждаемся в информации. Нам нужно больше, чем просто имя и почтовый адрес. Нам нужно знать функцию, размер команды, цель её работы.
Мы разговариваем с пользователями, клиентами, друг с другом, чтобы убедиться, что мы задаём хорошие вопросы. Сможем ли мы сделать их хорошими запросами — зависит от того, как мы используем их при адаптации.
Начиная с того, как много будут значить вопросы для пользователей, и заканчивая тем, насколько комфортно пользователи будут чувствовать себя, отвечая на них.
Почему вопросы важны для адаптации пользователей
Лучше всего на этот вопрос смогут ответить мобильные приложения и их нативность. Брендан Маллиган, сооснователь Cluster, объясняет, почему:
Работая над веб-приложением, вы создаёте просто страницу, куда переходит пользователь. Работая над нативным приложением, вы не просто просите пользователей загрузить какую-то программу, но и спрашиваете разрешение на доступ к их местоположению и личным данным. Это уже совершенно другая ситуация.
Загрузка приложения и доступ к личным данным — два серьёзных запроса. Без них мобильное приложение невозможно. Они неизбежны при адаптации пользователей. Неудивительно, что они также влияют на то, как пользователи относятся к приложению. В 2015 году исследователи выяснили, что 25% пользователей открывают приложение один раз и никогда больше не пользуются им.
В 2017 году на саммите Chrome Dev Крис Вильсон заявил, что 90% запросов в Chrome и Android игнорируются. У Cluster была похожая ситуация. Когда продукт запустили в 2013 году, запросы Cluster выглядели так же, как и у других приложений:
60% пользователей отказывали приложению, которое просило доступ к их местоположению и камере. Брендан знал, что такой прямолинейный способ не работает. Нужно что-то менять. Для недоверия у пользователя есть несколько причин. Когда приложение запрашивает доступ к какой-либо информации:
- у пользователя нет никаких оснований доверять ему;
- никто не объяснил, зачем приложению нужны эти данные;
- никто не попытался облегчить переход пользователя от адаптации к запросу и обратно.
Решив эти проблемы, Cluster снизила количество пользователей, которые отказывались давать приложению доступ к различным данным, — с 60% до 5%. Компания поняла: как вы задаёте вопрос, не менее важно (а, может, даже важнее), чем то, о чём вы спрашиваете.
Вот что они выяснили.
Когда гость становится пользователем
После регистрации? В начале адаптации? Или в конце? Каждый возможный ответ не сможет до конца ответить на вопрос. Формы регистрации и процесс адаптации не могут быть посредниками для вовлечённых пользователей.
Джош Дайс и Джошуа Портер понимают это. Ниже — картинка из их книги «Дизайн социальной сети» («Designing For The Social Web»). Они пытаются объяснить, что адаптации пользователя не всегда то же самое, что вовлечённость.
Люк Вроблевски также обращается к этой идее в своей книге «Дизайн веб-форм» («Web Form Design»). В ней он приходит к выводу, что гость становится пользователем, когда он знает, как работает продукт и для чего он ему нужен.
В контексте этой статьи у вывода Вроблевски есть две предпосылки, из которых можно сделать ещё один важный вывод.
- Регистрации часто недостаточно, чтобы сделать из гостя пользователя.
- Вероятнее всего, на вопрос ответит пользователь, а не гость.
- Следовательно, не нужно задавать вопросы сразу же после регистрации.
По мнению Вроблевски, лучше постепенно представлять функции приложения и взаимодействовать с гостями, пока они не будут готовы дать вам ту информацию, которая вам нужна.
Время примеров.
Что я вижу, когда регистрируюсь на сайте Zendesk:
А это скриншот страницы сайта Intercom до того, как я закончил регистрацию:
Zendesk и Intercom упускают возможность превратить гостя в пользователя из-за большого количества вопросов при регистрации.
Cluster впервые спрашивает у меня разрешение на доступ к данным. Это произошло спустя некоторые время после моей регистрации и после того, как я стал пользователем. За это время я понял, как работает Cluster и зачем это приложение мне нужно.
Приложение запрашивает доступ к моим контактам после того, как я вошёл в приложение, создал группу и теперь думаю, кого я хотел бы в неё пригласить.
Вовлекая пользователей в процесс, мы показываем, что наше приложение может делать и его важность. Мы позволяем аудитории взаимодействовать с приложением сразу же, вместо того чтобы отпугивать её (это 75% аудитории) ещё при регистрации.
Люк Вроблески
Когда вопрос помогает
Если ты хочешь построить корабль — не нужно звать людей, планировать, делить работу, доставать инструменты. Надо заразить людей стремлением к бесконечному морю.
Антуан де Сент-Экзюпери
Просьбы предоставить доступ к некоторым данным и функциям мешают мобильным приложениям.
- Процесс адаптации в приложении проходит дольше.
- Такие просьбы вредят пользовательскому опыту.
Если пользователь запрещает приложению доступ к контактам, но потом меняет своё решение, то процесс изменения этих настроек довольно долгий и сложный.
Важно получить доступ с первого раза. Мобильные приложения должны хорошо потрудиться, чтобы всё получилось сразу. Стратегия Cluster — грунтование разрешений, или объяснение пользователям:
- почему запрашиваемые данные необходимы;
- как это поможет пользователю.
Объяснение должно успокоить и мотивировать пользователя. Вы рассказали, зачем приложению информация, и показали, какую пользу она может принести.
На примере Cluster снова можно увидеть, как грунтование может помочь превратить некрасивый вопрос в продуманный запрос:
Для сравнения посмотрите на Xero:
Вопросы задаются без объяснений. Никто не пишет, зачем Xero информация, когда заканчивается мой финансовый год или какие программы бухгалтерского учёта я использую. Я начинаю нервничать, потому что не понимаю, зачем эти данные нужны Xero.
Xero пытается индивидуализировать мой опыт использования приложения? Если да, то я дам разрешение. Xero собирает эту информацию, чтобы предложить мне товары? Если да, то я пока пропущу этот шаг и сразу начну пользоваться приложением.
Вопрос может помочь, если к нему прилагается грунтовка: нам нужен ответ по такой-то причине, и вот так-то он может вам помочь.
Другим примером может послужить Shopify:
Как и в случае с Xero, я спрашиваю себя: зачем Shopify нужно знать мой уровень доходов? У компании, наверное, есть причины для этого вопроса. Но мне никто об этих причинах не рассказал.
Как заслужить доверие при первых взаимодействиях
Адаптация пользователя должна проходить с помощью обучения, демонстрации функций или стимулирования действия. Вопросы могут либо помогать, либо мешать. Третьего не дано.
Давайте посмотрим, как вопросы при регистрации могут обманывать пользователя. Вот несколько вопросов, которые задаёт Hotjar во время регистрации:
Hotjar хочет узнать побольше информации. Фраза «Индивидуализация аккаунта» отлично работает, объясняя мне, почему эти вопросы важны и почему на них нужно ответить именно сейчас.
Я отвечаю на вопросы, потому что мне интересно, что я получу взамен. В чём же проблема? Открыв приложение, я вижу, что мои ответы никак не индивидуализировали Hotjar.
Давайте посмотрим на Zendesk.
Как и Hotjar, Zendesk объясняет мне, зачем приложению нужны ответы на вопросы. Проблема в том, что и здесь никакой индивидуализации нет.
Возможно, они задают вопросы, чтобы улучшить качество службы поддержки, когда я обращусь туда. Но если вам понадобится эта информация позже, зачем вы её просите сейчас?
В обоих случаях вопросы неэффективны. Они не способствуют обучению, демонстрации функций или стимулированию действия. Так как они не влияют на адаптацию пользователя, они кажутся излишне навязчивыми. Но самое главное, они обманывают ожидания пользователей.
Как этого избежать? Сразу показывайте, как информация пользователя, которую он вам предоставит, будет использоваться. Cluster — хороший пример.
Когда Cluster просит доступ к моим контактам, я вижу, зачем это делается. Это часть адаптации пользователя. Каждый запрос Cluster контекстуален (с постепенным вовлечением) и успокаивает (с грунтованием). Приложение также показывает, почему ответы пользователя важны.
Чем больше мы изучаем различия между адаптацией пользователя мобильных и веб-приложений, тем менее заметны эти различия. Да, вопросы, которые мы задаём пользователям, отличаются.
Мы не просим пользователей загрузить что-то. Мы просим взять частичку нового программного обеспечения для команды, у которой, возможно, уже устоявшийся рабочий процесс. Мы не просим доступа к местоположению. Мы спрашиваем, как много людей работают в компании или какой доход у предприятия.
Но неважно, разрабатываем ли мы приложения для веб-страницы или смартфона, для компании или потребителей, — мы разрабатываем приложения для людей. И люди заслуживают хороших вопросов и запросов.
- Используйте постепенное вовлечение пользователей в качестве компаса, чтобы выяснить, когда нужно задать вопрос.
- Используйте грунтование разрешения или информации, чтобы помочь пользователям легче воспринимать каждый запрос.
- Убедитесь, что за каждым запросом следует незамедлительное действие: вы должны показать, зачем вам нужна эта информация.
#дизайн
© vc.ru
