Организация цвета в дизайн-системах

Введение

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

Неоспоримым является тот факт, что для построения сильной и универсальной системы необходимо создание крепкого фундамента. Я говорю о таких вещах как токены — то из чего будут собраны атомы, молекулы и организмы вашего продукта. Цвета, отступы, радиусы скруглений, стили типографики, эффекты и многое другое что можно вынести на уровень мельчайшего неделимого “определителя” визуальной составляющей.

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

А как бывает?

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

Способ 1. Базовый.

Первый и самый простой способ. Стили добавляются по мере их создания и использования. Делая фриланс заказ или даже промо страницы в рамках своей основной работы вы наверняка использовали такой подход. К плюсам можно отнести то, что это довольно быстро, расширяется такая система “на лету” и не требует сакральных знаний и навыков. Из минусов можно выделить что такой способ организации убивает гибкость на корню, с определенного момента контролировать рост станет невозможно, а фантазия для придумывания новых названий иссякнет на слове “одиннадцатичный”. Стоит добавить что для подавляющего большинства разработчиков нет визуальной разницы между “Light grey” и “Mid grey”, а нежно лиловый и сиреневый — один и тот же цвет. Переключение тем не поддерживается без значительных изменений нейминга.

Способ 2. Как у всех.

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

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

Показательный пример это способ организации цвета в Material design 3 Довольно специфичные названия могут затруднить использование стилей и каждый кто хоть раз проектировал интерфейс на основе М3 знаком с этим не понаслышке.

Способ 3. Расширенный.

Однажды проектируя новую темную тему для одного из продуктов бренда “N” и создавая новый пресет компонента, мы понимаем, что наш стиль light-green в темной теме должен быть заменен на черный, а цвет стиля light_bg можно было бы переиспользовать и для другого компонента, не раздувая библиотеку новым. Также, я пришел в выводу что членам команды разработки проще оперировать циферными названиями, да и дизайнеры в системах с количеством оттенков больше 30 перестают их запоминать. К сожалению на тот момент я не нашел в интернете способа как это сделать, либо никто не задумывался над этим ранее, либо просто не спешил делиться своими наработками с широкой аудиторией. Пришлось, набивая шишки, переизобретать “велосипед” самостоятельно.

Можно сказать что этот вариант вобрал в себя лучшие практики из других способов организации. Поговорим о них чуть подробнее.

Палитры и нейминг

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

Палитра mono, содержит монохромные цвета, которые используются везде, от текста до разделителей. Может включать в себя сколько угодно оттенков по светлоте или прозрачности. При переключении в темную тему инвертируется. То есть цвет что был черным в светлой теме станет белым в черной. Чтобы серые фоны и подложки сохранили свой контраст и вес, подбирайте оттенки вручную или воспользуйтесь готовым сервисами типа dopelyColors или плагинами. Могу сказать что на практике хватает около 14 оттенков с равномерным шагом от #FFFFFF (белого) до #000000 (черного).

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

main100, main200, main300, и т.д.

mono100, mono200, mono300, и т.д.

system100, system200, system300, и т.д.

Дополнительные палитры

Такая система удобна тем что ее можно расширять палитрами. Представим, что в вашем огромном приложении-маркетплейсе появился новый раздел кошелек, который хоть и позиционируется отдельным брендом, но является частью экосистемы и жить будет на общих компонентах дизайн-системы. Создав отдельную палитру wallet, вы сохраните порядок и сможете гибко управлять стилями в рамках такого мини-продукта. Такая палитра позволит не добавлять цвета в основную и может жить и развиваться самостоятельно. Например в одном разрабатываемых мной из финтех-продуктов такая палитра pfm (персональный финансовый менеджер) помогла ввести в игру более 80 уникальных цветов которыми обозначены категории трат.

Оттенки

Зачастую бывает необходимо создать определенное количество оттенков цвета для стиля, и иногда это можно сделать использовав функции lighen или darken для переменной, но преимущество такого подхода в том, что его оттенки можно добавить рядом с основным цветом, используя значения в диапазоне от 100 до 999. Как правило, дизайнерам всегда хочется оперировать большим количеством цветов, дабы иметь возможность управлять акцентами в интерфейсе. Расширяя палитры оттенками вы закрываете потребность дизайн-команды и на чуточку снижаете дизайн-долг в вашем продукте.

Похожие градации используются в системе цветов Material design 2

Темы

Именно в создании и поддержке большого количества тем раскрываются основные преимущества такого способа организации. Разработать набор альтернативных тем приложения, поддержать решение для системы зонтичных продуктов компании или внедрить пару светлой и темной темы для white label продукта становится просто как никогда. Достаточно откопировать вашу основную figma-библиотеку и настроить в ней все оттенки. Хотите в темной теме вам немного притушить или выбелить гамму, или инвертировать стили монохромной палитры подмешав туда оттенок для глубины цвета? Сделайте это отредактировав стили напрямую, не опасаясь нарушить целостность всей системы.

Подключаются новые библиотеки через swap library, после опубликования. А вынеся переменные цвета в json или воспользовавшись figma API, вы получите простой способ мгновенного переключения тем уже в коде ваших приложений. На примере ниже, в упрощенном варианте, показано как как может быть переключена тема для другого продукта или бренда.

К плюсам способа номер 3 (Расширенный) можно отнести:

1. Прозрачность. Цвета сгруппированы по смыслу и разложены в палитрах.
2. Гибкость переиспользование цветов и оттенков больше не вызывает трудностей и имена становятся лишь элементами обозначения.
3. Масштабируемость. Расширить количество цветов в палитре или добавить новые палитры по необходимости? Нет ничего проще.
4. Один язык коммуникации. Разработчикам и другим членам команды теперь проще оперировать названиями стилей.
5. Снижение ошибок. Ошибки, связанные с неправильным применением стилей, некорректным отображением элементов и прочими визуальными недоразумениями, могут быть существенно снижены благодаря использованию таких названий.
6. Обновления и изменения. Благодаря модульной структуре, становится проще внедрять изменения в другие продукты. На практике это выглядит как пересоздание библиотеки сделав дубликат из мастер-библиотеки или точечное добавлени палитр или оттенков в уже существующие с последующим опубликованием.

К минусам:

1. Чувствительность. Иными словами если раньше внося изменения в цвет home_page_bg_color вы не переживали что где-то что-то сломается, то теперь никто не скажет где этот стиль был переиспользован. Помогает добавлять в описание стиля правила использования, например: “main100 — CTA элемменты, кнопки, ссылки, чекбоксы, радио-кнопки и т.д.”.
2. Повышенный уровень входа. Конечно, это относится к любой такой системе, где потребуется время на то чтобы запомнить названия компонентов и стилей, но в случае с абстрактным неймингом его требуется чуть больше, но зато после того как логика понята и усвоена процесс ускоряется. В среднем требуется около одного месяца.

В заключение

Независимо от ваших предпочтений и потребностей, выбор способа — это вопрос личного вкуса. Если же вы в поисках того как улучшить свою дизайн-систему, я настоятельно рекомендую попробовать третий “Расширенный” подход, который я описал выше. Я использовал его в своей работе на протяжении нескольких лет и могу с уверенностью сказать, что он показал себя с лучшей стороны. Этот метод обладает множеством преимуществ, таких как быстрое создание и переключение тем, гибкая настройка и универсальное использование стилей, подключение библиотек к файлам и обновление стилей в разработке через figma API, использование градиентов и стилей с прозрачностью для создания уникальных компонентов.

Если вы дочитали до этого места, то вы большой молодец :) Тут ссылка на файл песочницы в Figma Community для желающих потыкать все самостоятельно.