Как использовать семантические цветовые токены

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

Семантические цветовые токены делают такие решения явными. Базовый токен называет цветовое значение, например green-700. Семантический токен называет его задачу, например action-primary-background или status-success-text. Компоненты ссылаются на задачу, чтобы при обновлении бренда можно было изменить нужные роли, случайно не затронув все применения похожего оттенка.

Начните с ошибки, которую хотите предотвратить

Представьте рабочее пространство с кнопкой «Создать проект», подтверждением «Сохранено», сообщением об ошибке и выбранной ссылкой в боковой панели. Первый дизайнер выбрал один и тот же тёмно-зелёный цвет для кнопки, подтверждения и выбранной ссылки. Разработчик вполне разумно сохранил это значение один раз и использовал повторно. Теперь новое направление бренда требует другого основного цвета.

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

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

Как Atlassian показывает роли непосредственно в интерфейсе

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

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

Для небольшой системы сначала позаимствуйте этот приём, а не весь набор названий. Поместите предлагаемый токен рядом с реальным применением, опишите, что должно вызывать его изменение, и покажите один случай, которым он не должен управлять. «Фирменное действие» и «успешная операция» могут сначала использовать одинаковый зелёный, оставаясь независимыми решениями. Если ваша карта не позволяет выразить эту разницу, она хранит палитру, а не семантику интерфейса.

Сделайте проверку зависимостей конкретной

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

:root {
  --palette-green-700: #236646;
  --palette-purple-700: #6439a8;
  --action-primary-bg: var(--palette-green-700);
  --action-primary-fg: #fff;
  --status-success-text: var(--palette-green-700);
}
[data-brand="purple"] {
  --action-primary-bg: var(--palette-purple-700);
}

Изменение атрибута бренда должно менять элементы, использующие --action-primary-bg. Оно не должно менять подпись об успехе, использующую --status-success-text. Если меняются оба элемента, проверьте реальные ссылки в компонентах, прежде чем выбирать новый оттенок. Если не меняется ни один, поищите жёстко заданный цвет или более специфичное переопределение. Это проверка зависимостей; иллюстративные значения всё равно требуют проверки контраста в реальных условиях применения.

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

Проверьте миграцию в три прохода:

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

Разделяйте значения, роли и решения отдельных компонентов

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

Например, neutral-950 может хранить самый тёмный нейтральный цвет. И text-primary, и border-strong поначалу могут ссылаться на него. Это всё равно разные роли, поскольку улучшение читаемости основного текста необязательно должно затемнять каждую выраженную границу. Одинаковые значения сегодня не доказывают, что два решения навсегда должны делить одно имя.

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

Имена должны помогать правильно выбирать токен без необходимости открывать каждый компонент. Разработчик, ищущий границу поля с ошибкой, не должен гадать, означает ли опасность accent-strong, special-red или brand-secondary. Предпочитайте понятную роль остроумному сокращению, особенно если тот же контекст будет использовать агент для работы с кодом.

Свяжите семантические цвета с ролями в интерфейсе

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

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

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

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

Проработайте смену бренда до окончательного решения

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

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

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

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

Опишите состояния, не создавая отдельный цвет для всего

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

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

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

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

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

Дополняйте цвет понятным смыслом

Цвет облегчает беглый просмотр интерфейса, но смысл должен сохраняться и тогда, когда оттенок трудно различить. Одна красная граница заставляет пользователя догадываться, что пошло не так. Метка ошибки и полезное сообщение об исправлении делают состояние понятным. Аналогично значок успеха с надписью «Изменения сохранены» сообщает больше, чем зелёная точка без подписи.

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

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

Для обычного текста критерий минимального контраста WCAG в общем случае требует 4.5:1; для крупного текста, отвечающего установленным условиям, — 3:1, с предусмотренными исключениями. Объяснение W3C о контрасте уточняет область применения и детали. Измеряйте реальную пару в фактическом отображении: прохождение одной пары не подтверждает соответствие компонента, темы или целого сайта.

Предыдущие значения из примера позволяют увидеть это конкретно. Расчёт относительной яркости для зелёного #236646 и фиолетового #6439a8 даёт контраст с белым 6.86:1 и 7.80:1. С чёрным те же заливки дают 3.06:1 и 2.69:1. Следовательно, обе заливки позволяют использовать белую надпись при пороге для обычного текста, но ни одна не обеспечивает этот порог с чёрной. Результат определяется не семантическим именем, а конкретными значениями переднего плана и фона. Храните расчёт вместе с этой парой, чтобы будущий переход к более светлому фирменному цвету запускал новую проверку.

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

Рассматривайте тёмную тему как новое сопоставление

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

Не инвертируйте механически каждый базовый цвет и не используйте значения светлой темы на тёмной странице без пересмотра. Заново оцените отношения. Яркое действие, уравновешенное на белом, может доминировать на тёмной поверхности. Граница, мягко различимая на светлой панели, способна исчезнуть. Изображения, логотипы и графики также могут требовать решений за пределами карты семантических цветов.

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

При таком сравнении имена ролей должны оставаться неизменными. Если в тёмной теме вы начинаете переименовывать text-primary в white-text, вы возвращаете цветовое значение в имя, предназначенное для описания задачи. Сохраняйте постоянный смысл роли и меняйте сопоставление, которое его обеспечивает.

Передайте агенту для работы с кодом карту ролей, а не только палитру

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

В поддерживаемых HTML-предпросмотрах OpenDesign можно оценивать отображённый результат, использовать доступные средства ручного изменения стилей и прикреплять к нужной области комментарии для обсуждения. Используйте эти возможности, чтобы указать конкретное несоответствие, например сообщение об успехе, оформленное как основное действие. В замечании следует назвать и предполагаемую роль, и видимое место.

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

После визуального исправления проверьте ссылку компонента в сгенерированных файлах. Кнопка может выглядеть правильно, но всё ещё использовать токен успеха; следующая смена темы снова обнаружит ту же ошибку зависимостей.

Сначала перенесите один характерный компонент

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

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

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

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

Что должно остаться после полезной проверки токенов

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

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