Design tokeny to nazwane wartości kolorów, odstępów, typografii i innych decyzji wizualnych, zapisane raz i używane zarówno w plikach projektowych, jak i w kodzie. Zamiast wpisywać w stu miejscach wartość #0055FF, zespół używa nazwy, na przykład color.action.primary, a samą wartość zmienia w jednym miejscu. Tokeny działają pod dwoma warunkami: są ułożone w poziomy, a projekt i kod czytają je z tego samego źródła.
Czym jest design token?
Token składa się z nazwy, wartości i typu (kolor, wymiar, krój pisma, czas trwania animacji, cień). Nazwa jest umową między projektantem a programistą: obie strony mówią „odstęp 200” albo „kolor akcji”, a konkretna liczba lub kod koloru przestaje krążyć w komentarzach i zrzutach ekranu.
Przez lata każde narzędzie zapisywało tokeny po swojemu. 28 października 2025 r. grupa Design Tokens Community Group działająca przy W3C opublikowała pierwszą stabilną wersję wspólnego formatu (2025.10). Specyfikacja formatu opisuje plik JSON z rozszerzeniem .tokens albo .tokens.json, w którym każdy token ma właściwość $value i typ $type, a odwołanie do innego tokena zapisuje się w nawiasach klamrowych. W ogłoszeniu wśród narzędzi obsługujących lub wdrażających standard wymieniono między innymi Figmę, Penpot, Sketch, Style Dictionary, Tokens Studio i Terrazzo. Dla zespołu oznacza to mniejsze uzależnienie od jednego narzędzia: ten sam plik da się wczytać w kilku miejscach.
Jakie są trzy poziomy tokenów?
Sedno tematu to rozdzielenie tego, jakie wartości istnieją, od tego, do czego służą.
| Poziom | Przykład nazwy | Wartość | Kto z niego korzysta |
|---|---|---|---|
| Prymitywny | color.blue.600 | #0055FF | Wyłącznie inne tokeny |
| Semantyczny | color.action.primary | {color.blue.600} | Projektanci i programiści w komponentach |
| Komponentowy | button.primary.background | {color.action.primary} | Jeden komponent |
Tokeny prymitywne to paleta: wszystkie odcienie, kroki skali odstępów i rozmiary pisma, bez informacji o zastosowaniu. Tokeny semantyczne nazywają rolę: tło powierzchni, tekst drugorzędny, kolor błędu, obramowanie pola. Tokeny komponentowe są opcjonalne i przydają się dopiero wtedy, gdy jeden komponent musi odbiegać od reguły ogólnej.
Zasada, która trzyma całość: komponent nie sięga bezpośrednio do tokena prymitywnego. Jeżeli przycisk używa color.blue.600, zmiana koloru akcji wymaga przeszukania wszystkich komponentów. Jeżeli używa color.action.primary, wystarcza zmiana jednego odwołania. Większości produktów wystarczają dwa pierwsze poziomy.
Jak tokeny obsługują tryb ciemny i kilka marek?
Token semantyczny może mieć inną wartość w każdym trybie. color.surface.default wskazuje jasny odcień w trybie jasnym i ciemny w trybie ciemnym, a komponent o tym nie wie, bo zna tylko nazwę. Ten sam mechanizm obsługuje warianty marek, gęstość interfejsu i wersję o podwyższonym kontraście.
W Figmie służą do tego tryby zmiennych: jedna zmienna przechowuje po jednej wartości na tryb, a liczba dostępnych trybów zależy od planu. Format 2025.10 opisuje motywy i wiele marek bez powielania plików. W aplikacji Daily Effect, którą projektowaliśmy, komponenty oparte o zmienne obsługują tryb jasny i ciemny oraz dwa warianty kolorystyczne, a zmiany wizualne wprowadza się w jednym miejscu.
Bez poziomu semantycznego tryb ciemny jest niewykonalny w rozsądnym koszcie, bo nie ma czego przełączać: prymitywny niebieski pozostaje niebieski w każdym trybie.
Jak wartości trafiają z Figmy do kodu?
Przepływ ma cztery kroki i jeden kierunek.
- Źródło. Zespół wybiera jedno miejsce, w którym tokeny się edytuje: zmienne w Figmie albo plik JSON w repozytorium. Druga strona tylko czyta.
- Eksport. Figma importuje i eksportuje zmienne w formacie JSON zgodnym ze standardem Design Tokens Community Group. Alternatywą jest wtyczka Tokens Studio, znana wcześniej jako Figma Tokens.
- Przekształcenie. Style Dictionary zamienia plik tokenów na formaty platform: zmienne CSS, zasoby dla iOS i Androida, moduły JavaScript. Narzędzie obsługuje format grupy od wersji 4, a pełna obsługa wydania 2025.10 jest według jego dokumentacji w toku.
- Użycie. Komponenty w kodzie odwołują się do wygenerowanych zmiennych, na przykład -color-action-primary, i nie zawierają wartości wpisanych ręcznie.
Zmiana wartości tokena dociera tylko tam, gdzie tokeny są faktycznie użyte. Każdy kolor i odstęp wpisany w kodzie na sztywno zostaje po staremu, dlatego wdrożenie zaczyna się od policzenia takich miejsc, a kończy regułą w narzędziu do kontroli kodu, która nie przepuszcza nowych.
Jak nazywać tokeny, żeby nazwy wytrzymały rozwój produktu?
- Nazwa opisuje przeznaczenie, a wygląd zostaje w wartości. color.text.danger przetrwa zmianę palety, color.red już nie.
- Kolejność od ogółu do szczegółu: kategoria, rola, wariant, stan. Na przykład color.border.input.focus.
- Jeden język i jeden zapis w projekcie i w kodzie. Angielski jest praktyczny, bo tak nazywa się właściwości w CSS. Style zapisu porównuje wpis o konwencjach nazewnictwa w kodzie.
- Skale liczbowe z zapasem (100, 200, 300) dla odstępów i rozmiarów, żeby dało się dodać krok pośredni bez zmiany nazw.
- Wycofywanie zamiast kasowania. Format 2025.10 przewiduje właściwość $deprecated, dzięki której stary token zostaje oznaczony i znika dopiero po migracji.
Pięć błędów przy wdrażaniu tokenów
- Same prymitywy. Zamiana #0055FF na blue-600 niczego nie porządkuje, bo nazwa dalej nie mówi, gdzie koloru wolno użyć.
- Token na każde użycie. Setki tokenów komponentowych tworzonych na zapas to drugi arkusz stylów, którego nikt nie utrzymuje.
- Dwa źródła. Figma i kod edytowane niezależnie rozchodzą się w ciągu kilku wydań, a zespół przestaje ufać obu. Skalę rozbieżności pokazuje audyt design systemu.
- Brak właściciela. Bez osoby, która zatwierdza nowe tokeny, i bez opisanej ścieżki zgłoszenia każdy dodaje własne.
- Tokeny bez komponentów. Plik tokenów w repozytorium nie zmienia produktu, dopóki przyciski, pola i tabele faktycznie z niego nie korzystają. Od których elementów zacząć, podpowiada wpis o tym, co powinien zawierać design system.
Kiedy tokeny to za dużo?
Jeden produkt, jedna platforma, jeden motyw i jeden lub dwóch projektantów: w takim układzie wystarczają style w Figmie i kilkanaście zmiennych CSS. Pełny przepływ z eksportem i przekształceniem ma swój koszt utrzymania i zwraca się dopiero przy skali.
Tokeny zaczynają się opłacać, gdy zachodzi co najmniej jedna z czterech sytuacji: produkt działa na więcej niż jednej platformie, ma mieć tryb ciemny albo warianty marek, pracuje nad nim kilka zespołów, albo w planie jest zmiana identyfikacji wizualnej. O tym, kiedy cały system zaczyna być potrzebny, piszemy we wpisie design system: kiedy wdrożyć.
Dlaczego tokeny mają znaczenie przy kodzie generowanym przez AI?
Narzędzia generujące interfejs korzystają z tego, co znajdą w repozytorium i w poleceniu. Jeżeli znajdą plik tokenów i komponenty, które się do niego odwołują, nowy ekran może użyć istniejących nazw. Jeżeli nie znajdą nic, wpiszą własne wartości i każdy wygenerowany widok będzie miał trochę inny odstęp i trochę inny odcień. Kiedy wybrać no-code, low-code, AI czy tradycyjny kod, opisujemy w osobnym wpisie. Dlatego przy doprowadzaniu prototypu zbudowanego narzędziami AI do stanu produkcyjnego zostawiamy zespołowi design system i zasady pracy z tymi narzędziami.
Tokeny w projektach Squares
W usłudze Design system tokeny powstają na etapie fundamentów, po audycie, który pokazuje, ile wariantów tych samych elementów jest dziś w produkcie. Ustalamy z zespołem poziomy, nazewnictwo i źródło prawdy, a potem budujemy na nich bibliotekę komponentów. Design system wyceniamy projektowo, od 12 000 zł netto.
Najczęstsze pytania
Czym design token różni się od zmiennej CSS?
Zmienna CSS to jeden z formatów wyjściowych. Token jest zapisem niezależnym od platformy: z tego samego pliku powstają zmienne CSS dla aplikacji webowej, zasoby dla iOS i Androida oraz zmienne w Figmie. Zespół edytuje token, a pliki dla poszczególnych platform generuje narzędzie, na przykład Style Dictionary.
Czy zmienne w Figmie to to samo co design tokeny?
Zmienne w Figmie są sposobem przechowywania tokenów w narzędziu projektowym, razem z trybami. Tokenami w pełnym znaczeniu stają się wtedy, gdy te same nazwy i wartości trafiają do kodu. Figma importuje i eksportuje zmienne jako JSON zgodny z formatem Design Tokens Community Group, więc może być źródłem albo odbiorcą.
Czy tokeny mają sens bez design systemu?
Mają, ale ograniczony. Sam plik tokenów porządkuje nazwy i wartości, natomiast spójność interfejsu daje dopiero biblioteka komponentów, która z nich korzysta, oraz zasady dodawania nowych. W praktyce tokeny są pierwszym etapem budowy design systemu, a nie osobnym projektem.
Ile poziomów tokenów potrzebuje produkt?
Większości produktów wystarczają dwa: prymitywny i semantyczny. Poziom komponentowy przydaje się, gdy pojedynczy komponent musi odbiegać od reguły ogólnej albo gdy kilka marek różni się na poziomie komponentów. Dodawany na zapas tworzy setki nazw, których nikt nie utrzymuje.
