Как выживать с мультибрендовой дизайн‑системой

Дизайн-система: начало

Дизайн-системы — это непросто, и в больших компаниях они могут превратиться в семь кругов ада и оставить после себя вьетнамские флешбеки. Особенно если других устоявшихся систем в компании нет и всё приходится делать с нуля. Нужно постоянно балансировать: скорость и качество, гибкость и консистентность, «как в коде» и «как в дизайне».

Тем не менее, дизайн-система должна помочь вашей команде. Дизайнеры будут играться не пером и фреймами, а настройками в правой панели. Разработчики не будут писать код, а будут писать код из компонентов. Все части вашего продукта будут похожи друг на друга. Это ли не мечта?

Это мечта. Мечты должны сбываться, так что впёред: от первой переменной до десятков компонентов, сотен итераций и тысяч свойств. Допустим, что самое сложное позади. Дизайн-система собрана в фигме и в коде. Разработчики начали быстрее программировать, для дизайнеров она не стала ночным кошмаром, а вы её поддерживаете, любите и думаете о ней по ночам.

Если дизайн-система оказалась хороша, а в компании есть другие продукты и команды, они точно захотят попробовать ваши компоненты на вкус. Сначала нужно порадоваться и погордиться собой, пока не придёт осознание: всё стало сложнее.

Помогите

Обращений за помощью стало в пять раз больше. Программисты жалуются, что дизайнеры рисуют что хотят. Дизайнеры жалуются, что не могут нарисовать то, что хотят. К вам начинают приходить продакты. Разработчик, когда-то в соло делавший дизайн-систему вошёл в ступор и не вышел. Брендам хочется, чтобы компоненты выглядели по-разному. Появляется колоссальная нагрузка на команду системы, вы понимаете, что даже новые ресурсы не помогут.

Это всё зелёные флаги — ваша система выросла и встала на ноги, просто столкнулась с очередным кризисом перед героическим скачком в развитии.

Расширение системы

Пришла пора думать, как расширять систему на несколько команд.

Создать разные системы? Смело, но обмен опытом будет сомнительным, продукты будет сложно объединить даже идеалогически, дизайнеры и разработчики не будут взаимозаменяемыми. А ещё каждый продукт потратит кучу времени (а значит денег) на изобретение своего велосипеда.

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

Отдать всё на откуп самим продуктам? Это может сработать — продукты берут компоненты из базовой дизайн-системы (кнопочки и менюшки), а на своей стороне делают то, что нужно им (плеер и карту). Держатели системы смогут сосредоточиться на самом важном, а продуктовые дизайнеры смогут реализовать свои заветные желания. Из минусов — какие-то ресурсы придётся выделить на ревью продуктовых наработок, чтобы они соответствовали базовым принципам дизайн-системы.

Мы выбрали последний подход. Он позволяет нам заниматься базовой дизайн-системой относительно небольшой командой, в то же время любой продукт может сделать её лучше. Расширяемая дизайн-система держится на двух столпах: продуктовые компоненты и продуктовые токены.

Продуктовые компоненты

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

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

Продуктовые токены

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

Цвета, шрифты и числа попадают к нашим разработчикам через систему VKUI Tokens, она же помогает нам расширять дизайн-систему на разные продукты. Каждый продукт может создать свою тему, импортировать туда токены из базовой темы (или из другого продукта), а также переопределить часть переменных или добавить свои. Так получается мультибрендовая дизайн-система.

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

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

Первая мысль: использовать моды переменных. Если у вас не самый дорогой Enterprise план, вы ограничены всего четырьмя модами. Допустим, у каждого продукта есть светлая и тёмная тема. Тогда вы ограничены... двумя продуктами! Переключаться можно будет через моды — это удобно.

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

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

Если всё правильно организовать, перекрашивать кнопки и макеты станет легко и адаптация страницы авторизации под десятки продуктов в разных стилях станет базовой задачей

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

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

Помните, что Земля стоит на UI-китах, и удачи с экспансией вашей дизайн-системы на разные бренды ✊