Создание цветовой палитры для компании с большой распределенностью продуктов

"Пение — дело такое: только начни петь своему отражению в зеркале, потом запоешь дуэтом с какой-нибудь синичкой, затем подтянутся прочие лесные жители, ну а дальше остановить тебя можно будет только огнемётом". (с)

Работа с цветовой палитрой продукта поначалу в чем-то похожа на приятную прогулку по летнему лугу. Вокруг тебя летают бабочки, растут цветочки, и ты безмятежно расписываешь основные цвета, еще не зная, что этот путь тебе будет стоить очень дорого. Чем дальше ты будешь заходить в лес, тем больше эта чаща из нюансов будет густеть и темнеть. В этой статье мы, Подразделение дизайна и клиентского опыта ДОМ.РФ, подробно рассмотрим варианты того, как нам вылезти из этого леса и не сломать себе ноги в процессе.

В любом продукте цвет начинается с бренда. Мы не будем рассматривать ситуации, когда вы создаете продукт с нуля, а перейдем сразу к продукту с существующим брендбуком. Помимо разных интересных и важных вещей, спрятанных там, любой документ по стилю содержит в себе цветовую палитру. Основные цвета - это лицо и визитная карточка, те самые оттенки, благодаря которым наш продукт становится узнаваемым. Этот тот самый синий и желтый из ИКЕИ, красный из МТС и зеленый у нас, в ДОМ.РФ.

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

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

Когда каждый продукт делает свой подрядчик без отсутствия общей дизайн-системы, рано или поздно велик риск того, что рука дизайнера дрогнет, и пипетка соскочит. Так произошло у нас, и в какой-то момент мы превратились в персонажей книги «50 оттенков серого», только без красавчика, денег и личного самолета.

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

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

— То, что нас не убивает, делает нас сильнее! — А то, что убивает, делает нас мертвыми! (с)

Как подходить к первичному объединению палитры в нескольких продуктах сразу? Рассказываем на примере тех самых страшных серых цветов:

В итоге у нас получилось сбить палитру между продуктами с количеством оттенков более 50-ти штук. Дополнительно в процессе мы разложили статусные цвета и добавили отдельные «запасные» оттенки для графиков и диаграмм.

Но это было только начало.

— Хаос всегда побеждает порядок, поскольку лучше организован (с)

Когда ты счастливый обладатель небольшой палитры, то легко можно оперировать простыми названиями продуктов - main green, light blue, dark grey. Как только цветов становится чуть больше, ты начинаешь думать что light blue не такой уж и light, а возможно и lighter. И вот на этом месте мы впервые сталкиваемся с реальностью: что-то пошло не так. Палитра из более чем 50-ти цветов становится еще чувствительнее, особенно когда ей пользуются 18+ дизайнеров сразу. И вопрос нейминга упирается не только в описание текущих цветов, но и в неиллюзорную вероятность добавления новых, ведь продукты растут, и близок тот день, когда к нам придет система, в которой жизненно необходим еще более серый серый.

Как же так? Вы же заложили кучу оттенков заранее для масштабирования?

"Никогда не говори "никогда" - это девиз всех дизайнеров, который сэкономит вам кучу нервов и выпавших волос. Эту истину ты впитываешь с каждой сотой правкой и каждый желанием подлить себе коньячку в утренний кофе. Мы называем это красивым словосочетанием «вероятное масштабирование продуктовой линейки» и готовимся к этому заранее.

Итак, мы столкнулись с проблемой, и ее надо решать. Цифры! Это еще одно популярное решение, которое часто используется в дизайн-системах. Light blue превращается в blue-200, а вся палитра превращается в красивый ряд со своими значениями.

Такой подход, безусловно, устраивает многих. Но в случае изменения палитры у нас неожиданно появляются такие варианты как blue-250, и нет логики в назначении этой сортировки.

Поэтому в какой-то момент мы решили совместить приятное с полезным и воспользоваться шкалой контрастности WCAG.

Чем же оно полезное? При проектировании системы легко выбирать цвета, сидя за Макбуком с ретиной. Все цвета выглядят идеально, все читается, ведь это не просто какой-то компьютер, а дизайнерский. Но если в какой-то момент мы откроем наш макет внутри контура, на офисном мониторе, а еще лучше - расшарим его в корпоративном вебексе, то тут-то и осознается масштаб бедствия. У нас был реальный кейс, когда все цвета ниже grey-300 просто исчезали.

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

Каждый цвет из нашей палитры мы прогоняли через сервис WCAG, к каждому цвету мы добавили колонку, где четко зафиксировали, соответствует ли он стандартами читаемости по трем параметрам (цвет шрифта, цвет фона, цвет графики).

Чтобы дизайнерам проще было ориентироваться в степени насыщенности - для нейминга мы взяли именно значение цвета по шкале.

Так, grey-900 превратился у нас в Grey - 1514, и стало интуитивно понятно, что это высокий показатель контрастности, а значит, его можно использовать в основном тексте. С точки зрения масштабируемости такой нейминг максимально легко калибровать под систему. Если у нас добавляется новый оттенок, он также проходит сквозь чистилище WCAG и обретает свое имя, рассчитанное не эмпирически, а математически.

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

- В общем, у нас большой опыт отсутствия опыта (с)

Вообще, мы очень любим такую интересную парадигму подхода к дизайну как design-as-a-code. Разработчиков мы тоже любим, особенно тех, кто не меняет наши кнопки на бою и не верстает на глазок.

Поэтому даже система хранения макетов у нас чем-то напоминает структуру работы в гите: есть мастер ветки, которые в фигме мы называем "Эпики", есть отдельные маленькие ветки по неймингу задач в Джире. Все компоненты у нас строго идут из главной дизайн-библиотеки, при создании макетов мы сразу думаем про нюансы реализации и специфику фреймворка.

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

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

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

Конструкция токена

[Category]-[Type]-[Item]-[SubItem]-[State]

С точки зрения токенов, цвет фона кнопки выглядит вот так:

$color-background-button-primary-default: #00BFFF

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

Но есть изящное решение этой проблемы - переменные. Каждый атомарный элемент, идентифицируемый с помощью HEX-кода, такого как # FFFFFF, может быть сохранен и доступен в переменной для использования в препроцессоре. Это называется options или global. Это также касается остальных атомарных элементов, например шрифта или свойства обводки.

Для каждого цвета мы прописали ее собственную переменную, и таким образом наша цепочка токена стала выглядеть вот так:

$color-background-button-primary-default: $rubens

где $rubens это переменная для цвета #00BFFF

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

И вот как выглядит кусочек нашей цветовой базы теперь:

Для создания документации и оптимизации создания базы мы дополнительно написали инструкцию и мини-конструктор, чтобы дизайнерам-гуманитариям было проще.

В конце этой статьи мы бы очень хотели показать вам красивые метрики, степень увеличения time-to-market и ликующие лица, но это только начало пути. План внедрения полноценной цветовой базы у нас заложен в четвертый квартал, так что ждите новых статей и увлекательных историй.

Однако уже на этом этапе мы можем констатировать следующие достижения: