Как собрать гармоничную цветовую палитру для сайта: теория и практика

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

Про сами цветовые модели (HEX, RGB, HSL) и про то, как формально считается контраст по WCAG, мы уже писали отдельно. Здесь — именно про процесс: как дойти от пустого экрана до согласованной палитры, которую можно закодировать в Tailwind-конфиг или CSS-переменные.

С чего начинается палитра

Не с цветов. Сначала — с трёх вопросов:

1. Какую эмоцию должен вызывать продукт? Финтех и доверие — обычно синий/тёмно-синий. Здоровье и забота — зелёный, мягкий. Развлечения — может быть что угодно яркое. Это не строгие правила, а отправная точка, от которой можно осознанно отклониться.
2. Кто аудитория и в каком контексте смотрит интерфейс? B2B-дашборд, который открывают по 6 часов в день, не должен утомлять глаза кислотными акцентами. Лендинг с одним CTA может себе позволить куда больше контраста и яркости.
3. Какие ограничения уже есть? Логотип, фирменный цвет из брендбука, цвета, зашитые в существующий UI-кит — палитру выгоднее строить вокруг них, а не игнорировать.

Только после этого имеет смысл открывать генератор палитры.

Анатомия рабочей палитры

Рабочая палитра для сайта или приложения — это не один цвет, а пять ролей:

1. Основной (primary)

Цвет бренда. Используется для ключевых CTA, активных состояний, акцентных элементов. Должен быть один — если «основных» несколько, интерфейс теряет иерархию: пользователь не понимает, на что в первую очередь смотреть.

2. Вторичный (secondary)

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

3. Нейтральная шкала (neutrals)

Это не «один серый», а шкала из 8-10 оттенков от почти белого до почти чёрного. Именно нейтралы делают 80% интерфейса — фон, текст, границы, разделители. Хорошая нейтральная шкала с правильным контрастом между соседними ступенями экономит больше времени дизайнера, чем любой яркий акцент.

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

4. Семантические цвета (status colors)

Успех, ошибка, предупреждение, информация — зелёный/красный/жёлтый/синий (или их вариации). Это единственное место, где стоит держаться близко к интуитивным ассоциациям пользователя: красный для ошибки почти универсален, экспериментировать здесь рискованно.

5. Акцентные цвета (accents)

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

Как подбирать оттенки внутри роли

Современный подход — не «5 случайных цветов», а шкала оттенков одного тона (50, 100, 200 ... 900, как в Tailwind). Это даёт гибкость: светлый оттенок primary для фона уведомления, тёмный — для текста на этом фоне, при этом всё визуально согласовано, потому что построено из одной точки в цветовом пространстве.

Технически это делается через HSL: меняя только Lightness (и слегка Saturation) при фиксированном Hue, получаете согласованную шкалу одного цвета. Полностью вручную считать не нужно — для этого и существуют генераторы палитр, которые строят шкалу по базовому цвету автоматически.

Частые ошибки

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

Игнорирование тёмной темы на старте. Если тёмная тема вообще планируется, проектировать палитру нужно сразу с учётом обеих — иначе потом окажется, что половина оттенков на тёмном фоне просто не читается.

Цвета «по ощущению», без проверки контраста. Красивая палитра в Figma может полностью провалиться по доступности в реальном UI. Нейтральные и семантические цвета особенно важно проверить на контраст текста к фону — это не эстетическая придирка, а требование для части аудитории, которая иначе не сможет прочитать интерфейс.

Слишком насыщенные цвета на больших площадях. Цвет, который отлично смотрится на кнопке 40×120px, может быть невыносимым, если им залить весь фон секции. Перед утверждением палитры полезно посмотреть на цвета не только в свотчах, а в реальных пропорциях интерфейса.

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

Чек-лист перед утверждением палитры

• Определена одна основная роль (primary) — без конкуренции нескольких «главных» цветов;
• Нейтральная шкала состоит минимум из 6-8 ступеней, а не одного серого;
• Семантические цвета (успех/ошибка/предупреждение) интуитивно понятны и не пересекаются с акцентами;
• Текстовые пары (текст на фоне) проверены на контраст;
• Палитра протестирована в реальных пропорциях интерфейса, а не только в свотчах;
• Учтена тёмная тема, если она в планах;
• Палитра зафиксирована как переменные (CSS custom properties, Tailwind config, design tokens) — а не «помню примерные HEX-коды».

Заключение

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

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