Как мы упустили онбординг пользователя при разработке ИТ-продукта и во что нам это обошлось
Почему онбординг пользователей так важен в продуктовой разработке
В начале этого года мы выпустили на рынок телеграм-бота для задач Service Desk. Он облегчает взаимодействие сотрудников со специалистами ИТ-отделов, кадровой службы, бухгалтерии и других подразделений. Создавая его, мы совершили достаточно распространенную и типичную ошибку. Сосредоточившись на разработке определенных фич и идеальном образе целевой аудитории, которая будет пользоваться этим продуктом, совсем забыли о косвенных пользователях. Расскажу, как мы это обнаружили, к чему привела ошибка и каким образом удалось все исправить.
Что такое онбординг и зачем он нужен
Согласно теории продуктового менеджмента, образ пользователя продукта нужно формировать заранее: его возраст, привычки, поведенческие паттерны, используемые сервисы, компетенции и так далее. Это позволяет создать карту пользовательского опыта и выдвинуть гипотезы, как человек будет взаимодействовать с продуктом, какая информация окажется для него важной, какие функции он начнет использовать чаще всего, а от каких откажется вовсе. А уже в продукте это отслеживается с помощью функциональности и метрик онбординга. Онбординг пользователя — это процесс повышения индивидуальных требований и достижения успеха при использовании продукта или услуги. Команды нередко допускают ошибки в онбординге на этапе реализации. И это нормально. Главное, чтобы впоследствии не оказалось критичным фактором неуспеха продукта или финансово болезненно для команды продукта.
Как это было у нас
Во время исследования продуктовой идеи, как и полагается, мы сформировали портрет пользователей. Также сразу заложили уровень их потребностей, зрелость владения аналогичными продуктами, потенциальную частоту использования нашего решения и то, как с ним будут взаимодействовать. Карта пользовательского опыта представляла собой сразу критический путь по функциям, так как в боте не было большого количества фич, чтобы углубляться в сложные детали. Мы сформулировали гипотезу, какая функциональность будет использоваться наиболее часто, а какая — реже, но при этом она необходима, чтобы у продукта сразу была достаточно полная версия. На этом и остановились до этапа пилотных внедрений.
MVP апробировали внутри нашей компании, поскольку мы тоже являемся целевой аудиторией сервиса. Для этого собрали исследовательскую группу из пользователей Service Desk, запустили цикл тестирования бота и сбора обратной связи. Наша гипотеза о частоте использования определенных функций и карта пути подтвердились, и мы начали работать над улучшением качества пользовательского опыта — увлеклись «бантиками». Например, решали запросы на присвоение прямых линков на заявки Service Desk, более структурированного описания, делали кнопки удобными и т. д.
О том, что упустили из виду важную фичу, влияющую на онбординг пользователя в продукте, узнали уже на этапе пилотного внедрения бота коммерческим заказчикам. Ошибка привела нас ко второму полноценному релизу коммерческой версии сервиса.
Бот выступает единым окном для обращения в Service Desk и коммуникации с различными подразделениями.
Что случилось
Мы не учли пользовательский опыт группы косвенных потребителей продукта — разработчиков и инженеров поддержки, которые отвечают за первый запуск и обслуживание бота. Тех возможностей, которые мы заложили для масштабирования сервиса, им не хватило, когда количество конечных пользователей в боте стало кратно расти. Мы не учли, что они могут просто попросить инженеров поддержки обойти их авторизацию в боте (то есть практически пропустить онбординг), потому что эта фича им не нравится.
Дело в том, что каждый пользователь в своем личном профиле в Jira должен был выпускать персональный токен доступа и затем предоставлять его боту. Вместо прямых пользователей это могли делать и инженеры поддержки Jira, но пользователей в боте стало больше 50 и их количество увеличивалось на 20—30 человек в день. Процедура отнимала много времени, так как все действия выполнялись вручную. Такая система авторизации оказалась сложно масштабируема на большое количество пользователей и значительно усиливала нагрузку на инженеров, хотя они и не конечные важнейшие пользователи бота. Конечным пользователям продукта наш подход к авторизации не подошел из-за непривычного опыта: частота потребности заходить в личный профиль Jira и выпускать персональный токен доступа для каких-либо внешних сервисов стремится к нулю со скоростью света.
По сути, мы столкнулись с ситуацией из популярного мема, когда разработчики выпускают функционал, а пользователи переворачивают его с ног на голову, так как поняли все по-своему. Но стало ясно, что мы совершили еще одну ошибку, выбрав не самый популярный метод авторизации. Пользователи цифровых сервисов привыкли авторизовываться через СМС, e-mail, аккаунты в соцсетях. Такие способы стали популярны и превысили все другие по частоте использования. И мы, создавая наш бот, упустили этот момент, сделав упор на безопасность и цифровую зрелость использования сервиса. Это довольно распространенные ошибки, которые совершают команды с любым опытом и масштабом продуктов. Обнаружить и устранить их обычно можно как раз на этапе тестирования пользователями.
Как решали проблему
Мы полностью пересмотрели систему авторизации, устранили узкое место при масштабировании продукта и сохранили при этом необходимый уровень безопасности. Метод авторизации Basic Auth не подходит для сервиса с точки зрения безопасности, а метод OAuth 2.0 дорогой для реализации для команды в данном случае. Рассмотрев альтернативы исполнения методов авторизации, мы остановились на организации доступа к боту через почтовый сервис — некоторая смесь OAuth 2.0 и Basic Auth. Работает это следующим образом: пользователь вводит в интерфейсе бота адрес корпоративной электронной почты, получает на него код доступа и после его введения может пользоваться сервисом. Инженерам технической поддержки теперь достаточно сверять внутреннюю базу данных Jira Service Management на неактуальные адреса корпоративной системы и даже «удалять» учетки при резкой необходимости (внешний взлом корпоративной почты, например). Такой метод возвращает пользователя в самостоятельный онбординг без нагрузки сотрудников поддержки. На изменение авторизации потребовалась неделя самой разработки, еще две — на исследование, аналитику и тестирование на разных средах. Сейчас обновленную систему тестируют наши коммерческие клиенты. У бота достаточно долгий срок бесплатной эксплуатации как раз для того, чтобы собрать побольше качественной обратной связи.
Вывод
Можно ли было предотвратить такую ошибку, которую мы совершили, и не упустить ничего из виду? Хочется ответить, что да. Скорее всего, требовалась другая группа первых тестовых пользователей. Мы же тестировали на себе, а как ИТ-компания, мы любим интересные технические решения и новый пользовательский опыт. Получается, что не очень хорошо примерили на себя портреты пользователей. В таких случаях нужно быть готовым, что какие-то элементы исследования все же окажутся упущены и ошибки обнаружатся уже значительно позднее.
Хотите рассказать о своем бизнесе или поделиться экспертизой?
В рубрике «Блоги компаний» вы можете бесплатно публиковать статьи о своем бизнесе. Публикации помогут укрепить ваш личный бренд или привлечь внимание партнеров, клиентов, инвесторов. О чем можно рассказать?Обо всем, с чем вы столкнулись лично, например, вышли на новый рынок, нашли неочевидный канал сбыта или придумали, как увеличить продажи в несезон. О работе с инструментами, сервисами или технологиями для бизнеса.Для помощи в подготовке статьи мы сделали телеграм-бот. В нем — рекомендации по содержанию статьи и инструкции по ее оформлению. Следуйте инструкциям, пишите статьи и отправляйте готовые тексты так же в чат-бот.
