Приветствую! Меня зовут Борис, я руководитель отдела фронтенд-разработки в ЮМoney и продакт-менеджер платформенной команды. О сложностях управления подобными командами и проблемах, которые иногда возникают, уже рассказывал в своей предыдущей статье. Сегодня хочу поделиться историей о том, как в условиях ограниченных ресурсов нам удалось выстроить консистентность пользовательского интерфейса в сервисе, который состоит более чем из 70 микросервисов и охватывает разные направления бизнеса.
Как всё начиналось
Несколько лет назад масштабы нашего фронтенда были значительно скромнее — он представлял собой небольшой набор микросервисов. За последние пять лет их количество, как и число команд, выросло, мы пережили ребрендинг и редизайн, а вместе с этим эволюционировала и дизайн-система.
Изначально мы создали фирменный стиль для ЮMoney и для этого разработали библиотеку собственных UI-компонентов. Тогда мы едва ли понимали, насколько много ресурсов потребуется, чтобы поддерживать эту библиотеку в долгосрочной перспективе.
Параллельно искали открытое решение — дизайн-систему с возможностью гибкой кастомизации и быстрой интеграции. Выбор пал на MUI — это один из самых зрелых и широко используемых продуктов в сфере React-компонентов.
Первые трудности
С каждым месяцем разрозненность решений внутри микросервисов только усиливалась. Базовые компоненты успешно покрывала выбранная дизайн-система, но этого было недостаточно для создания выразительных интерфейсов, которые нужны продуктовым командам.
Из-за сжатых сроков и ограниченных ресурсов продуктовые команды самостоятельно восполняли недостающую функциональность. Они разрабатывали собственные UI-компоненты или дополнительно стилизовали существующие, что приводило к хаосу и несогласованности.
Постепенно пришло осознание: если не предпринять решительных мер, мы не сможем обеспечить должный уровень консистентности интерфейсов и поддерживать приемлемое качество кода. Особенно критичной стала ситуация с обновлением UI-библиотек — никто уже не понимал, как и в каком виде используется тот или иной компонент. Это делало бесшовный переход на новые версии практически невозможным. Каждая команда вынужденно тратила колоссальное количество времени только на то, чтобы обновиться и начать использовать актуальные версии компонентов. А дизайнеры тем временем не понимали, на что им ориентироваться, какие компоненты уже есть и в каком виде.
Первые шаги к порядку
Нашу первую и самую очевидную проблему мы сформулировали предельно ясно: у нас была не дизайн-система, а разрозненные кусочки пазла, которые никто не пытался собрать воедино. Каждая команда создавала свои фрагменты, не заботясь о том, как они стыкуются с остальными.
Первоочередной задачей стала ревизия всего накопившегося багажа и определение элементов, поддающихся унификации в рамках единой дизайн-системы. Для этого пришлось отвлечь ресурсы платформенной команды от текущих задач — вынужденная, но необходимая мера, учитывая, что разработка не останавливалась, а с каждым новым проектом хаос только усиливался.
Тогда же мы решили, что в существующих условиях не можем эффективно поддерживать несколько параллельных библиотек. Выходом стало создание единого источника истины — монорепозитория, объединившего все имеющиеся компоненты.
Это решение принесло ряд ощутимых преимуществ:
Значительно улучшился контроль над источниками импорта компонентов.
Появился единый и прозрачный Changelog (документ, описывающий изменения внутри версии относительно предыдущей) для всей дизайн-системы.
Разработчики получили централизованный ресурс с документацией.
За счёт фокуса ресурсов мы активизировали работу над собственной документацией для всей дизайн-системы и начали гораздо внимательнее относиться к проблемам, с которыми сталкивались разработчики.
Как мы формировали системный подход
Ситуация заметно улучшилась: объединив компоненты в единую, хорошо документированную библиотеку, мы снизили когнитивную нагрузку на разработчиков и уменьшили разброс по версиям между различными микросервисами. Однако объём дизайн-системы был настолько значителен, что мы по-прежнему не успевали за требованиями новых проектов.
Ресурс платформенной команды оставался ограниченным, возможности выделить под эту задачу отдельную команду не было. Бэклог работ непрерывно рос, при этом отсутствовала чёткая стратегия развития и понимание целевого состояния системы. Наша деятельность больше напоминала экстренное «латание дыр» — мы добавляли новые пропсы к компонентам и исправляли критические баги.
Помимо решения очевидных проблем в отдельных компонентах, нужно было выстроить долгосрочную стратегию развития, основанную прежде всего на потребностях будущих продуктов и видении дизайнеров. Было принято решение планировать работы по дизайн-системе наравне с другими проектами.
Каждый квартал мы выбирали два-три крупных компонента, которые требовали особого внимания. Прежде чем начать, проводили масштабную подготовительную работу с дизайнерами — встречались, согласовывали приоритеты. Также мы внедрили практику проводить демо по итогам изменений в уже функционирующих продуктах, чтобы наглядно продемонстрировать, как наша работа трансформирует пользовательские интерфейсы.
Как мы формировали культуру работы с дизайн-системой
Исторически дизайн-система никогда не была приоритетом для платформенной команды — нам всегда хватало инфраструктурной работы и основные задачи оказывались более важными. Внедрив планирование, мы исправили эту ситуацию, но этого было недостаточно, чтобы кардинально поменять отношение команды. Нужно было, чтобы она начала воспринимать дизайн-систему как важную составляющую разработки.
Нас спасли коллеги-энтузиасты, которые в разное время естественным образом становились евангелистами дизайн-системы и стремились вывести её на качественно новый уровень:
Самостоятельно ходили к дизайнерам с запросами на улучшение каких-либо компонент.
Подсвечивали проблемы в дизайн-системе и занимались приоритезацией работ внутри неё.
Рассказывали об обновлениях и планах отдела.
Это помогало развивать документацию, внедрять новые инструменты и укреплять внутреннюю коммуникацию — как в рамках отдела, так и с дизайнерами.
Не менее важным фактором стала демонстрация отделу нашей искренней заинтересованности в улучшении дизайн-системы: мы регулярно проводили презентации, рассказывая об изменениях и стратегических планах развития. Постепенно вокруг дизайн-системы формировалась группа людей, понимающих её ценность для продукта в целом.
Я считаю, что рассказывать надо обо всех изменениях и по всем возможным каналам, чтобы люди услышали и запомнили. Поэтому как минимум с каждым новым релизом, помимо дополнения Changelog, мы собирались и голосом проговаривали, что уже сделано и почему. Также завели привычку раз в квартал обсуждать предстоящие изменения и вектор движения.
Анализ эффективности и новые вызовы
К определённому моменту работа над дизайн-системой стала неотъемлемой частью нашего процесса разработки. Казалось, что всё наладилось: процесс работает, задачи выполняются, коммуникация выстроена, версионирование отлажено. Но именно тогда мы столкнулись с неожиданной проблемой — команды оказались не готовы к интенсивности наших обновлений.
Каждый релиз мог содержать изменения размеров компонентов, модификацию API, визуальные корректировки — всё это требовало внимания разработчиков, ручной работы и значительного ресурса на тестирование. Использование таких ресурсов надо было заранее планировать, что не всегда совпадало с приоритетами продуктовых команд.
Мы, как платформенная команда, стремились не просто выпустить обновление, но и обеспечить миграцию всех команд на актуальные версии. Это привело к напряжению: с одной стороны, мы старались улучшить дизайн-систему, с другой — создавали дополнительную нагрузку на команды.
Эволюция процесса релизов
Чувствуя растущее напряжение, мы начали искать способы упростить процесс обновлений. Наши эксперименты способствовали комплексному подходу к релизам:
Кодмоды для автоматизации миграций — мы начали писать скрипты для автоматического обновления кода.
Предварительное тестирование — перед релизом проверяли изменения на различных микросервисах.
Детальная документация — создавали подробные Changelog и пошаговые инструкции по миграции, просили команды самостоятельно дополнять недостающие сценарии.
Сопровождение команд — активно помогали им с обновлением, а порой просто брали на себя эту задачу, чтобы сократить разрывы в версиях.
С каждым релизом мы совершенствовали процесс, но напряжение в командах сохранялось. Любой баг или недочёт вызывал волну негативных отзывов.
Переломный момент: релиз, изменивший наш подход
Критическая ситуация произошла с одним из релизов, который содержал обновление крупного компонента. Для некоторых команд из рутинной задачи это превратилось в полноценный проект. Последовали закономерные вопросы от бизнеса: «Почему мы тратим столько ресурсов на обновления, которые могут быть не критичны для команды прямо сейчас?».
Попытки объяснить ценность единой дизайн-системы вызывали непонимание — увидеть полную картину сложно, даже находясь в контексте, а для людей вне процесса разработки это практически невозможно.
Стало очевидно: нужен открытый диалог с бизнесом для поиска баланса между потребностями новых продуктов и затратами команд. Необходимо было научиться планировать, опираясь не только на дизайнерское видение или техническое совершенство, но и на стоимость изменений для команд.
Как мы сделали инструмент, который помогает принимать решения
Первые встречи с бизнесом проходили напряжённо — несмотря на отлаженный процесс релизов, у нас не было понимания, какова их реальная стоимость для команд. Никто не мог даже примерно оценить объём ручной работы, которая требовалась для миграции.
И мы решили: почему бы не научиться это рассчитывать? У нас уже были наработки по поиску компонентов в кодовой базе. Мы создали удобный интерфейс и настроили регулярный подсчёт использований.
Получившийся инструмент оказался полезен сразу нескольким отделам:
платформенной команде — для понимания частоты использования компонентов;
дизайнерам — для анализа реального применения дизайн-системы;
менеджерам — для оценки влияния изменений на продукт и планирования работ.
Анализ выявил интересную картину: некоторые компоненты применяются более чем в 80% интерфейсов, другие практически не востребованы. Например, списки используются в интерфейсах повсеместно, а вот компонент эмоджи, который долго прорабатывали, не пригодился. Либо в командах есть своя реализация, либо он просто оказался никому не нужен.
Также мы можем определить, что используются свойства, не заложенные в API компонента. Это даёт дополнительные возможности для улучшения документации.
Как все наши обновления стали осмысленными
Имея данные о распределении компонентов и примерную оценку трудозатрат, мы смогли вести предметный диалог с бизнесом. Теперь каждое значительное изменение в дизайн-системе сопровождается анализом:
сколько команд будет затронуто;
какова примерная трудоёмкость миграции;
есть ли альтернативные решения с меньшими затратами;
какую бизнес-ценность принесёт изменение.
Этот подход кардинально изменил динамику: от обновлений, которые мы считали необходимыми, мы пришли к обновлениям, которые нужны бизнесу. За актуальность версий начали частично отвечать продуктовые команды: они сами решают, когда им выгодно обновиться, исходя из своих планов и приоритетов.
Какие риски у нового подхода
Предоставляя командам больше свободы, мы одновременно увеличиваем их ответственность. Появляются новые риски:
Соблазн создать локальное решение, не обсуждая изменения в дизайн-системе.
Возможные технические компромиссы, которые могут появиться из-за давления сроков.
Увеличение фрагментации между версиями в разных командах.
В определённом смысле это шаг назад, но я уверен: культурная трансформация, произошедшая в командах за время построения процессов, не позволит откатиться к изначальному хаосу. Теперь разработчики понимают ценность консистентности и готовы за неё бороться. По рассуждениям ребят слышно, что они знают, к чему могут привести собственные реализации компонент внутри команды.
Какие у нас планы на будущее
Нас ждёт ещё много работы, но теперь мы точно знаем направление. В первую очередь хочется избавить команды от рутины обновлений. Каждая команда должна знать, зачем это обновление ей нужно и в какой срок стоит обновиться.
За время работы с MUI мы достигли предельной стилизации этой библиотеки. Раньше мы во многом полагались на те возможности, которые она нам предоставляет, но борьба с её особенностями и стилями привела нас к переосмыслению её использования.
Вторым поводом подумать о смене библиотеки стало неожиданное решение о прекращении поддержки MUI Base и переход к новой альфа-версии. К этому мы не были готовы. Такие решения никак не упрощают жизнь разработчикам, поэтому мы будем постепенно мигрировать в сторону других styleless-библиотек и более атомарных пакетов.
Заключение
Наш путь от разрозненных кусочков пазла к цельной дизайн-системе научил нас важному:
Технология — это только часть решения. Без изменения культуры и процессов даже самая совершенная дизайн-система останется мёртвым грузом.
Диалог важнее директив. Вовлечённость всех заинтересованных сторон — от разработчиков до бизнеса — имеет критическое значение для успеха.
Измеряйте, чтобы управлять. Данные об использовании компонентов превратили наш подход из интуитивного в осознанный.
Нужен баланс контроля и свободы. Жёсткая централизация создаёт напряжение, полная свобода ведёт к хаосу. Ищите золотую середину.
Эволюция, а не революция. Постепенные изменения с учётом обратной связи эффективнее радикальных преобразований.
Дизайн-система — это живой организм, который должен развиваться вместе с продуктом и командой. Инвестиции в эту систему сложно измерить здесь и сейчас. Они окупаются не только ускорением разработки, но и повышением качества продукта и его согласованности. И, что не менее важно, позволяют разработчикам получать больше удовольствия от работы.