Poniższe notatki powstały na podstawie prezentacji „Design Tokens for Dummies | A Complete Guide”. Wszystkie opisane koncepcje, strategie i przemyślenia pochodzą od autora prezentacji.

TL;DR

Tokeny projektowe to małe, wielokrotnego użytku decyzje projektowe definiujące wizualny styl systemu projektowego
Spójna konwencja nazewnictwa zapobiega błędom przy wyborze odpowiednich tokenów
Architektura trzystopniowa (brand → alias → mapped) stanowi rozwiązanie dla dojrzałych systemów korporacyjnych
Podejście dwustopniowe (primitive → semantic) sprawdza się przy rozpoczynaniu pracy z tokenami
Nie wszystkie kolory ze skal potrzebują ról – należy używać tylko te, których rzeczywiście potrzebujesz
Dokumentacja systemu pozostaje kluczowa dla prawidłowego stosowania tokenów przez zespół
Kolekcja responsywna obsługuje różne rozmiary czcionek oraz odstępów na różnych urządzeniach

Tokeny projektowe to koncepcja, którą Google definiuje jako małe, wielokrotnego użytku decyzje projektowe tworzące wizualny styl systemu projektowego. Prezenter wyjaśnia jednak, że ta definicja może brzmieć abstrakcyjnie. W związku z tym przedstawia praktyczne podejście do budowania skutecznego systemu tokenów.

Podstawy organizacji kolorów w tokenach projektowych

Struktura tokenów dla stanów komponentów

Autor prezentacji pokazuje, że każdy komponent wymaga czterech podstawowych tokenów kolorów. Na przykładzie paska powiadomień czy przycisku potrzebne są:

Ikona powodzenia – kolor ikon w stanie sukcesu
Tekst powodzenia – kolor tekstu w stanie sukcesu
Obramowanie powodzenia – kolor obramowania w stanie sukcesu
Powierzchnia powodzenia – kolor tła w stanie sukcesu

Ta sama logika dotyczy wszystkich stanów:

Informacja (niebieski)
Ostrzeżenie (pomarańczowy)
Błąd (czerwony)

Prezenter podkreśla, że spójna konwencja nazewnictwa jest kluczowa – zawsze zaczynamy od typu elementu (ikona, tekst, obramowanie, powierzchnia), a dopiero później dodajemy stan.

Tokeny akcji kontra „na akcji”

Częstym źródłem zamieszania pozostaje różnica między tokenami „akcji” a „na akcji”. Jak wyjaśnia autor, akcja to kolor głównych elementów interaktywnych (np. kolor przycisku), podczas gdy „na akcji” to kolor tekstów i ikon umieszczonych na elementach akcji.

Na przykład fioletowy przycisk ma powierzchnię akcji w kolorze fioletowym, jednak tekst na akcji jest biały. To rozróżnienie eliminuje błędy w nazywaniu tokenów. Gdyby tekst na przycisku miał token „tekst akcji”, byłby tego samego koloru co przycisk – fioletowy na fioletowym.

Wyłączony kontra „na wyłączonym” – mylące ale ważne rozróżnienie

Prezenter przyznaje, że tokeny wyłączone mogą być szczególnie mylące. W związku z tym pokazuje dwa różne przypadki:

Przycisk wyłączony – przycisk prowadzący do strony, która jest niedostępna (np. link do sekcji, której nie można odwiedzić). Z kolei przycisk „na wyłączonym” – przycisk reprezentujący stronę, na której już się znajdujemy, więc nie jest klikalny, ponieważ jesteśmy „na” tej opcji.

Autor zachęca do elastyczności w strukturze tokenów wyłączonych, gdyż projektanci preferują różne podejścia w zależności od kontekstu aplikacji.

Tokeny powierzchni – niedoceniane ale kluczowe

Powierzchnia strony – fundament każdej strony

Prezenter nazywa powierzchnię strony jednym z najbardziej niedocenianych tokenów. To kolor tła wszystkich stron w aplikacji. Bez tego tokena projektanci będą „strzelać” kolorem tła, próbując dopasować go wizualnie. W rezultacie powstają strony o subtylnie różnych kolorach tła, które psują spójność systemu.

Powierzchnia główna i drugoplanowa – hierarchia komponentów

Powierzchnia główna służy do głównych komponentów jak nawigacja górna czy boczna. Może być identyczna z powierzchnią strony lub lekko odmienna – to zależy od potrzeb projektu.

Powierzchnia drugoplanowa to kolor dla kart, okien modalnych oraz innych elementów wymagających wizualnego odróżnienia od tła strony. Prezenter podkreśla, że dokumentacja jest tutaj kluczowa – projektanci muszą wiedzieć, kiedy używać głównej a kiedy drugoplanowej, inaczej karty będą miały przypadkowe kolory.

Obramowanie główne – subtelne oddzielenie

Gdy mamy powierzchnię strony oraz powierzchnię główną, często potrzebujemy obramowania głównego dla subtelnego oddzielenia komponentów od tła. Zwykle to delikatny odcień szarości, który zapewnia wystarczający kontrast bez dominowania w projekcie.

Architektura tokenów projektowych – dwa główne podejścia

Podejście trzystopniowe (brand → alias → mapped)

Prezenter preferuje to rozwiązanie dla dojrzałych systemów. Składa się z trzech kolekcji:

Kolekcja marki – fundament wszystkich zmiennych
- Zawiera kolory w „czystej formie” (same kody hex)
- Nie ma przypisanych ról, jak pień drzewa w analogii autora
Kolekcja aliasów – łączy markę z kolekcją przypisaną
- Definiuje role kolorów (czerwona skala → „błąd”)
- Tutaj dodaje się różne marki
Kolekcja przypisana – najbardziej szczegółowy poziom
- Konkretne zastosowania („tekst błędu”, „powierzchnia informacji”)
- To co widzą oraz używają projektanci

Podejście dwustopniowe (primitive → semantic)

Prostsze rozwiązanie dla zespołów rozpoczynających pracę z tokenami:

Kolekcja pierwotna – pomija kolekcję marki
- Od razu definiuje kolory z ich rolami (powodzenie, błąd, ostrzeżenie)
- Kombinacja marki + aliasów z podejścia trzystopniowego
- Mniej złożone w zarządzaniu
Kolekcja semantyczna – odpowiada kolekcji przypisanej
- Zawiera konkretne zastosowania tokenów

Problem z kolekcją pierwotną: gdy masz wiele odcieni zieleni o różnych rolach, musisz tworzyć grupy jak „powodzenie”, „zielony”, „zielony-jasny”, „zielony-ciemny” w tej samej kolekcji. To może prowadzić do zamieszania – kolekcja aliasów właśnie to rozdzielenie czyni system jaśniejszym.

Praktyczna implementacja w Figmie

Budowanie kolekcji marki z uniwersalną skalą

Autor pokazuje przykład tworzenia skali kolorów z użyciem systemu numeracji 100-700. Kluczową zaletą jest możliwość dodawania wartości pośrednich – między 400 a 500 możemy wstawić 450 dla dodatkowego odcienia.

W kolekcji marki umieszczamy również rodziny czcionek oraz wagi czcionek, jednak prezenter ostrzega: sprawdź dostępne wagi w wybranych czcionkach. Jeśli Inter ma wagę „czarną” ale Roboto nie, Figma nie będzie wiedziała co zrobić z tokenem wagi czcionki dla Roboto.

Uniwersalna skala zastępuje chaos losowych wartości. Zamiast umieszczać szerokość obramowania i promień bezpośrednio w kolekcji marki, autor buduje jedną długą skalę (0, 1, 2, 4, 8, 16…) z której czerpią wszystkie elementy. To zapobiega dodawaniu kolejnych marek na poziomie aliasów – inaczej szerokość obramowania stałaby się częścią definicji marki.

Tworzenie połączeń między kolekcjami

Prezenter demonstruje jak kolory przepływają przez system na przykładzie zielonej skali. Poziom marki zawiera zielony-500 jako czysty kod hex. W kolekcji aliasów ten kolor staje się powodzenie-500. Z kolei w kolekcji przypisanej powodzenie-500 może być używany jako tekst-powodzenia czy obramowanie-powodzenia.

Kluczowa zasada spójności: autor zaleca utrzymywanie tych samych poziomów kolorów dla podobnych funkcji. Wszystkie tokeny tekstu mogą używać poziomu 500, wszystkie tokeny obramowania poziomu 600 – to upraszcza system oraz zwiększa przewidywalność.

Kluczowa zasada: nie wszystkie kolory ze skali potrzebują ról w kolekcji przypisanej. Autor ostrzega przed tworzeniem 50 odcieni zieleni – używaj tylko te kolory, których rzeczywiście potrzebujesz w komponentach.

Zarządzanie złożonością systemu

Wiele marek i tryb ciemny

Prezenter wyjaśnia gdzie dodawać różne warianty w architekturze systemu. Różne marki dodajemy na poziomie kolekcji aliasów – możemy mieć Markę A oraz Markę B z własnymi kolorami głównymi, ale używającymi tych samych skal z kolekcji marki.

Tryb jasny i ciemny implementujemy na poziomie kolekcji przypisanej. Tryb ciemny tworzy się przez odwrócenie kolorów – główny-100 z trybu jasnego staje się główny-700 w trybie ciemnym. Autor radzi zacząć od prostego odwrócenia, a potem dostosować w razie potrzeby (np. powodzenie-700 zmienić na powodzenie-600 dla lepszego kontrastu).

Stany najechania – kiedy potrzebujemy dodatkowych tokenów

Prezenter wyjaśnia, że nie zawsze wszystkie elementy potrzebują wariantów najechania. Powierzchnia akcji zmienia się na powierzchnię akcji przy najechaniu, jednak tekst na akcji oraz ikona na akcji mogą pozostać niezmienione, jeśli mają ten sam kolor w obu stanach.

Akcja najechania 2 to dodatkowy token dla specjalnych przypadków – gdy element na ciemnym tle ma jaśnieć przy najechaniu zamiast ciemnieć. To zapewnia elastyczność bez komplikowania podstawowej struktury.

Tokeny responsywne

Dla różnych rozmiarów ekranów autor wprowadza osobną kolekcję responsywną:

Rozmiary czcionek – różne rozmiary dla komputera/tabletu/telefonu
Wysokości linii – dopasowane do każdego rozmiaru
Odstępy akapitów – odstępy między akapitami
Odstępy komponentów – wypełnienie oraz luki w komponentach

Tokeny typografii i odstępów

Hierarchia typografii i dostępność

Prezenter rekomenduje strukturę od Bohatera (większy niż H1, dla banerów marketingowych) przez klasyczne H1-H6 (rozmiary od 72px do 20px) aż po tekst podstawowy.

Kluczowe odkrycie o dostępności: 16px to wartość bazowa, przy której każda czcionka zachowuje czytelność według standardów WCAG. Poniżej tej wartości trzeba bardzo uważać na wagę, styl oraz kontrast czcionek.

Podstawowe rozmiary to:

Akapit – 16px, główny tekst artykułów (bezpieczna wartość bazowa)
Akapit duży – 20px, idealne dla podtytułów na kartach
Akapit mały – 14px, wymaga ostrożności z dostępnością
Podpis – 12px, minimalna czytelna wielkość

Tekst nagłówków kontra tekst podstawowy – strategiczne rozróżnienie

Autor zaleca oddzielne tokeny kolorów dla nagłówków oraz tekstu podstawowego. Tekst nagłówków może być ciemniejszy (bardziej kontrastowy), podczas gdy tekst podstawowy lekko jaśniejszy – to naturalnie kieruje uwagę na hierarchię treści. Takie rozróżnienie zwiększa czytelność bez konieczności manipulowania wagami czcionek.

Uniwersalna skala odstępów i zasady projektowe

Zamiast losowych wartości, autor buduje skalę opartą na siatce 4px. Wszystkie wartości odstępów, szerokości obramowania oraz promienia pochodzą z tej samej skali, co zapobiega używaniu przypadkowych liczb przez projektantów.

Podstawowe wartości to zero (0) dla komponentów bez obramowania, 1px oraz 2px dla minimalnych elementów, 4px jako jednostka bazowa, następnie 8px-32px dla standardowych komponentów oraz 64px+ dla większych odstępów między sekcjami. System numeracji 100-900 (gdzie 100 = 4px, 200 = 8px) umożliwia łatwe dodawanie wartości pośrednich.

Zasada promienia: autor nie lubi używać nieparzystych liczb dla promienia obramowania, ale przyznaje że to kwestia preferencji markowych. Zaleca mieć „w zanadrzu” wartość 50 (lub podobną) dla elementów całkowicie zaokrąglonych jak przyciski pigułkowe czy okrągłe awatary.

Znaczenie dokumentacji

Prezenter wielokrotnie podkreśla, że nawet najlepsze tokeny są bezużyteczne bez dokumentacji. Projektanci muszą wiedzieć kiedy używać powierzchni głównej kontra drugoplanowej, jaka jest różnica między akcją a na-akcji, oraz które tokeny stosować w konkretnych komponentach.

Bez jasnych wytycznych zespół będzie „strzelał” oraz używał kolorów intuicyjnie, co niszczy spójność systemu. Dokumentacja powinna zawierać praktyczne przykłady zastosowań – konkretne komponenty z przypisanymi tokenami.

Lista kontrolna: budowanie tokenów projektowych krok po kroku

Planowanie i architektura

□ Przeanalizuj istniejące projekty – zidentyfikuj kolory, czcionki, odstępy które są już używane
□ Wybierz podejście – dwustopniowe dla prostoty, trzystopniowe dla firm ze złożonymi wymaganiami
□ Ustal konwencję nazewnictwa – ikona/tekst/obramowanie/powierzchnia + stan (powodzenie/błąd/ostrzeżenie)

Budowanie kolekcji

□ Stwórz skale kolorów – system 100-700 umożliwia łatwe skalowanie oraz dodawanie odcieni
□ Zdefiniuj typografię – rodziny czcionek, wagi (sprawdź dostępność!), uniwersalną skalę 4px
□ Przypisuj tylko potrzebne tokeny – nie każdy kolor ze skali musi mieć rolę w komponentach

Testowanie i wdrożenie

□ Przetestuj na rzeczywistych komponentach – czy wszystkie połączenia działają poprawnie
□ Sprawdź dostępność – kontrasty muszą spełniać standardy WCAG
□ Stwórz dokumentację – jasne przykłady kiedy używać powierzchni głównej kontra drugoplanowej
□ Przeszkol zespół – projektanci muszą rozumieć system zanim zaczną go używać

Kluczowy wgląd

Mniej tokenów = lepszy system

Standardowo myślimy: Skoro mam skalę z 10 odcieniami zieleni, powinienem wszystkie wykorzystać w systemie projektowym – przecież po co je tworzyć, żeby potem nie używać?

W praktyce okazuje się, że: Najlepsze systemy projektowe używają tylko 3-4 odcieni z każdej skali kolorów. Reszta to „materiał zapasowy” na przyszłość, jednak aktywne przypisywanie wszystkich odcieni prowadzi do chaosu w projekcie.

Dlaczego to jest istotne: Gdy projektanci mają do wyboru 10 odcieni zieleni z różnymi rolami, zaczynają „strzelać” który użyć w konkretnej sytuacji. W rezultacie powstają aplikacje z subtylnie różnymi kolorami wszędzie, które psują spójność systemu.

Test na jutro: Następnym razem gdy budujesz skalę kolorów, zamiast przypisywać wszystkie odcienie na konkretne role, wybierz tylko 3-4 które rzeczywiście potrzebujesz w komponentach oraz sprawdź czy system nie stał się prostszy w użyciu.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów oraz innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Design Tokens for Dummies | A Complete Guide

Tag: Zmienne Figma

Tokeny projektowe w design systemie – przewodnik #EN160

Figma Dev Mode MCP Server – rewolucja w generowaniu kodu z designu #EN159