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