liquiddesign

Zasada 08

Kolor nie działa solo

Około 8 procent mężczyzn myli czerwień z zielenią, a każdy użytkownik miewa ekran w pełnym słońcu. Kolor wzmacnia znaczenie, ale nie może go nieść w pojedynkę: obok zawsze stoi label, ikona albo wzór.

Status systemu na dwa sposoby

Włącz skalę szarości, czyli świat części daltonistów i ekranów w słońcu. Lewa kolumna traci znaczenie, prawa czyta się dalej.

✕ Sam kolor

  • API produkcyjne
  • Kolejka raportów
  • Płatności

✓ Kolor, ikona i etykieta

  • API produkcyjneDziała
  • Kolejka raportówOpóźnienia
  • PłatnościAwaria

Reguły

  • Każdy status ma oprócz koloru etykietę tekstową albo ikonę o innym kształcie.
  • Tekst trzyma kontrast co najmniej 4.5:1, duże napisy i ikony co najmniej 3:1.
  • Interfejs przechodzi test w skali szarości bez utraty informacji.
  • Czerwień i zieleń nigdy nie są jedyną różnicą między successem a błędem.

Wzorzec w kodzie

Status niesie kolor, kształt ikony i słowo naraz
<Badge tone="danger">
  <IkonaAwarii aria-hidden className="mr-1.5 size-3.5" />
  Awaria
</Badge>
Test skali szarości, jedna linia w konsoli przeglądarki
document.documentElement.style.filter = "grayscale(1)";

Prompt dla Claude

Wklej do Claude Code w swoim projekcie. Prompt niesie komplet reguł tej lekcji i ogólne zasady Liquid Design, więc implementacja trafia w metodologię bez tłumaczenia jej od zera.

Prompt do wklejenia
Zastosuj w moim projekcie zasadę „Kolor nie działa solo" z metodologii Liquid Design.

Status niesiony samym kolorem znika przy daltonizmie, w słońcu i na złym ekranie. Ikona i tekst zostają.

Wymagania:
- Każdy status ma oprócz koloru etykietę tekstową albo ikonę o innym kształcie.
- Tekst trzyma kontrast co najmniej 4.5:1, duże napisy i ikony co najmniej 3:1.
- Interfejs przechodzi test w skali szarości bez utraty informacji.
- Czerwień i zieleń nigdy nie są jedyną różnicą między successem a błędem.

Ogólne reguły Liquid Design, których implementacja nie może złamać:
- HTML jest semantyczny: button, a, nav, form, label, dialog, details, ul, dl i nagłówki h1-h6 zamiast div z onClick i ARIA dopisywanym ręcznie. div i span służą wyłącznie do layoutu, nigdy do interakcji ani struktury treści.
- Layout jest umową: treść, która dociera później, ma miejsce zarezerwowane od pierwszego renderu. Nic nie skacze.
- Stany ładowania, pustki, błędu i treści dzielą jeden layout.
- Typografia pochodzi z nazwanej, płynnej skali opartej o clamp(), nie z gołych rozmiarów.
- Animacje dotyczą wyłącznie transform i opacity, a prefers-reduced-motion redukuje je do natychmiastowej zmiany stanu.
- Breakpoint jest ostatecznością: najpierw container queries i repeat(auto-fit, minmax(...)).

Sposób pracy – zanim napiszesz pierwszą linię kodu:
- Sprawdź w plikach projektu, jak stylowane są komponenty (Tailwind, CSS Modules, vanilla-extract, styled-components, Sass, czysty CSS...) i pisz wyłącznie w tej konwencji. Niczego nie zakładaj z góry i nie dodawaj nowych zależności.
- Wymagania powyżej opisują właściwości CSS i atrybuty HTML, nie klasy narzędziowe. Przełóż je na system stylowania zastany w projekcie.
- Sprawdź framework komponentów, wersję i konwencje nazewnictwa, zamiast zakładać konkretny stack.
- Używaj istniejących tokenów projektu (kolory, typografia, odstępy). Jeśli czegoś brakuje, zaproponuj minimalne uzupełnienie w duchu istniejącego kodu, nie osobny system.
- Nie używaj klas, tokenów ani API, których nie znalazłeś w tym projekcie.

Pełny opis z żywym demo i kodem: https://liquid-design.website/zasady/kolor