Как Rutube перенёс Discovery из Miro в «Эсборд» — без остановки процессов

Вот уже почти 5 лет мы развиваем сервис «Эсборд». В текущих реалиях — замену Miro и Figjam в РФ. И одним из наших ключевых направлений является Enterprise-сегмент. Изначально проектируя архитектуру системы, мы заложили возможность довольно просто развернуть нас на серверах компании. И сегодня мы хотим поделиться одним из кейсов наших клиентов.

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

Когда стало ясно, что Miro может покинуть российский рынок, команда RUTUBE заранее начала поиск российского решения, чтобы обеспечить непрерывность Discovery-процессов без изменения ритма работы.

На досках жили CJ, User Flow, Service Blueprint, а также таблицы с юзабилити-проблемами и требованиями к клиентскому опыту.Это рабочая среда предварительного анализа перед дизайном: фиксация гипотез, шагов сценариев, приоритетов и входных требований.Если убрать этот этап, Discovery растянется: меньше подготовительной аналитики → больше итераций макетов и согласований.

Пример Customer Journey Map, собранного командой в Эсборд

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

При отборе инструментов проверяли:

— корректный импорт существующих проектов;

— сохранение внутренних ссылок и фреймов;

— удобство комментирования и навигации;

— интерфейс, понятный пользователям Miro;

— возможность on-premise-развёртывания под требования ИБ.

В итоге выбрали Эсборд. Импорт досок сработал корректно, логика интерфейса оказалась близка к Miro, а в открытом roadmap были обозначены сроки выхода нужных функций. Позже RUTUBE развернул коробочную версию — это позволило хранить данные внутри корпоративной сети и соответствовать требованиям безопасности.

Одна «бесконечная» доска для всего — неудобна для больших массивов артефактов, поэтому в RUTUBE выбрали структурный подход: команда разбила рабочие материалы по нескольким доскам — каждая отвечает за отдельное направление или блок клиентского пути.Это помогло поддерживать порядок, ускорить поиск нужных артефактов и избежать перегрузки.

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

User Flows, спроектированные в рамках CX-аудитов

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

Ответственный выбор платформы сработал. После импорта сохранилась структура артефактов, видна граница между завершенными и требующими уточнений участками. On-prem-развёртывание обеспечило соблюдение требований информационной безопасности и контроль над доступом к данным. В повседневной работе сохранилась привычная логика взаимодействия (вход по ссылке, знакомая структура досок: материалы разнесены по тематическим пространствам). В итоге команда сохранила темп и управляемость без лишних итераций.

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

Такой подход особенно полезен крупным продуктовым и UX-командам, где важно не просто «где рисовать CJM», а как сохранить связность артефактов, прозрачность для всей команды и контроль над данными.
Читать в нашем блоге