O co chodzi z design tokens i dlaczego warto

Marek Szydełko
12.11.2025

Design tokens to najprościej „słowniczek” wyglądu Twojej marki zapisany w postaci nazwanych wartości. Zamiast pisać w pliku „zielony #1EAA6F”, nadajesz mu nazwę, np. color/brand/primary. To samo robisz z fontami, odstępami, promieniami zaokrągleń czy cieniami. Dzięki temu grafiki w Figma, komponenty na stronie i materiały reklamowe korzystają z tych samych ustaleń. Gdy zmienisz odcień zieleni, zmiana „przepłynie” przez cały system – bez ręcznego poprawiania setek plików.

Brzmi „enterprise”? Wcale nie musi. Mała firma też zyska: mniej poprawek, szybsze wdrożenia i mniej nieporozumień między grafikiem a wykonawcą strony. W praktyce wystarczy jeden dobrze nazwany zestaw tokenów i prosty rytuał ich utrzymania.

Co można zapisać jako token

Na start wystarczy kilka kategorii. Nie rozbudowuj systemu ponad potrzeby – to ma pomóc, nie dodawać papierologii.

  • Kolory: podstawowy, akcentowy, kolory tła, tekstu, stany (sukces, ostrzeżenie, błąd), odcienie dla hover i focus.
  • Typografia: rozmiary (np. h1, h2, body), waga, interlinia, odstępy między literami.
  • Odstępy: skala przestrzeni (np. 4, 8, 12, 16, 24, 32 px) – ta sama skala dla paddingów i marginesów.
  • Zaokrąglenia i cienie: promienie narożników dla przycisków, kart, inputów; cienie dla podbicia hierarchii.
  • Siatka i breakpointy: szerokości kontenera, punkty przełamań pod mobile i desktop.
  • Stany i interakcje: kolory i cienie dla hover, focus, disabled – to później oszczędza mnóstwo czasu.

Jak zacząć w Figma (bez zawiłej terminologii)

W Figma możesz utworzyć bibliotekę stylów i komponentów. Tokeny to po prostu nazwy dla tych stylów. Zrób plik „Design System – Tokens” i tam trzy rzeczy:

  • Style kolorów: utwórz małą paletę (np. brand/primary, brand/secondary, text/primary, text/secondary, ui/background, ui/border, state/success, state/warning, state/error). Nie używaj nazw typu „zielony jasny” – kolory mają znaczenie, nie odcień.
  • Style tekstu: nazwy po roli, a nie wielkości (np. heading/h1, heading/h2, text/body, text/small). Dzięki temu możesz zmienić rozmiar bez zmiany nazwy.
  • Skala odstępów: przygotuj komponent „Spacing” z opisem wartości 4–8–12–16–24–32 px. To prosty „słup” wartości, który każdy rozumie.

Następnie z tych stylów budujesz podstawowe komponenty: przycisk, pole formularza, karta. W opisie komponentu dopisz, które tokeny go zasilają. Jeśli jutro zmienisz promień narożnika z 8 na 12 px dla radius/md, wszystkie przyciski przyjmą nowy wygląd.

Nazewnictwo, które się nie mści

Dobre nazwy to 80% sukcesu. Uprość je i myśl o przyszłości. Najpierw określ strukturę: kategoria/podkategoria/rozmiar-stan. Kilka przykładów:

  • color/brand/primary – główny kolor marki.
  • color/text/secondary – słabszy kolor tekstu, np. opis pod nagłówkiem.
  • space/04 – odstęp 4 px (cyfry z wiodącym zerem ułatwiają sortowanie).
  • radius/md – średnie zaokrąglenie dla kart i przycisków.
  • shadow/card – standardowy cień dla kart.
  • font/heading/weight – waga fontu dla nagłówków.

Unikaj nazw „gdzie użyłem” (np. „kolor menu”) – bo kiedy zmienisz projekt, nazwa przestaje pasować. Nazwy powinny mówić „co to jest”, nie „gdzie to było”.

Kontrast i dostępność – prosty test, wielka różnica

Nawet najładniejsza paleta nic nie daje, jeśli tekstu nie da się odczytać. W tokenach ustal minimalne parametry kontrastu dla tekstu i stanów. Sprawdź, czy color/text/primary na ui/background ma odpowiedni kontrast. Jeśli nie, zmień kolory na poziomie tokenów, a nie w pojedynczych komponentach. Dzięki temu nie „zaśmiecisz” systemu wyjątkami.

Jak przełożyć tokeny z Figma na stronę

Jeśli Twój wykonawca korzysta z CSS, najłatwiej zapisać tokeny jako zmienne. Zamiast rozlewać kolory po całym projekcie, masz jeden blok, który kontroluje wygląd całego serwisu. Przykład idei (ale pamiętaj: bez wklejania do CMS, to tylko obraz):

  • --color-brand-primary: odpowiada color/brand/primary.
  • --space-04: odpowiada space/04.
  • --radius-md: odpowiada radius/md.

Ważne jest to, że nazwy w kodzie powielają nazwy z Figma. Kiedy grafik pisze „zmień radius/md na 12”, programista wie dokładnie, gdzie to zrobić. To likwiduje nieporozumienia „o który zielony chodzi?”.

Minimalny proces dla małej firmy

Nie potrzebujesz komitetów i godzin spotkań. Wystarczy lekki rytm pracy, który każdy ogarnie:

  • Raz na miesiąc – przegląd tokenów (15–30 minut). Czy coś się rozjechało? Czy trzeba dodać nowy stan do przycisku?
  • Przy nowym layoucie – najpierw definiujesz tokeny, dopiero potem rysujesz komponenty. Dzięki temu unikasz „wyrywanych z kapelusza” wartości.
  • Przy przekazywaniu do wdrożenia – eksport listy tokenów z Figma i krótkie „co to jest i gdzie używamy” w pliku tekstowym.

Najczęstsze błędy i szybkie poprawki

  • Za dużo na start. Masz 40 tokenów, a używasz 10. Zredukuj. Mniejszy zestaw szybciej się utrzymuje.
  • Nazwy po miejscach, nie po roli. Zmieniasz układ, stare nazwy nie mają sensu. Napraw to: nazwy po funkcji („brand/primary”), nie po miejscu („główne menu”).
  • Brak stanów interakcji. Użytkownik nie wie, co się dzieje po najechaniu czy focusie. Dodaj hover i focus do przycisków i linków jako osobne tokeny.
  • Wyjątki „na oko”. Ktoś dodał inny cień, bo „ładniej”. Jeśli to lepsze – wprowadź to do tokenów. Jeśli nie – usuń wyjątek. Porządek jest tu kluczem.
  • Kontrast „jak leci”. Tekst na zdjęciu ledwo widać. Zdefiniuj tokeny tła dla napisów na obrazach (np. półprzezroczysta nakładka) i trzymaj się ich.

Prosty plan wdrożenia w 10 krokach

  • Zrób listę elementów, które naprawdę tworzysz: przyciski, pola, karty, nagłówki, stopka.
  • Na tej podstawie wypisz, jakich kategorii tokenów potrzebujesz (kolor, tekst, odstępy, zaokrąglenia, cienie).
  • W Figma utwórz style kolorów i tekstu nazwane po roli, nie po odcieniu.
  • Ustal skalę odstępów i trzy poziomy zaokrągleń (sm, md, lg) – to wystarczy w 90% przypadków.
  • Zbuduj 3–5 komponentów bazowych (przycisk, karta, input, nawigacja, badge) i podłącz do tokenów.
  • Dodaj stany interakcji: hover, focus, disabled – jako osobne tokeny.
  • Uzgodnij z wykonawcą strony, jak odwzorować tokeny w kodzie (spójne nazwy).
  • Wprowadź prosty dokument „jak używać” – pół strony tekstu plus zrzuty z Figma.
  • Przetestuj kontrast i dostępność na dwóch typowych tle: białym i szarym.
  • Ustal rytm przeglądu: raz w miesiącu aktualizacja i czyszczenie wyjątków.

Jak to przekona zarząd albo klienta

Design tokens brzmią jak „nowinka dla geeków”, ale przekładają się na pieniądze. Zamiast przepisywać 20 ekranów po zmianie koloru, klikasz raz. Zamiast tłumaczyć programiście, „który niebieski” – podajesz nazwę tokenu. Zamiast łatać kontrast po zgłoszeniach, masz go ustawiony od początku. To mniej godzin na poprawki i mniej stresu tuż przed publikacją.

Co robić, gdy system rośnie

Jeśli po kilku miesiącach widzisz, że brakuje Wam skalowalności, rozbudowuj świadomie. Dodaj wersje tematyczne (np. light i dark), poszerz skalę odstępów, ale trzymaj nazwy i strukturę. Pamiętaj też o „wersjonowaniu” – nadaj numer paczce tokenów i zapisuj, co się zmieniło. Kiedy ktoś wróci do starszego projektu, będzie wiedział, z czego korzystał.

Podsumowanie w jednym akapicie

Zacznij mało i pożytecznie: kilka kolorów, skala odstępów, podstawowa typografia, zaokrąglenia i stany interakcji. Nazwy po roli, nie po miejscu. Tokeny w Figma i te same nazwy w kodzie. Jeden comiesięczny przegląd i zero wyjątków „na oko”. To wystarczy, by Twoje grafiki, strona i reklamy „mówiły jednym głosem” – bez biegania z wiadrem poprawek.

Źródła

  • https://www.w3.org/community/design-tokens/ – Strona społeczności W3C dotycząca standardu Design Tokens: koncepcje, słownictwo, kierunek rozwoju specyfikacji.
  • https://help.figma.com/hc/en-us/articles/1500005632141 – Dokumentacja Figma: praca ze stylami i bibliotekami komponentów (jak tworzyć i udostępniać style).
  • https://m3.material.io/foundations/design-tokens/overview – Material Design 3: omówienie design tokens na przykładzie systemu Material (kategorie, zastosowania, przykłady).
Zgłoś swój pomysł na artykuł

Więcej w tym dziale Zobacz wszystkie