Привет всем! И снова мы будем говорить о том как создавать удобные в работе дизайн-системы для продуктовых команд. И сегодняшняя тема — организация палитры.
Я занимаюсь дизайном с 2010 года и в основном я сталкивался с двумя подходами:
«У нас есть ВСЕ цвета»
Палитра имеет полную раскладку каждого оттенка цвета, от самого светлого до самого темного. Берется как правило уже готовая из какого-либо фрэймворка (material, tailwind, bootstrap и т/п.), либо генерируется специальными инструментами.
Проблемы:
- Из всей палитры используются максимум 15-20 цветов.
- «А зачем вам оттенки болотного?»
- Дизайнеры постоянно ошибаются в числовой кодировке цветов — обводка на одном макете 200, на другом 300. Нужно тщательнее проверять и все равно постоянно возвращаются замечания с фронта.
- Идеальных палитр «из коробки» не существует и придется добавлять/менять цвета, начнут появляться 150 320 910 (с ещё меньшим контрастом и ещё большей вероятностью спутать цвета)
- Проблема с темированием. У вас скорее всего не получится делать зеркальную инверсию с 100 на 900 и получить адекватную темную тему.
«Чем богаты, тому и рады»
Палитра, которая содержит только те цвета которые используются. Дизайнер в процессе работы добавляет по квадратику цвета по мере появления.
«У нас есть набор белых-серых-черных оттенков, цвет логотипа он же цвет кнопок + два производных для ховеров и подложечек, контр-цвет (он же « просто второй цвет из логотипа»), стандартные красный и зеленый»
Проблемы:
- Этот подход работает только в небольших проектах и не подходит для серьезной продуктовой разработки.
Для меня показательным примером является палитра вк
(файл в комьюнити скорее всего давно устарел, ребята из vk если что поправят меня в комментах - просто для меня это наглядный пример того, что случается когда этот подход применяется в продуктах)
На первый взгляд тут не так много цветов, но
- визуальная разница между например light blue 100 и 80 довольно слабая и есть вероятность ошибиться.
- такие системы накапливают артефакты, которые наслаиваются друг на друга — «в один момент мы решили перестать использовать цвет N, сделали новый цвет N10, но не удалили пока не провели рефакторинг а потом забыли».
- У градации нет консистентности. Посмотрите на тот же light blue в котором порядок идет 100, 300, А300, 400.
… как мы видим появляются все те же проблемы что и у первого метода.
Как быть?
Как нам иметь гибкость палитры и уменьшить количество ошибок при сборке макетов. Я предлагаю комбинировать оба метода.
Цвет = Функция
Поговорим немного о токенах
Что такое по своей сути токены? Это полная синхронизация фигмы и стилей на клиенте. Вы используете одни и те же термины, можете самостоятельно создавать стили, менять их и передавать на фронт. Отделы начинают говорить на одном языке и обращаться к одному источнику истины (а это не только frontend с дизайном, но еще и мобильная разработка с QA). Для меня как для архитектора это идеальный расклад… но зачастую руководство компании сложно так вдохновить - это нужно проводить рефакторинг стилей, откладывать разработку фич на месяц-два, обучать команды, время, ресурсы, инструменты, нервы…
Но это не значит что мы не можем взять самое лучшее из системы токенов и воплотить это в фигме.
Базовым понятием работы с токенами является — Alias. Это промежуточный стиль-прокладка, который назначает базовому стилю функцию.
- Например у вас есть цвет white #FFFFFF
- Вы используете white как фон и текст на кнопке
- Вы создаете alias-стили background и buttontext
- В .js файле эта запись выглядит вот так:
"white": {"value": "#FFFFFF"}
"background": {"value": "{white}"}
"buttontext": {"value": "{white}"} - Теперь у вас есть две функции использующие один цвет
Это дает возможность тонкого тюнинга цветовой схемы сайта - как меняя исходный цвет палитры, так и меняя параметр алиаса, а при смене темы подключается другой файл алиасов в котором будет прописан уже "background": {"value": "{black}"}.
И такую систему вы можете поднять у себя в фигме.
Собираем палитру
Я создал и выложил шаблон в Figma Community
Важное примечание перед тем как приступить к сборке — не бойтесь исключений. Стремление к созданию чего-то идеального это путь в никуда. Вы будете загонять себя в рамки, а продукту будет сложнее развиваться визуально… оговорите заранее с разработчиками что будет определенная степень кастома, так как того требует дизайн с точки зрения коммуникации с пользователем или создания определенных эмоций. И сами не забывайте что в первую очередь вы дизайнеры, а не сборщики макетов:)
Итак
- Переносите полностью вашу палитру в файл и заведите стили as is, потому что скорее всего они в так же виде уже есть на фронте.
- Начните раскладывать ваши макеты на составляющие. Экран за экраном вычленять общие паттерны. Не бойтесь что их может оказаться слишком много - постарайтесь вычленять общие функции и сразу их объединять.
- Соберите из этого таблицу отражающую «функция - цвет - кодировка в общей палитре»
- Занесите эти значения в стили
Hacks
Base color — цвета которые не меняются при смене темы, например текст на кнопке или overlay. Чтобы не сменить их случайно заведите их отдельно.
Logocolor — аналогично basecolor, только конкретно для логотипа.
HSB — дополняйте hex-кодировку еще и hsb. По ней будет проще добавлять новые или менять имеющиеся цвета за счет лучшей визуализации. +если у вас есть системы автоматической генерации градиентов вам будет проще работать с hsb.
Плагины которые помогают следить за привязкой цветов. Я использую Style Organizer и Similayer.
Чего мне удалось добиться таким подходом
Упрощение рабочей палитры. Было — все доступные цвета подряд. Стало — четкое разделение по темам и функционалу.
Быстрая сборка тем. По сути вся работа сводится к тому что вы переключаете LT-alias на DT и происходит это практически не глядя.
Унификация. У ребят в файлах стилей ровно такие же названия и параметры.
Подстройка цветовых схем на любом сроке жизни проекта. В процессе работы можно безболезненно поправить цвет по конкретному назначению так и полностью раскладку палитр.
Работа с возражениями
«Нам было удобно когда всё было по номерам» — Ни в коем случае не соглашайтесь на номера. Вы потеряете понятные функциональные названия… а это самое важно сохранять первоначальную функцию цвета, иначе меняя какой-нибудь разделитель у вас начнет меняться ещё и текст.
«А что будет если вы добавите третий фон?» «А что если понадобится новый алиас?» - моя самая нелюбимая формулировка. С одной стороны проблема только гипотетическая и она возможно никогда не случиться, а с другой нельзя сказать что мы не закладываем будущую гибкость и решение прекрасно уже сейчас. В системе достаточно гибкости чтобы вводить алиасы и называть их как угодно - в этом нет никакой проблемы.
Состояния компонентов. Нужно ли добавлять отдельные алиасы для таких состояний как ховер, нажатие, фокус и т/п? Мое мнение - они точно нужны на фронте, их можно описать в файле палитры, но их можно не добавлять в рабочие стили - так как вы вряд ли будете их отображать на макете но при этом расширение палитры ведет в усложнению работы с ней.
Вот пожалуй и всё.
Этот сценарий отлично подходит чтобы превратить «ад в адекват», добавит больше гибкости вашему продукту (никто не отменяет внезапных редизайнов и ребрендингов), упрощает масштабирование команд работающих с дизайн системой.