Как мы упустили онбординг пользователя при разработке ИТ‑продукта и во что нам это обошлось

В начале этого года мы выпустили на рынок телеграм‑бота для задач Service Desk. Он облегчает взаимодействие сотрудников со специалистами ИТ‑отделов, кадровой службы, бухгалтерии и других подразделений. Создавая его, мы совершили достаточно распространенную и типичную ошибку. Сосредоточившись на разработке определенных фич и идеальном образе целевой аудитории, которая будет пользоваться этим продуктом, совсем забыли о косвенных пользователях.

Расскажу, как мы это обнаружили, к чему привела ошибка и каким образом удалось все исправить.

Что такое онбординг и зачем он нужен

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

Онбординг пользователя — это процесс повышения индивидуальных требований и достижения успеха при использовании продукта или услуги.

Команды нередко допускают ошибки в онбординге на этапе реализации. И это нормально. Главное, чтобы впоследствии не оказалось критичным фактором неуспеха продукта или финансово болезненно для команды продукта.

Как это было у нас

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

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

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

Что случилось

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

Дело в том, что каждый пользователь в своем личном профиле в Jira должен был выпускать персональный токен доступа и затем предоставлять его боту. Вместо прямых пользователей это могли делать и инженеры поддержки Jira, но пользователей в боте стало больше 50 и их количество увеличивалось на 20—30 человек в день. Процедура отнимала много времени, так как все действия выполнялись вручную. Такая система авторизации оказалась сложно масштабируема на большое количество пользователей и значительно усиливала нагрузку на инженеров, хотя они и не конечные важнейшие пользователи бота.

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

Пользователи цифровых сервисов привыкли авторизовываться через СМС, e‑mail, аккаунты в соцсетях. Такие способы стали популярны и превысили все другие по частоте использования. И мы, создавая наш бот, упустили этот момент, сделав упор на безопасность и цифровую зрелость использования сервиса.

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

Как решали проблему

Мы полностью пересмотрели систему авторизации, устранили узкое место при масштабировании продукта и сохранили при этом необходимый уровень безопасности.

Метод авторизации Basic Auth не подходит для сервиса с точки зрения безопасности, а метод OAuth 2.0 дорогой для реализации для команды в данном случае. Рассмотрев альтернативы исполнения методов авторизации, мы остановились на организации доступа к боту через почтовый сервис — некоторая смесь OAuth 2.0 и Basic Auth.

Работает это следующим образом: пользователь вводит в интерфейсе бота адрес корпоративной электронной почты, получает на него код доступа и после его введения может пользоваться сервисом. Инженерам технической поддержки теперь достаточно сверять внутреннюю базу данных Jira Service Management на неактуальные адреса корпоративной системы и даже «удалять» учетки при резкой необходимости (внешний взлом корпоративной почты, например).

Такой метод возвращает пользователя в самостоятельный онбординг без нагрузки сотрудников поддержки.

На изменение авторизации потребовалась неделя самой разработки, еще две — на исследование, аналитику и тестирование на разных средах. Сейчас обновленную систему тестируют наши коммерческие клиенты. У бота достаточно долгий срок бесплатной эксплуатации как раз для того, чтобы собрать побольше качественной обратной связи.

Вывод

Можно ли было предотвратить такую ошибку, которую мы совершили, и не упустить ничего из виду? Хочется ответить, что да. Скорее всего, требовалась другая группа первых тестовых пользователей. Мы же тестировали на себе, а как ИТ‑компания, мы любим интересные технические решения и новый пользовательский опыт. Получается, что не очень хорошо примерили на себя портреты пользователей. В таких случаях нужно быть готовым, что какие‑то элементы исследования все же окажутся упущены и ошибки обнаружатся уже значительно позднее.

Хотите рассказать о своем бизнесе или поделиться экспертизой?

В рубрике «Блоги компаний» вы можете бесплатно публиковать статьи о своем бизнесе. Публикации помогут укрепить ваш личный бренд или привлечь внимание партнеров, клиентов, инвесторов.

О чем можно рассказать?

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

Для помощи в подготовке статьи мы сделали телеграм‑бот. В нем — рекомендации по содержанию статьи и инструкции по ее оформлению. Следуйте инструкциям, пишите статьи и отправляйте готовые тексты так же в чат‑бот.

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

Ждем ваших историй!