Правильное хранение палитры в дизайн системе

Привет всем! И снова мы будем говорить о том как создавать удобные в работе дизайн-системы для продуктовых команд. И сегодняшняя тема — организация палитры.

Я занимаюсь дизайном с 2010 года и в основном я сталкивался с двумя подходами:

Палитра имеет полную раскладку каждого оттенка цвета, от самого светлого до самого темного. Берется как правило уже готовая из какого-либо фрэймворка (material, tailwind, bootstrap и т/п.), либо генерируется специальными инструментами.

Проблемы:

Палитра, которая содержит только те цвета которые используются. Дизайнер в процессе работы добавляет по квадратику цвета по мере появления.

«У нас есть набор белых-серых-черных оттенков, цвет логотипа он же цвет кнопок + два производных для ховеров и подложечек, контр-цвет (он же « просто второй цвет из логотипа»), стандартные красный и зеленый»

Проблемы:

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

На первый взгляд тут не так много цветов, но

… как мы видим появляются все те же проблемы что и у первого метода.

Как нам иметь гибкость палитры и уменьшить количество ошибок при сборке макетов. Я предлагаю комбинировать оба метода.

Что такое по своей сути токены? Это полная синхронизация фигмы и стилей на клиенте. Вы используете одни и те же термины, можете самостоятельно создавать стили, менять их и передавать на фронт. Отделы начинают говорить на одном языке и обращаться к одному источнику истины (а это не только frontend с дизайном, но еще и мобильная разработка с QA). Для меня как для архитектора это идеальный расклад… но зачастую руководство компании сложно так вдохновить - это нужно проводить рефакторинг стилей, откладывать разработку фич на месяц-два, обучать команды, время, ресурсы, инструменты, нервы…

Но это не значит что мы не можем взять самое лучшее из системы токенов и воплотить это в фигме.

Базовым понятием работы с токенами является — Alias. Это промежуточный стиль-прокладка, который назначает базовому стилю функцию.

Это дает возможность тонкого тюнинга цветовой схемы сайта - как меняя исходный цвет палитры, так и меняя параметр алиаса, а при смене темы подключается другой файл алиасов в котором будет прописан уже "background": {"value": "{black}"}.

И такую систему вы можете поднять у себя в фигме.

Я создал и выложил шаблон в Figma Community

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

Итак

Base color — цвета которые не меняются при смене темы, например текст на кнопке или overlay. Чтобы не сменить их случайно заведите их отдельно.

Logocolor — аналогично basecolor, только конкретно для логотипа.

HSB — дополняйте hex-кодировку еще и hsb. По ней будет проще добавлять новые или менять имеющиеся цвета за счет лучшей визуализации. +если у вас есть системы автоматической генерации градиентов вам будет проще работать с hsb.

Плагины которые помогают следить за привязкой цветов. Я использую Style Organizer и Similayer.

Упрощение рабочей палитры. Было — все доступные цвета подряд. Стало — четкое разделение по темам и функционалу.

Быстрая сборка тем. По сути вся работа сводится к тому что вы переключаете LT-alias на DT и происходит это практически не глядя.

Унификация. У ребят в файлах стилей ровно такие же названия и параметры.

Подстройка цветовых схем на любом сроке жизни проекта. В процессе работы можно безболезненно поправить цвет по конкретному назначению так и полностью раскладку палитр.

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

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

Состояния компонентов. Нужно ли добавлять отдельные алиасы для таких состояний как ховер, нажатие, фокус и т/п? Мое мнение - они точно нужны на фронте, их можно описать в файле палитры, но их можно не добавлять в рабочие стили - так как вы вряд ли будете их отображать на макете но при этом расширение палитры ведет в усложнению работы с ней.

Вот пожалуй и всё.

Этот сценарий отлично подходит чтобы превратить «ад в адекват», добавит больше гибкости вашему продукту (никто не отменяет внезапных редизайнов и ребрендингов), упрощает масштабирование команд работающих с дизайн системой.

#дизайн