Как называть цвета в Figma

Кратко: не привязывать названия стилей к их функции и яркости, оставлять абстрактными.

Палитра — одно из мест, вокруг которого выстраивается консистентный дизайн интерфейса.

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

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

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

Здесь и далее — палитры из color.adobe.com

Я использую формат kebab-case, поскольку он мне кажется хорошо читаемым, хотя другие конвенции вроде CamelCase тоже годятся и зависят от платформы. Главное — чтобы команде было удобно их использовать.

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

1. Называть стиль по функции

Примеры: button-background, global-back, link, header, button-hover и так далее.

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

2. Выстраивать шкалу оттенков

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

green / light
green / medium
green / dark
green / darkest

Можно использовать номера:

green / 1
green / 2
green / 3

Пример расширенной палитры со шкалами оттенков.

Поскольку мы использовали символ /, Фигма прикольно группирует такие стили. Кроме того, очень желательно добавлять пробелы между ним и слэшем, что повышает читаемость имени.

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

Кстати, есть полезный сервис Shade Generator, который позволит по одному HEX-коду построить ровную шкалу всех его оттенков.

Недостатки

долго возиться с изначальной настройкой. Всё ещё негибко при большом размере палитры, особенно, если нужно поменять или добавить стиль. Дизайнер должен помнить, какой из вариантов где используется, это повышает когнитивную нагрузку. Если вдруг посреди такой шкалы появится предательский новый кандидат на название green-medium, придётся сдвигать названия у нескольких стилей на шаг яркости. Делать это крайне неприятно и можно запутаться и испортить палитру, а как следствие, все её связи к компонентам и шейпам, что отразится на всём проекте. Или сделать быстрый костыль, назвав новый цвет green-medium2. Лучше бы ты этого не делал.

3. Полная абстракция

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

Примеры: electric-blue, coral, banana, red-lips, metallic, stone, night-sky, space-black и так далее. То, что оно не указывает на яркость цвета, играет нам на руку и даёт свободу в расстановке пробников по палитре. Способ идеален для компактных палитр.

Пример компактной палитры.

Что делать, если нужна большая палитра?

В ней можно объединить удобство первого и второго подхода. Для быстрой настройки главных цветов мы используем основную палитру вверху палитры. Цвета в ней могут меняться очень часто. А если встречается какой-то редкий кейс, пользуемся расширенной палитрой оттенков, в которой можно найти все остальные. Она при этом не должна меняться примерно никогда. Она служит не для синхронизации стилей по всему проекту, а для хранения HEX-кодов дополнительных оттенков. Желательно, чтобы в расширенную палитру не попадали те цвета, которые есть в основной, чтобы не было дублирования стилей.

Если тебе понравился этот пост, нажми и держи кнопку Claps, пока на счётчике не будет +50. Так пост увидит больше людей. Это бесплатно.

Иногда я веду /designer — телеграм-канал, паблик и сайт о дизайне интерфейсов.

По теме дизайн-систематизации рекомендую статью своей коллеги и напарницы по Газпромбанку:

Дизайн-система: как хорошо начать и не закончить плохо