В нашу жизнь уже достаточно давно ворвался тренд на дизайн-системы. Пройдя через все стадии принятия, почти все, наверное, уже поняли, что нет того самого идеально-единого-гибкого решения, которое устранит все проблемы, ускорит процесс разработки и исключит изобретение велосипеда (если у кого-то получилось идеально, дайте знать).

Меня зовут Катя Бурлакина, я старший продуктовый дизайнер в VK Tech и занимаюсь развитием дизайн-системы. В этой статье я не буду рассказывать про весь наш путь, а расскажу про его часть — систему дизайн-токенов. Спойлер: при помощи нее у нас получилось устранить некоторые проблемы, ускорить процесс разработки и даже исключить изобретение велосипеда. 

Система дизайн-токенов

Продукты VK Tech — это решения для бизнеса. Долгие годы эти решения успешно развивались отдельными продуктовыми командами — это привело к сильным различиям в UI и отсутствию узнаваемого бренда VK Tech для пользователей.

Поэтому когда у нас возникла потребность в дизайн‑токенах, нашей основной задачей стало внедрить единый визуальный стиль и обеспечить его контроль через токены. В подходе мы выделили главные приоритеты — универсальность и гибкость: продукты уже имели собственные компоненты в дизайне и на фронте, при этом у каждого была своя техническая база и свои рабочие инструменты. Нам нужно было сделать систему применимой к любой такой базе, а также не потерять возможность клиентских настроек в формате White Label.

Так нашей задачей стала разработка системы, которая обеспечит единый UI, соответствующий бренду, и при этом подойдет любому продукту по техническим требованиям. А решением этой задачи — трехуровневая система дизайн-токенов:

Первый уровень — базовый. С его помощью решается задача единого UI. По сути, это библиотека возможных значений переменных: палитры цветов, числовые значения и параметры типографики, допустимые в проектах. При помощи них мы задаем общий тон и ритм визуального языка, не ограничивая продукты в конкретных значениях по причине их сложившейся технической уникальности, которая непременно влияет и на UI. 

Следующий уровень — семантический — основной уровень для непосредственного применения в проектах. Дизайн-токены данного уровня ссылаются на базовый уровень, но по своей сути обезличены. Они определяют роль в интерфейсе (приоритетность, настроение или относительную величину), но не относятся к конкретному элементу. Это позволяет обеспечить универсальность для использования в любом продукте с любой базой компонентов без риска несогласованности. 

Мы также заложили возможность третьего — компонентного — уровня. Это дизайн-токены конкретных элементов интерфейса. Они принимают значения с семантического уровня, тем самым поддерживая всю цепочку зависимостей. При этом, в отличие от двух предыдущих, могут быть совершенно уникальным списком, определяющим UI определенных компонентов. 

Автоматизация

Экспорт дизайн-токенов

К переходу продуктов на дизайн-токены мы подготовили плагин, позволяющий нам выгружать переменные из Figma в нужных форматах: json, scss, css и ts. Таким образом, Figma стала источником правды и уже значительно ускорила процесс передачи UI из дизайна в код: нативность Figma и взаимосвязанная структура дизайн-токенов позволяли дизайнеру изменять значения и передавать их на фронт буквально в пару кликов.

Дизайнер и GitLab

В процессе внедрения требовалось много изменений в значениях — тестирования на проде то и дело подсвечивали непредвиденные баги в UI. И мы подумали, что возможность дизайнера самостоятельно вносить изменения в репозиторий должна ускорить процесс внесения правок. Небольшой мастер класс по работе с терминалом, настройка доступов в GitLab — и добро пожаловать в команду фронтенд-разработчиков. 

Почему это классно? Процесс обновления токенов очень простой, а дизайнеру не нужно дергать фронта и ждать, пока у него освободится время на обновление. Ведь если у вас жесткая политика планирования, то замена пары значений вообще может затянуться на недели. Теперь обновление UI от начала и до конца проводилось дизайнером. Время обновления токенов на его стороне практически равно времени заведения задачи на фронт — а результат мы получаем быстрее за счет сокращения междкомандного взаимодействия ради минорных изменений.

Тем временем освободившийся от рутинного обновления токенов фронт получил больше времени на фокусировку в продукте. Все, что от него требуется в рамках обновления UI, — это ревью MR и дальнейшее обновление библиотеки токенов в репозитории самого тулкита при очередном релизе.

Компонентный подход

В целом результат уже неплохой. Можно менять значения семантических токенов, экспортировать и выгружать в репозиторий — все изменения быстро оказываются на проде. Но семантика не предоставляет достаточной гибкости — это факт. 

Изменив значение какого-нибудь Background-secondary, мы поменяем цвет нескольких элементов. Это решает часть потенциальных задач. Однако зачастую нужна более точечная настройка: изменить фон кнопки, сделать заголовок алерта на пару пунктов больше или изменить отступы у модалки.

Так мы пришли к третьему уровню — компонентному. В компонентном уровне мы заранее заложили возможность любых изменений — так, чтобы при редизайне у нас были ручки управления каждым UI-параметром независимо от того, как компонент выглядит сейчас. Например, заложили толщину и цвет обводки для кнопки, у которой сейчас эти параметры не назначены. 

Кроме того, компонентный уровень позволяет поддержать стилизации UI в рамках одного тулкита. Зачем это может понадобиться в рамках одного бренда? Например, для разработки лендингов. Маркетинговые страницы точно такой же продукт, как и личный кабинет. В нем используются такие же компоненты: кнопки, модалки, элементы форм в виде инпутов, селектов, чек-боксов и так далее. Только выглядят эти компоненты более выразительно — а этим управляют как раз дизайн-токены.

Одна структура и названия дизайн-токенов, но разные значения — это две темы в токенах. Так мы получили независимый UI, не затрачивая ресурсы для создания и поддержки очередной базы компонентов.

Минусы решения

Мы не смогли применить систему дизайн-токенов во всех продуктах. Не по той причине, что система не оправдала универсальность, а потому, что некоторые продукты уже были завязаны на других дизайн-системах с собственными токенами. По несложным подсчетам, оказалось просто невыгодно пересаживать их на новое решение: наша цель не была в единой системе любой ценой. Такие продукты применили значения визуальной политики бренда у себя, а для остальных и для новых продуктов стандартом стала трехуровневая система дизайн-токенов.

Система токенов с применением компонентного подхода значительно увеличивает количество токенов. Сейчас токенов у нас около двух тысяч — это много и на первый взгляд тяжело контролируемо. Но системность упрощает любое комплексное решение. Когда у вас есть этапность, связность и четкие правила, количество токенов перестает быть проблемой и как таковым «минусом». В нашей системе дизайн-токенов мы соблюдаем следующие правила:

1. Четкое разделение на три уровня, каждый из которых выполняет определенную роль, позволяет разбить большой массив на логические части.

2. Все уровни независимы, но связаны между собой — это обеспечивает управляемый контроль. Изменение на нижнем уровне может организованно прокатиться вверх по системе.

3. Мы не меняем структуру и названия токенов, которые, в свою очередь, были построены по интуитивно понятному принципу. Этот фундамент обеспечивает быстрый онбординг и предсказуемость системы.

В ответ мы получаем гибкий и удобный инструмент, который:

• обеспечивает соответствие бренду в продуктовых интерфейсах;

• ускоряет процесс передачи UI из дизайна в код;

• позволяет переиспользовать одну базу компонентов для админочных и маркетинговых страниц, сохраняя стилистическую независимость каждого.

Вывод

В нашем случае трехуровневая система решила сразу несколько задач: закрепила единый визуальный стандарт, не ущемляя техническую уникальность продуктов, сократила зависимости между командами и дала дизайнерам реальную автономию в управлении UI. И даже возникшие в результате ~2 000 токенов не стали помехой. Надеюсь, наш опыт поможет вам в развитии дизайн-систем в ваших проектах!

Благодарности

Спасибо Ярославу Петухову, Артему Камышу, Юре Дроздову и Саше Шаталову за реализацию проекта на фронте и истинно командную работу, моему руководителю Павлу Карпову за поддержку в развитии идей, а также Анастасии Кабалкиной, Евгению Теслову и Тамазу Хабулову за совместную работу в формировании системы дизайн-токенов.