Як OKLCH допоміг мені перестати підбирати UI-кольори на око

Anna Loban — Thu, 02 Jul 2026 13:31:03 +0000

Зараз я працюю над конструктором сайтів для недизайнерів.
У такому продукті користувач може змінювати тему, фон, акцентний колір і стилі кнопок. Але він не має розуміти контраст, колірні моделі чи UI-стани.Тому колір не може просто добре виглядати в одному вибраному варіанті. Він має залишатися читабельним і передбачуваним у всій системі.

Нещодавно я почала детальніше розбиратися з OKLCH.
Коротко: OKLCH — це колірна модель у CSS, яка описує колір ближче до того, як ми його сприймаємо: через perceptual lightness, chroma і hue.

Порівняно з HSL, lightness в OKLCH поводиться передбачуваніше. Два кольори з однаковим значенням lightness зазвичай сприймаються ближче за візуальною яскравістю.
Для UI це виявилося дуже практичним. Замість того щоб підбирати кожен колір вручну, можна виводити пов’язані значення з однієї логіки.

Наприклад, фон, CTA, hover, border або shadow можуть бути не випадковими окремими значеннями, а пов’язаними кольорами.
Коли підбираєш кольори на око, усе зазвичай виглядає нормально до першого edge case.

Фон м’який. Кнопка помітна. Потім змінюєш hue, перевіряєш hover, border, shadow, текст на кнопці або перемикаєш тему — і система починає розвалюватися.

Типові проблеми:

фон і кнопка занадто близькі за світлотою;
CTA втрачає контраст;
hover виглядає брудно;
border здається випадковим;
shadow не пов’язаний із кнопкою;
текст на кнопці читається гірше, ніж очікувалося;
акцентний колір, вибраний користувачем, ламає весь інтерфейс.

На звичайному сайті більшість цього можна поправити вручну. У конструкторі це не масштабується. Користувачі будуть створювати власні комбінації, і система має допомагати їм не отримати нечитабельний UI.

В OKLCH колір описується трьома частинами:

L — perceptual lightness, сприймана світлота;
C — chroma, інтенсивність кольору;
H — hue, відтінок.

Найкорисніше для мене — можливість окремо змінювати lightness і chroma, зберігаючи той самий hue.
Так простіше зробити колір світлішим, темнішим, м’якшим або глибшим, не втрачаючи зв’язок з оригінальним кольором.

Наприклад:
--background: oklch(98% 0.015 260);
--primary: oklch(58% 0.18 260);
--primary-text: oklch(99% 0.01 260);
--primary-hover: oklch(52% 0.17 260);

Логіка проста:
фон залишається дуже світлим і спокійним;
кнопка помітно темніша й інтенсивніша;
текст на кнопці залишається читабельним;
hover залишається в тій самій колірній сім’ї, тому відчувається як стан, а не як випадковий новий колір.
Це не замінює перевірку контрасту. Але зменшує ручне вгадування: частину колірних пар можна будувати за зрозумілим правилом.

Маленький приклад — тінь кнопки.
Я перевірила це в CodePen. Замість того щоб вручну вибирати shadow color, можна взяти колір кнопки й зробити його темнішим через OKLCH:

oklch(from var(--button) calc(l - 0.15) c h / 0.45)

Тінь зберігає той самий hue і chroma, але отримує нижче значення lightness. Тому вона все ще виглядає візуально пов’язаною з CTA, а не як випадкова сіра чи чорна тінь.
Це невеликий приклад, але він добре показує принцип: користувач змінює один колір, а система будує пов’язані значення навколо нього.

Для конструктора головне не сама палітра. Важливо, як колір поводиться в різних станах: фон, кнопка, текст на кнопці, hover, border, shadow, disabled...

Користувач вибирає настрій теми. Система допомагає зберегти інтерфейс читабельним і акуратним.

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

CodePen playground: https://codepen.io/anna-loban/pen/vEyOraY

UXPUB 🇺🇦 Дизайн-спільнота: Anna Loban

Як OKLCH допоміг мені перестати підбирати UI-кольори на око