Эволюция токенов цветов в Туту: как навести порядок в дизайне
Д
Джексон Стей
·6 мин читать
Создание единой дизайн-системы для крупного кроссплатформенного продукта — это всегда вызов. А если процесс совпадает с масштабным ребрендингом компании, задача
Статья была полезной?
Создание единой дизайн-системы для крупного кроссплатформенного продукта — это всегда вызов. А если процесс совпадает с масштабным ребрендингом компании, задача усложняется в разы. В этой статье мы разберем двухлетний кейс команды «Туту», которая прошла путь от полного отсутствия стандартов до гибкой, масштабируемой и строго контролируемой архитектуры цвета.
На момент старта работ (около 2,5 лет назад) команда столкнулась со сложным контекстом:
Три раздельные кодовые базы: Web, нативный iOS и нативный Android.
Устаревшая Legacy-система в вебе: Она пережила три попытки перезапуска, не поддерживалась, а разработчики и дизайнеры боялись вносить туда изменения, чтобы ничего не упало.
Автономия продуктовых вертикалей: Каждая команда (Авиа, ЖД, Отели) самостоятельно кастомизировала интерфейсы под свои локальные задачи, не контрибьютила решения обратно и редко переиспользовала чужие паттерны.
Ребрендинг: Спустя три месяца после старта начался процесс изменения айдентики, правила которой еще только уточнялись на ходу.
Главными принципами новой системы были выбраны отзывчивость к изменениям, простота и управляемость. Чтобы не оверинжинирить систему в условиях полной неопределенности, команда пошла на радикальный шаг — полностью отказаться от среднего (семантического) слоя токенов.
Классическая теория дизайн-систем предполагает три слоя:
Палетка (Primitives): Весь спектр доступных цветов.
Семантика (Semantic): Роли цветов (тексты, фоны, акценты).
Компоненты (Component): Специфичные токены конкретного элемента (цвет текста кнопки в ховере).
В MVP-версии архитектура состояла только из Палетки и сразу Компонентных токенов.
При этом были жестко зафиксированы ограничения:
Дизайнеры и продуктовые разработчики не видели базовую палетку и не могли красить макеты «руками» — они использовали только готовые компоненты.
На стороне мобильной разработки базовые цвета изолировали внутри модуля UI Kit.
Компонентные токены запретили оверрайдить (переопределять) на уровне продуктов.
Такой подход позволил за полгода спроектировать 80% и разработать 50% всех компонентов UI Kit. Однако отсутствие семантического слоя привело к неизбежным проблемам:
1. «Простыня» в Фигме: Количество компонентных токенов разрослось до огромных масштабов, усложняя поддержку внутри команды дизайн-системы
1. «Простыня» в Фигме: Количество компонентных токенов разросло до огромных масштабов, усложняя поддержку внутри команды дизайн-системы
2. Микронеконсистентность (Разножопица): Схожие элементы в разных компонентах ссылались на разные слоты палетки (например, в одном месте Halva 450 с прозрачностью 15%, а в другом — Halva 500 с прозрачностью 10%) просто потому, что «так было можно»
2. Микронеконсистентность (Разножопица): Схожие элементы в разных компонентах ссылались на разные слоты палетки (например, в одном месте Halva 450 с прозрачностью 15%, а в другом — Halva 500 с прозрачностью 10%) просто потому, что «так было можно»
Спустя полгода, когда айдентика устоялась, а продуктовые команды накопили реальный опыт работы с новым стилем интерфейса, пришло время внедрять семантику. Команда выделила два уникальных продуктовых запроса:
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) до черно-белого спектра стало очевидно, что цвета в одном ряду критически отличаются по контрастности (например, желтый был слишком блеклым, а синий — слишком темным).
При старой палитре тесты на контрастность по стандарту 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)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…