Создание единой дизайн-системы для крупного кроссплатформенного продукта — это всегда вызов. А если процесс совпадает с масштабным ребрендингом компании, задача усложняется в разы. В этой статье мы разберем двухлетний кейс команды «Туту», которая прошла путь от полного отсутствия стандартов до гибкой, масштабируемой и строго контролируемой архитектуры цвета.
Часть 1. Предыстория и запуск MVP: Осознанный отказ от семантики
Богдана Кибза (экс-руководитель команды дизайн-системы Туту)
Вводные данные и контекст
На момент старта работ (около 2,5 лет назад) команда столкнулась со сложным контекстом:
Три раздельные кодовые базы: Web, нативный iOS и нативный Android.
Устаревшая Legacy-система в вебе: Она пережила три попытки перезапуска, не поддерживалась, а разработчики и дизайнеры боялись вносить туда изменения, чтобы ничего не упало.
Автономия продуктовых вертикалей: Каждая команда (Авиа, ЖД, Отели) самостоятельно кастомизировала интерфейсы под свои локальные задачи, не контрибьютила решения обратно и редко переиспользовала чужие паттерны.
Ребрендинг: Спустя три месяца после старта начался процесс изменения айдентики, правила которой еще только уточнялись на ходу.
Разработка MVP
Главными принципами новой системы были выбраны отзывчивость к изменениям, простота и управляемость. Чтобы не оверинжинирить систему в условиях полной неопределенности, команда пошла на радикальный шаг — полностью отказаться от среднего (семантического) слоя токенов.
Классическая теория дизайн-систем предполагает три слоя:
Палетка (Primitives): Весь спектр доступных цветов.
Семантика (Semantic): Роли цветов (тексты, фоны, акценты).
Компоненты (Component): Специфичные токены конкретного элемента (цвет текста кнопки в ховере).
В MVP-версии архитектура состояла только из Палетки и сразу Компонентных токенов.
При этом были жестко зафиксированы ограничения:
Дизайнеры и продуктовые разработчики не видели базовую палетку и не могли красить макеты «руками» — они использовали только готовые компоненты.
На стороне мобильной разработки базовые цвета изолировали внутри модуля UI Kit.
Компонентные токены запретили оверрайдить (переопределять) на уровне продуктов.
Проблемы MVP-подхода
Такой подход позволил за полгода спроектировать 80% и разработать 50% всех компонентов UI Kit. Однако отсутствие семантического слоя привело к неизбежным проблемам:
Часть 2. Версия 1.0: Появление локальной семантики
Спустя полгода, когда айдентика устоялась, а продуктовые команды накопили реальный опыт работы с новым стилем интерфейса, пришло время внедрять семантику. Команда выделила два уникальных продуктовых запроса:
Концепция On White / On Gray
Интерфейсы Туту делятся на два типа:
On Gray: Серый фон интерфейса, на котором контент группируется в белые карточки (типично для поисковой выдачи Авиа/ЖД).
On White: Белый сплошной фон интерфейса, на котором контент идет свободным потоком (характерно для коммуникационных экранов, блогов или контента).
В светлой теме это решается легко. Но в тёмной теме прямая инверсия цветов (белый/серый) порождает классическую проблему: бэкграунд начинает светиться ярче, чем карточки на переднем плане, создавая визуальные «дыры» интерфейса 
Решение: В тёмной теме оба этих режима должны схлопываться в единую визуальную схему. Чтобы дизайнеры не гадали в Фигме, какой из одинаковых белых токенов выбрать, команда упаковала эту логику в отдельную коллекцию переменных — коллекцию модов (Style: On White / On Gray). Переключение одной галочки автоматически перестраивает фон и контрастность элементов под выбранный тип экрана. 2. Управление контрастностью (Contrast High / Low)
Изначально все информационные баннеры и плашки проектировались бледными (пастельными). Продукту потребовались более жесткие, яркие, акцентные решения. Чтобы не плодить новые компоненты, команда создала еще один слой логики через режимы — коллекцию модов Contrast (Default / High). При активации режима High подложка становится сочной, а текст внутри автоматически перекрашивается в нужный цвет для сохранения читаемости.
Часть 3. Архитектурный рефакторинг: Наведение порядка, пересчет хексов
Алексей Макаренко (экс-лид-дизайнер дизайн-системы туту)
Несмотря на успешное внедрение модов, базовая палитра все еще оставалась собранной на шару. В ней не было логики, слоты распределялись хаотично, а главное — цвета сильно страдали с точки зрения доступности (с чем к нам прибежали SEO). Я возглавил процесс рефакторинга токенизации и пересчета всей цветовой палитры. Наведение порядка в семантических группах
До рефакторинга токены семантики (Background, Content, Overlay) располагались в палитре хаотично.
Если фоны еще как-то соотносились со 100-ми и 200-ми слотами 
то текстовые токены (Content Primary) прыгали по абсолютно случайным позициям . Обслуживать такой массив данных и отлавливать ошибки было невозможно. 
Я выстроил ровную структуру, где за каждой группой закрепился свой шаг (столбец) в палитре. 
Однако простое перемещение токенов в один столбец оголило проблему: при выкручивании яркости (Luminosity) до черно-белого спектра стало очевидно, что цвета в одном ряду критически отличаются по контрастности (например, желтый был слишком блеклым, а синий — слишком темным). Решение проблем с Accessibility
При старой палитре тесты на контрастность по стандарту a11y проваливались почти везде: из всех цветных баннеров проверку проходил только один случайный темный слот. Что было сделано:
Все значения цветов были математически пересчитаны и выровнены по контрастности относительно друг друга. 
Команда искала компромисс между душной «B2B-протокольностью» и излишне няшной B2C-гаммой, которая уничтожает доступность интерфейса. Целевым ориентиром выбрали жесткое соответствие стандарту AA. 
Благодаря тонкой настройке контрастности удалось сократить количество токенов для контента в два раза: вместо четырех токенов (отдельно для белого и серого фонов) сделали всего два, которые идеально работают и проходят тесты в обоих контекстах (On White и On Gray). Тёмная тема: Отказ от ручного перекрашивания
Раньше, чтобы компонент корректно отображался в тёмной теме, дизайнерам приходилось вручную переназначать токены (например, менять сore.brand 600 в светлой теме на core.brand 400 в тёмной), что создавало полный рандом в коде. Новый подход:
1. Были созданы две независимые базовые палетки с префиксами Light и Dark (core.light.halva 700 и core.dark.halva 700). 2. Значения в слотах тёмной палетки были сразу интерпретированы с учетом инверсии и проверены на Accessibility.
3. Теперь сам токен семантики или компонента называется абсолютно одинаково для обеих тем. При создании нового компонента разработчику и дизайнеру достаточно просто переключить мод темы интерфейса — под капотом автоматически подставится нужное значение из соответствующей палетки. Оптимизация компонентных токенов и борьба с весом файлов
Компонентные токены — это главная точка хаоса. Схожие элементы управления (например, тогл, чекбокс и радио-кнопка) имели разные оттенки синего и разные уровни альфа-прозрачности.
Я выровнял базовые оттенки, объединив их вокруг единого токена. Как было до всех изменений:
component и semantic жили независимо друг от друга Как в итоге мы хотели видеть идеальную схему:
(7 и 43 это количество компонентов которые используют токены) Что в итоге вышло:
(6 это то что по прежнему смотрит в палетку, 37 в семантику) Что тоже большой успех. Не идеально, но отлично.
Зачем переводить все компоненты на семантические токены?
Для прогнозируемого контроля. стало значительно проще управлять цветами, например если мы меняем значение 500 то мы точно знаем где у нас поменяется цвет, это легко отследить и проконтролировать
Главные выводы.
Итеративность — залог выживания. Попытка спроектировать идеальную семантику на самом старте в условиях ребрендинга заставила бы команду погрязнуть в бесконечных переделках. Запуск MVP без семантики позволил быстро выкатить ДС в прод.
Инфраструктура важнее сиюминутных решений. Проектирование архитектуры «на вырост» позволило провести тотальный пересчет палитры и рефакторинг сорока с лишним компонентов незаметно для продуктовых дизайнеров. Продуктовые команды просто обновили версию ДС и автоматически получили доступные, контрастные и красивые интерфейсы.
Подписывайтесь на ТГ каналы (У меня еще и Youtube канал есть, там тоже подписывайтесь ❤)