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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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