Бизнес без устали тестирует разные гипотезы о том, как логично внедрять customer experience (CX) в производство своих продуктов. От команды к команде опыт подхода к этому «снаряду» отличается. Даже в рамках одной компании бывает, нет единого представления, как «сочетать несочетаемое»: ориентироваться на клиента и при этом зарабатывать деньги.
В RUTUBE мы нашли свой путь: пригласили в продуктовые стримы отдельных сотрудников. Их задача — погружать продуктовую команду в пользовательские запросы и потребности. А фоном — продвигать стратегию (и идеологию) классного клиентского опыта. Мы назвали себя Customer Journey Experts.
Эту статью написали Лада Еремеева (@lada_e) и Лиза Степанова (@Styepasha). Мы работаем CJE в продуктовых стримах RUTUBE и решили рассказать, как заряжаем свои команды идеями клиентоцентричности. И как в итоге влияем на готовый продукт.
Лада Еремеева
Эксперт по клиентскому опыту RUTUBE
Лиза Степанова
Эксперт по клиентскому опыту RUTUBE
Здесь не будет пропаганды и пустых лозунгов — только конкретные действия, которые мы предпринимаем каждый день.
Предыстория (совсем коротенькая, честно)
Раньше в RUTUBE потоками знаний о клиенте управляли разные специалисты: UX-исследователи, продакт-менеджеры, аналитики, клиентский сервис. Из-за этого синтез комплексных выводов о качестве клиентского опыта вызвал сложности. Сбор информации занимал время, и в итоге клиентоцетричность встраивалась в процесс создания и анализа фичи довольно долго.
Компания пересмотрела свой взгляд на продукт и процесс его создания. Решили усилить вклад в CX, и так в стримах появилась роль CJE aka эксперта по клиентскому опыту.
Мы пришли в продуктовые команды, чтобы аккумулировать потоки данных об опыте пользователя RUTUBE и инициировать клиентоцентричные изменения в продукте.
Как мы собираем знания о наших пользователях и улучшаем их опыт
1. «Купаемся» в обратной связи
Внутри стрима эксперт постоянно что-то читает или смотрит, чтобы понять, как фича реально работает в руках у пользователя. Вот, откуда мы получаем эти знания:
исходники всех обращений пользователей в поддержку;
результаты UX-исследований – внутренних от нашей лаборатории и внешних;
отзывы на различных сервисах: в магазинах приложений Google Play, AppStore, RuStore и других, на форумах типа «Отзовик» и даже в Яндекс.Картах;
комментарии в медиа, например, на Хабре и vc.ru, в социальных сетях и различных тематических каналах в Telegram;
данные пользовательской аналитики: NPS и CSI разных частей продукта, а также точечные данные в зависимости от задачи и гипотезы, которую хочется проверить.
2. Собираем карты «AS IS» и говорим о хорошем
Как только запускается новая фича, мы бежим проверять, как она работает на самом деле — на проде. И фиксируем пользовательский путь as is. На нём подсвечиваем не только юзабилити-проблемы и новые гипотезы, но и хорошие UX-решения, которые надо сохранить и усилить. И не забываем хвалить за них команду!
Ниже на схемах, как выглядит пользовательский путь AS IS.
А так уже исправленные СХ-проблемы:
В них мы сохраняем не только факт решения проблемы, но и способ, которым проблема была решена.
Неудачные решения и юзабилити-косяки тоже бывают, о них ниже.
3. Напоминаем про исправление юзабилити-проблем
CJE позволили себе роскошь прямо в продуктовых бэклогах размещать задачи на исправление юзабилити-проблем, а также инициировать их приоритезацию. Мы делаем это в таск-трекере и сразу «радуем» продакт-менеджера.
Мы собрали в Jira канбан-доску, которую видят все сотрудники компании. Наблюдать, как очередная юзабилити-проблема двигается от статуса к статусу и улетает в «Исправлено» очень терапевтично.
Но перед тем, как достичь такого статуса, любой проект проходит приоритизацию — и мы…
4. Приоритизируем фичи (да-да!)
Продуктологи обращаются к CJE за оценкой, насколько будущая фича повлияет на пользовательский опыт. Чтобы исключить субъективный фактор и оценивать опыт в целом, а не личные предпочтения, команда исследователей создала по нашему запросу специальный калькулятор (о нём наша команда рассказала в докладе на Research Expo).
5. Требуем (!), чтобы фича закрывала потребность
Когда продуктовая команда решает создать что-то новое, на самых ранних этапах CJE анализирует эту идею. Обычно на этом этапе мы создаём клиентский путь и даём ему оценку на основе знаний о своём пользователе. О своей методике проектирования расскажем как-нибудь потом, а сегодня поделимся отдельной гордостью — требованиями клиентского опыта.
В требованиях мы описываем, как должен «вести себя» RUTUBE, чтобы помочь пользователю справиться с задачей. А продуктолог забирает эти требования себе.
Мы по-настоящему гордимся тем, что внедрили их. Во-первых, они стали удобным инструментом влияния на продукт — мы формулируем и оформляем их так, что их правда очень легко передать на реализацию разработке. Во-вторых, мы на уровне терминологии устанавливаем условия: от CX-отдела приходят не только «рекомендации» (которые можно игнорировать), но и «требования», которые обязательно надо учесть при производстве фичи.
Вот пример требования, которое мы сформулировали для справочника для блогеров:
Реализация этого требования на проде выглядит вот так:
6. Прорабатываем макеты вместе с дизайнерами
Когда требования собраны, пора приступать к созданию визуала. Здесь CJE взаимодействует с продуктовыми дизайнерами и редакторами.
Опираясь на спроектированную ранее карту, мы вместе обозначаем потенциально опасные зоны на клиентском пути, где пользователю необходима дополнительная поддержка от интерфейса. Важно не допустить барьеры во взаимодействии пользователя с продуктом и удостовериться, что пользователь закрывает свою задачу.
Итоги
Роль CJE не новая на рынке. В разных компаниях задачи такого эксперта отличаются. Мы в RUTUBE составили своё «прочтение», сосредоточившись на миссии достичь баланса между закрытием пользовательских потребностей и коммерческим успехом продукта.
Для этого мы постоянно анализируем производственный процесс вместе с коллегами и задаёмся вопросом: «А на этом этапе не забывают про CX?» Так, за два года мы полностью интегрировались в продуктовые команды и присутствуем на всех этапах Discovery, Delivery пока происходит без нашего влияния, но мы уже ищем точки интеграции и тестируем подходы.
Поделитесь в комментариях своим опытом: какие процессы и ритуалы помогают вашей команде запускать клиентоцентричный продукт? А если хотите больше узнать о том, как создаются медиасервисы — заглядывайте в канал Смотри за IT.
