Кастомизация! Красим yclients в 16,7 млн цветов

yclients — Виджет онлайн-записи на услуги в 57 странах + ERP

3 млн MAU, 31к юзеров
Основной сегмент — сфера красоты, но по факту любые услуги с записью ко времени: от врачей до шиномонтажа.

Дизайн не менялся с основания. До прихода нашей команды была одна попытка — 1,5 года старая команда делала «новую» версию — так и не запустили.

Задача: пользователь выбирает любой HEX цвет из палитры и весь виджет раскрашивается в оттенки этого цвета

Решение сделано в 2020 году, до появления токенов в фигме

Дано: Новая версия не имеет кастомизации, она просто желтая. Задача актуальна, так как кастомизации цветов пользуются 64% пользователей старой версии. Остальные 26% процентов пользуются черно-белой.

Виджет поддерживает инъекции кода, то есть люди могли красить любые элементы как попало через CSS минуя настройки в ERP. Это осложняет работу с данными.
У нас может быть темный или светлый фон, (а в будущем и цветной)
Юзер может выбрать любой цвет из палитры: белый на белом, черный на черном, а Мы должны сохранить читаемость элементов интерфейса.
Опасно заменять цвета юзеров на другие (кроме нейтральных черного и белого) — может завалить поддержку и спровоцировать отвалы клиентов со специфическими вкусами
Нельзя все красить в ЧБ, даже если юзер выберет малочитаемый цвет — он должен присутствовать в интерфейсе, чтобы не ронять бренд!
Юзер может выбрать цвета из зоны Color Blind, т.е. неконтрастные и к белому и к черному, тогда нам нужно не дать человеку выстрелить себе в ногу

Юзер может выбрать любой из 16.7 миллионов цветов...

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

Важно было чтобы элементы и тексты всегда были читаемы. Нужно встроить WCAG чекер.
Он помогает проверить насколько читаемы элементы для людей с нарушениями зрения.
Контраст текста должен был быть > 4.5,
Контраст элементов > 3

Как поделить цвета на группы?

Сначала я попробовал перевести цвета в формат HSL
H – оттенок: желтый, красный
S – яркость: от серого до насыщенного
L – светлость: от белого до черного

И разделить цвета математически. Меня заинтересовал параметр L (lightness), потому что позволяет построить палитры и отделять слишком бледные и темные цвета. Я думал, что L = 100—90 бледные цвета, а 90–50 яркие.

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

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

Коэффициент контраста между цветом пользователя и фоном

Более грамотно делить цвета на группы по контрасту WCAG и тогда чтобы не вбил пользователь, его цвет попадет в одну из 5 групп:

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

Собираю UI кит, которые мы позже приведем к общему виду с готовыми компонентами из сторибука — вот и первый подход к дизайн системе.

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

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

Теперь нужно покрасить макеты и протестировать на цветах максимально близких к границе своего диапазона.

Про белый на белом

Если юзер выбирает бледно-салатовый, и нужно использовать этот цвет, как брендовый, то есть 2 варианта:

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

Я рискнул добавить яркости, если будут жалобы — всегда можно заменить на серый.

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

Что получилось

Миграция

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

Нам нужно выбрать 1 главный цвет для каждого из 27 000 виджетов. У меня есть цвета, которые они выбирали для разных элементов, надо понять какой их них выбрать. Я выписал предположения:

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

Значит надо понять у кого фон белый, а у кого черный.

Я написал алгоритм на основе WCAG чекера, и отдал его аналитикам

1 этап: Делаем проверку цвета фона
Если bg / ffffff <= 1,2— то фон белый
Если bg / 000000 <= 1,2
— то фон черный


2 этап: Делаем проверку цвета кнопки
Если btn / ffffff <= 1,2
— то кнопка белая

Если btn / 000000 <= 1,2
— то кнопка черная


3 этап: Определим брендовый цвет по имеющимся данным

3.1 Фон белый или черный + Кнопка цветная;
Брендовый цвет = цвет кнопки

3.2 Фон цветной + Кнопка белая или черная;
Брендовый цвет = цвет фона

3.3 Фон белый или черный + Кнопка белая или черная;
Брендовый цвет = цвет кнопки

3.4 Фон цветной + Кнопка цветная
Брендовый цвет = цвет кнопки

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

Спасибо, что прочитали этот трактат!
Он получился таким длинным и подробным, потому что является частью инструкции для будущих дизайнеров yclients.