Привет, Хабр! Меня зовут Григорий и я руковожу департаментом продуктового дизайна в «Лаборатории Касперского». Хочу рассказать историю, которая началась как форс-мажор, продолжилась как управленческий челлендж и закончилась как хорошая тренировка, позволившая нам проверить устойчивость процессов, силу команды и надежность новых технологических партнеров.
Речь пойдет о том, как в один момент может перевернуться жизнь целого дизайн-департамента (и не только), вынужденного сменить основной рабочий инструмент с Figma на Pixso и как грамотная организация работы помогает минимизировать влияние на непрерывность бизнес-процессов при экстренном переходе на другое решение.
Как и большинство продуктовых команд на рынке, мы проектировали интерфейсы в Figma. Дизайн-системы, библиотеки компонентов, процессы передачи в разработку, плагины, синхронизация процессов все было выстроено в Figma за последние пять-шесть лет, все стабильно работало и обеспечивало скорость выпуска продуктов. Но однажды ночью эта стабильность пошатнулась: мы узнали, что продукт придется сменить.
В этом посте я хочу поделиться опытом экстренной миграции, рассказать о сложностях, с которыми мы столкнулись, о найденных путях их преодоления, и о том, как в процессе вынужденной замены привычного инструмента нашли технологических партнеров, готовых меняться под наши задачи и расти вместе с нами.
Итак, в ночь с 21 на 22 ноября 2025 мы получили уведомление от Figma о прекращении сотрудничества и что доступ к корпоративному аккаунту будет закрыт через неделю.
Логичный вопрос: можно ли было предвидеть такое развитие событий и позаботиться о миграции заблаговременно? Конечно, в текущей геополитической ситуации мы прекрасно понимали и оценивали существующие риски, и заранее принялись изучать альтернативы.
Так, несколько лет назад начали тестировать разные решения и пришли к выводу, что на самом деле альтернатив на рынке не так много, а максимально близким по нужной нам функциональности вариантом будет Pixso. Поэтому для оценки возможностей и исследования перспектив переноса рабочих процессов приобрели тестовые лицензии. Мы даже вступили в диалог с разработчиками, чтобы узнать прогнозы развития инструмента. К слову, диалог со временем перерос в полноценное технологическое партнерство, но тут я немного забегаю вперед.
Иными словами, план был намечен, но принимать решение о заблаговременной замене основного рабочего инструмента, признаюсь, мы не торопились. Для такой смены процессов, к которым все привыкли и которые всех устраивают, действительно нужен финальный триггер.
Но вернемся в ноябрь 2025 года. После получения сообщения от Figma, наши действия можно разделить на несколько этапов, которые применимы не только к данной ситуации с Figma, но и ко многим внештатным ситуациям и внезапным проблемам.
Этап первый — минимизация ущерба
Мы не просто дизайнеры. Мы работаем в сфере информационной безопасности, так что не понаслышке знаем о важности проактивных мер защиты от угроз. Поэтому у нас вообще-то уже был настроен автоматический процесс регулярного резервного копирования файлов. Однако в условиях форс-мажора мы запустили процесс внепланового бэкапирования, поскольку было важно как можно быстрее сохранить рабочие файлы и библиотеки, чтобы не потерять последние версии текущих наработок и макетов.
Звучит не так сложно. Но когда у тебя департамент, ответственный за разработку дизайна нескольких десятков продуктов разного уровня сложности, работающий более чем c тысячей файлов задача становится не такой простой.
Добавлю к этому еще немного штрихов: в компании не только продуктовые дизайнеры использовали Figma. Это был единый инструмент и для команд брендинга, маркетинга, социальных медиа. И это тоже десятки людей и сотни файлов. А еще не будем забывать про аналитиков, доклоков (наших спецов по локализации) и других участников продуктовых команд. Получается совсем не маленькое количество пользователей.
Ну и вишенка на торте – Figma не позволяет выгрузить без ввода капчи больше 50 макетов… В этот момент мы мысленно перемножили это ограничение и количество наших макетов, и с ужасом поняли, что понадобится колоссальный объем времени, выражающийся даже не в часах, а в днях.
Учитывая, что точная дата отключения не была определена, откладывать на последний день было никак нельзя.
Поэтому уже в субботу (напомню, что первое письмо мы получили в ночь с пятницы на субботу) мы начали бэкапить рабочие файлы. Каждый дизайнер отвечал за бэкап своего продукта, а дизайн-лид проверял все бэкапы и сохранял продукты из архивов. Менеджеры еще раз проверяли в рамках своего направления (В2В/В2С/KasperskyOS), что мы точно не забыли ни один файл.
Кроме того, наш департамент собрал общую встречу и чат для всех пользователей Figma в компании, чтобы помочь смежным отделам с оперативным переездом на новую платформу. Сотрудник нашей команды даже быстро создал скрипт, который автоматизировал скачивание файлов (он все еще не позволял обойти капчу, но хотя бы первые 50 файлов скачивались значительно проще).
Этап второй — миграция, сохраняющая непрерывность бизнес-процессов
Итак, первый шаг позади, мы смогли сохранить все наши данные и помогли другим командам. Следующий шаг – импорт файлов в Pixso и старт работы в ней. Напомню, что у нас уже были закуплены пробные лицензии, поэтому мы достаточно быстро «переехали» (спасибо коллегам из Pixso за помощь с быстрым масштабированием) и приступили к импорту данных. Разумеется, при любой миграции возникают определенные сложности. Мы, например, столкнулись с тем, что импорт не всегда проходил успешно, файл мог не открываться из-за совершенно разных причин, например из-за каких-то иконок или линков с компонентами локальных библиотек. И с каждым таким случаем ошибки импорта приходилось разбираться вручную, а как мы уже говорили у нас в работе сотни файлов. Кроме того, при импорте предсказуемо побились все линки и связи с библиотеками. .
Для нас было крайне важно как можно быстрее импортировать файлы, чтобы аналитики и разработка не простаивали из-за наших переездов и смены инструментов. Для этого мы поставили на холд все менее приоритетные задачи, временно остановили внутренний процесс дизайн ревью (все задачи дизайнеров обязательно проходят многоступенчатый процесс ревью, в том числе командой дизайн-системы).
Мы сконцентрировались на основной задаче – открыть доступ к макетам команде разработки в кратчайшие сроки. Мы определили самые приоритетные задачи, которыми разработка уже занималась или вот-вот должна была взять в работу, и сосредоточились на том, чтобы критичные для этих задач файлы были успешно импортированы в первую очередь.
И у нас это получилось. Ни на одном из наших проектов (а у нас их несколько десятков) не пришлось переносить сроки релизов по нашей вине.
Тут важно отметить, как сильно отличался наш опыт взаимодействия с разработчиками Figma и Pixso. Несмотря на то, что мы много лет были постоянными клиентами компании Figma, их специалисты службы поддержки крайне плохо реагировали на наши запросы, а иногда и в принципе не отвечали.
Каким же приятным было наше удивление, когда обнаружилось что менеджеры Pixso активно отвечают на наши вопросы и помогают с решением возникающих проблем. Они проактивно создали с нашей командой общий чат, где собирали все возникающие при работе баги и были всегда готовы оперативно обсудить все проблемы и предложить варианты решения.
Для команды, уже привыкшей к асинхронной поддержке вендора, такой уровень вовлеченности оказался неожиданным и крайне ценным. И речь не только про комфорт коммуникации: открытый диалог с поставщиком инструмента напрямую влияет на скорость работы и устойчивость процессов. В условиях срочной миграции это стало одним из факторов успешного перехода, а оперативная помощь при возникновении связанных с миграцией сложностей послужила поддерживающим фактором для всей команды дизайна.
Этап третий — генеральная уборка
Да, мы смогли в кратчайшие сроки (буквально за несколько дней) предоставить разработке доступ к макетам, которые находились у них в работе, но праздновать победу было рано. Какие-то сложности возникали и дальше, это нормальная часть рабочего процесса. Например, некоторые макеты открывались с различными ошибками, самые частые из которых – поломанные компоненты.
На предыдущем этапе, когда надо было предоставить доступ к макетам как можно быстрее, это было не так критично. Но для постоянной работы нужно привести макеты в порядок: поправить все сломанные компоненты, перелинковать все библиотеки, обновить все слетевшие тексты в полях и таблицах и др. и пр. В общем много-много работы.
Что мы сделали:
В первую очередь декомпозировали все наши файлы на более мелкие, что значительно повышает производительность инструмента.
Затем мы опубликовали библиотеки дизайн-системы, чтобы продуктовые дизайнеры могли начать перелинковывать компоненты заново. Команда дизайн-системы выполнила миграцию материалов из Figma в Pixso, выстроив процесс как управляемый проект с акцентом на митигацию рисков и отсутствие простоя для продуктовых команд. В частности, для обеспечения прозрачности и контроля в Confluence заранее подготовили и регулярно актуализировали план миграции и чеклист. Риски сбоев при переносе закрыли поэтапным подходом: экспорт и импорт распределили между участниками. Проблемные файлы делили на меньшие и загружали последовательно, снижая вероятность сбоев.
По итогам команда успешно перенесла более 100 файлов дизайн-системы; все связи и зависимости восстановили в короткие сроки, так что рабочие процессы и использование дизайн-системы продуктовыми командами не останавливалось.
Несмотря на проделанную работу, нам еще предстоит много рутины по исправлению макетов и компонентов вследствие импорта файлов. Чтобы выдерживать все сроки, все исправления планируются в фоновом режиме параллельно с работой над новыми задачами и макетами.
Этап четвертый — разработка стратегии на будущее
Разумеется, мы четко представляли себе, что работаем с совершенно новым софтом, имеющим особенности, поэтому детально изучили различные нюансы и ограничения продукта. Например, достаточно быстро выяснили, что у Pixso менее развита вложенность компонентов. В нашем случае это значит, что нам нужно будет существенно поменять структуру большинства наших компонентов.
Также в ходе обновлений мы обнаружили ряд особенностей работы файлов, при которых часть текстов и состояний может сбрасываться. Это помогло нам глубже разобраться в механике платформы и точнее определить направления для оптимизации процессов.
Документация на текущем этапе также проходит дополнительную валидацию: некоторые примеры выглядят корректно визуально, но требуют технической синхронизации. Благодаря этому мы получили возможность провести комплексный аудит своих процессов и повысить качество системы в целом.
Важно отметить, что часть нюансов проявилась уже в процессе практической работы, что естественно для любой масштабной миграции, заранее такие вещи предвидеть нельзя. В результате переход трансформировался из разовой операции в последовательный процесс улучшений и стабилизации.
Сейчас перед нами стоит значимый объем задач, запланированы архитектурные улучшения дизайн-системы. Мы подходим к этому этапу стратегически и внимательно, совместно вырабатывая оптимальные решения. В данный момент формируется стратегия оптимизации дизайн-системы с учетом особенностей работы Pixso, а также поэтапный план внедрения изменений, который позволит усилить устойчивость, гибкость и масштабируемость всей системы.
Постскриптум
Если оглянуться назад и оценить масштаб работы, реализованной за считанные дни без остановки разработки и без сдвигов релизных планов, можно уверенно сказать: переход прошел успешно и стал для нас важным этапом профессионального роста. Кроме того, смена основного рабочего инструмента не только возможна, но и при правильной настройке может позволить усилить процессы и продолжить развивать эффективные решения в области информационной безопасности, сохраняя высокий уровень качества пользовательского опыта.
Команда же получила бесценный опыт и мне бы хотелось сформулировать несколько принципиальных выводов по итогу:
Процессы определяют устойчивость сильнее, чем инструменты.
Сплоченная команда способна эффективно проходить через любые трансформации.
Надежный технологический партнер — ключевой элемент долгосрочной стабильности.
Из всех доступных на рынке вариантов мы выбрали Pixso как инструмент, подходящий под наши задачи. Конечно же, мы понимаем, что на текущем этапе зрелости, Pixso еще развивается и может в чем-то уступать решениям, с которыми мы привыкли работать. Однако очень важным фактором оказалось следующее: разработчик софта готов развиваться вместе и под заказчика, работая совместно над улучшениями. Для нас, как для компании с комплексной продуктовой архитектурой и масштабными дизайн-процессами, особенно ценны открытость к диалогу, гибкость и внимательность команды Pixso. Постоянное рабочее взаимодействие, совместное формирование приоритетов развития и искренняя готовность продукта эволюционировать вместе с нашими задачами – именно такой формат сотрудничества позволяет не только успешно решать текущие вопросы, но и простраивать устойчивую долгосрочную стратегию. Конечно же, это взаимовыгодное сотрудничество — мы получаем функциональность, которая нам нужна, а они — горячий фидбек о востребованности и удобности обновлений.
Почему я решил поделиться нашим опытом? В надежде, что он поможет кому-то организовать процесс миграции у себя. Подобные переходы — серьезное испытание для любой дизайн-команды, да и компании в целом. Но наш кейс показывает, что при системном подходе, зрелом управлении рисками и сильной команде даже масштабные изменения могут стать точкой роста. Если вдруг наш материал пригодится вам на практике, или вы хотите поделиться своим опытом миграции с одного основного инструмента на другой — добро пожаловать в комментарии.
