{"id":13759,"url":"\/distributions\/13759\/click?bit=1&hash=6aaf2c3e4ab3fd085e02b84ad2ce9889ad89f66980d7001a661e1efa44e3fa38","title":"\u0420\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043f\u0440\u043e \u043d\u043e\u0432\u044b\u0439 \u0430\u0432\u0442\u043e\u043f\u0438\u043b\u043e\u0442 \u0434\u043b\u044f \u0442\u0440\u0430\u043a\u0442\u043e\u0440\u0430 \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043d\u0430\u0433\u0440\u0430\u0434\u0443","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}

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

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

Я занимаюсь дизайном с 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. Это промежуточный стиль-прокладка, который назначает базовому стилю функцию.

  1. Например у вас есть цвет white #FFFFFF
  2. Вы используете white как фон и текст на кнопке
  3. Вы создаете alias-стили background и buttontext
  4. В .js файле эта запись выглядит вот так:
    "white": {"value": "#FFFFFF"}
    "background": {"value": "{white}"}
    "buttontext": {"value": "{white}"}
  5. Теперь у вас есть две функции использующие один цвет

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

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

Собираем палитру

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

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

Итак

  1. Переносите полностью вашу палитру в файл и заведите стили as is, потому что скорее всего они в так же виде уже есть на фронте.
  2. Начните раскладывать ваши макеты на составляющие. Экран за экраном вычленять общие паттерны. Не бойтесь что их может оказаться слишком много - постарайтесь вычленять общие функции и сразу их объединять.
  3. Соберите из этого таблицу отражающую «функция - цвет - кодировка в общей палитре»
  4. Занесите эти значения в стили

Hacks

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

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

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

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

Чего мне удалось добиться таким подходом

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

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

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

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

Работа с возражениями

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

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

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

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

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

0
Комментарии
Читать все 0 комментариев
null