Tokeny w Figma dla wielu marek: jak to zrobić bez ręcznego przepinania stylów

Jak zaprojektować strukturę tokenów (core vs semantic), żeby wspierała wiele marek?

Najbezpieczniejszy model dla wielu marek to rozdzielenie tokenów na co najmniej dwie warstwy: core i semantic. Tokeny core opisują surowe wartości projektowe, czyli np. konkretne kolory, skale odstępów, promienie, cienie czy rozmiary typografii. Są techniczne i nie powinny mówić nic o roli interfejsu. Tokeny semantic opisują znaczenie w UI, np. tło strony, kolor tekstu głównego, obramowanie pola, kolor przycisku primary. To właśnie warstwa semantic jest używana w komponentach.

W architekturze multi-brand marka nie powinna zmieniać nazw tokenów semantic, tylko ich mapowanie do tokenów core. Dzięki temu komponent nadal odwołuje się do color.background.default albo color.text.primary, ale dla każdej marki ten sam token semantic może wskazywać inny token core, np. inną paletę neutralną lub akcentową. To eliminuje ręczne przepinanie stylów, bo zmienia się źródło wartości, a nie logika komponentu.

Kluczowe jest, żeby warstwa core była stabilna i porządkowana według właściwości, a nie zastosowania. Dobre nazewnictwo to np. skale i warianty: color.blue.500, space.16, radius.8. Z kolei warstwa semantic powinna być budowana wokół funkcji interfejsu: color.surface.default, color.text.muted, color.action.primary.background. Jeśli do warstwy core trafią nazwy typu „button” albo „success”, granica między poziomami się zaciera i system przestaje być skalowalny.

Żeby struktura działała dla wielu marek, warto przyjąć zasadę, że brand różnicuje core, a produkt korzysta z semantic. Oznacza to, że każda marka może mieć własny zestaw tokenów bazowych, ale wspólny kontrakt semantyczny pozostaje taki sam. Jeśli jedna marka ma ciemniejszą paletę, bardziej zaokrąglone komponenty albo inną skalę typografii, podmieniasz odpowiednie tokeny core i utrzymujesz te same odwołania semantic. To pozwala zachować jeden system komponentów mimo różnych identyfikacji wizualnych.

W praktyce warto też unikać zbyt szczegółowych tokenów semantic zależnych od pojedynczego komponentu, jeśli ich znaczenie można opisać szerzej. Na przykład lepiej mieć color.action.primary.background niż osobny token przypisany wyłącznie do jednego konkretnego przycisku, o ile ten sam wzorzec może być użyty także gdzie indziej. Im bardziej semantic opisuje rolę, a nie implementację, tym łatwiej utrzymać spójność między markami.

Dobrze zaprojektowana struktura wygląda więc tak: core = wartości, semantic = znaczenie, a komponenty korzystają wyłącznie z warstwy semantic. To jest podstawowy warunek, żeby system tokenów wspierał wiele marek bez przebudowy komponentów i bez ręcznego podmieniania stylów.

Jak wykorzystać Variables i tryby (modes) w Figma do przełączania brandów?

W Figma najczyściej robi się to tak, że tworzysz jedną kolekcję zmiennych dla tokenów, a każdy brand zapisujesz jako osobny mode w tej samej kolekcji. Sama zmienna reprezentuje rolę w systemie, na przykład kolor tła, kolor tekstu, promień narożnika czy odstęp, a mode przechowuje konkretną wartość tej zmiennej dla danego brandu. Dzięki temu komponenty i ekrany nie odwołują się do „koloru marki A” lub „koloru marki B”, tylko do wspólnego tokena, na przykład color/background/default. Zmienia się tylko aktywny mode, a przypisania w projekcie pozostają bez ręcznego przepinania stylów.

Kluczowe jest rozdzielenie nazwy semantycznej od wartości brandowej. Jeśli przycisk korzysta ze zmiennej color/button/primary, to w mode dla pierwszej marki ta zmienna może mieć jedną wartość, a w mode dla drugiej inną. Ten sam mechanizm działa dla typografii, spacingu, border radius i innych właściwości obsługiwanych przez Variables. W praktyce oznacza to, że budujesz jeden zestaw komponentów oparty na tokenach, a przełączenie brandu polega na zmianie mode dla odpowiedniej kolekcji lub dla wybranego zakresu projektu.

Żeby to działało przewidywalnie, komponenty muszą być podpięte bezpośrednio do zmiennych, a nie do wpisanych ręcznie wartości. Jeżeli jakaś warstwa ma ustawiony kolor „na sztywno”, zmiana mode niczego tam nie przełączy. Dlatego najpierw przypisuje się zmienne do właściwości w komponentach bazowych, a dopiero potem korzysta z tych komponentów w makietach. Wtedy przełączenie mode aktualizuje wszystkie instancje zgodnie z mapą tokenów dla danego brandu.

Modes najlepiej traktować jako warstwę wariantów tej samej struktury tokenów, a nie jako osobne, niespójne zbiory. To ważne, bo każdy brand powinien mieć odpowiadający zestaw tych samych zmiennych, tylko z innymi wartościami. Jeżeli w jednym brandzie istnieje token, którego nie ma w drugim, przełączanie staje się niepełne i trudniejsze do utrzymania. Właśnie dlatego projektuje się wspólny model semantyczny, a marki różnicuje na poziomie mode.

W skrócie: Variables definiują role projektowe, a modes przechowują ich warianty dla poszczególnych marek. Dzięki temu zmiana brandu w Figma odbywa się przez przełączenie zestawu wartości tokenów, a nie przez ręczne zamienianie stylów w komponentach i ekranach.

Jak nazwać tokeny, żeby projektanci i developerzy rozumieli je tak samo?

Najważniejsza zasada jest prosta: nazwa tokena powinna opisywać rolę w systemie, a nie przypadkową wartość, wygląd albo implementację w jednym narzędziu. Jeśli token nazywa się blue-500 albo 16px, projektant widzi kolor lub rozmiar, a developer często nie wie, kiedy tego użyć. Jeśli nazywa się color.text.primary albo spacing.md, obie strony rozumieją, do czego służy.

Dobrze działające nazewnictwo zwykle opiera się na jednej, wspólnej strukturze: kategoria + rola + wariant. Przykładowo color.background.brand, color.text.secondary, space.component.sm, radius.card.md. Taki zapis jest czytelny zarówno w Figma, jak i w kodzie, bo nie zależy od konkretnej marki, heksadecymalnej wartości ani aktualnej decyzji wizualnej. Dzięki temu można zmienić wartość tokena bez zmiany jego znaczenia.

Żeby uniknąć nieporozumień, trzeba rozdzielić nazwy techniczne od semantycznych. Token bazowy może mieć nazwę związaną z paletą lub skalą, na przykład color.brand.600, ale token używany w interfejsie powinien mieć nazwę znaczeniową, na przykład color.action.primary.default. Projektant wybiera wtedy rolę w UI, a developer mapuje ją do tej samej roli w kodzie. To jest szczególnie ważne w projektach wielomarkowych, gdzie ten sam przycisk może mieć inny kolor w zależności od marki, ale nadal pełni tę samą funkcję.

Wspólny język wymaga też konsekwencji słownikowej. Jeśli raz używacie słowa primary, nie mieszajcie go z main albo default w podobnym znaczeniu. Jeśli surface oznacza tło komponentu, nie nazywajcie podobnych rzeczy raz background, a raz container, jeśli nie ma między nimi świadomej różnicy. Najczęstsze błędy biorą się nie z samego formatu nazw, tylko z niespójnych definicji pojęć.

Dobra nazwa tokena powinna odpowiadać na trzy pytania: czego dotyczy, jaką pełni rolę i w jakim kontekście lub stanie działa. Dlatego nazwy typu button-blue czy card-shadow-2 są słabe, bo łączą komponent z aktualnym wyglądem. Lepsze są nazwy typu color.action.primary.hover albo elevation.surface.raised, bo dają wspólne znaczenie niezależnie od zmian wizualnych.

Jeśli zespół ma rozumieć tokeny tak samo, potrzebuje nie tylko wzorca nazewniczego, ale też krótkich definicji dla kluczowych terminów. Samo secondary bywa niejasne, jeśli nie wiadomo, czy oznacza niższy priorytet akcji, alternatywny styl przycisku czy tekst pomocniczy. Dlatego nazwy powinny być osadzone w prostym, uzgodnionym słowniku systemu designu. W praktyce to właśnie połączenie semantycznych nazw i jednoznacznych definicji sprawia, że projektanci i developerzy interpretują tokeny identycznie.

Jak mapować kolory i typografię wielu marek na jeden zestaw tokenów semantycznych?

Najpierw trzeba rozdzielić wartości brandowe od znaczenia w interfejsie. Jeden zestaw tokenów semantycznych opisuje rolę, jaką dany kolor lub styl tekstu pełni w UI, a nie konkretną barwę czy font. Dlatego nie tworzy się tokenów typu blue-500 albo brandA-heading-font jako warstwy wspólnej dla wszystkich marek, tylko tokeny takie jak color.text.primary, color.background.accent, color.border.subtle, font.body.default, font.heading.l.

Mapowanie polega na tym, że każda marka dostarcza własny zestaw tokenów bazowych, a następnie przypisuje je do tego samego zestawu semantycznego. Przykładowo w jednej marce color.text.primary może wskazywać ciemny grafit, a w innej głęboki granat, ale w obu przypadkach znaczenie pozostaje identyczne: to podstawowy kolor tekstu. Analogicznie font.heading.l może mapować się na inny krój, wagę lub wysokość linii, o ile pełni tę samą funkcję nagłówka danego poziomu.

Kluczowe jest, aby semantyka była zdefiniowana na poziomie roli, nie wyglądu. Jeśli dwa tokeny różnią się tylko wartością, ale używa się ich w tym samym kontekście, powinny być jednym tokenem semantycznym z różnymi mapowaniami per marka. Jeśli natomiast dany element ma inną funkcję, powinien dostać osobny token, nawet jeśli wizualnie bywa podobny.

W praktyce dobrze działa zasada: najpierw znormalizuj role UI, potem przypisz do nich wartości marek. Dla kolorów zwykle obejmuje to tekst, tła, obramowania, stany interakcji, komunikaty i warstwy akcentowe. Dla typografii: role tekstowe, takie jak body, caption, label, heading oraz ich rozmiary lub poziomy. Nie warto mapować jeden do jednego całej palety ani wszystkich stylów brand booka, tylko te elementy, które rzeczywiście mają funkcję w systemie interfejsu.

Żeby to działało spójnie, nazwy tokenów semantycznych muszą być stabilne i niezależne od marki. Marka zmienia wtedy tylko przypisanie wartości, a komponenty nadal odwołują się do tych samych tokenów. To właśnie eliminuje ręczne przepinanie stylów: komponent nie „wie”, z jakiej marki korzysta, tylko używa tokenu o określonym znaczeniu.

Najczęstszy błąd to mieszanie poziomów abstrakcji, na przykład używanie tokenu primary raz jako koloru brandowego, a innym razem jako koloru przycisku. Taki token jest niejednoznaczny i trudno go mapować między markami. Poprawne mapowanie wymaga, by każdy token semantyczny odpowiadał jednemu, jasno określonemu zastosowaniu.

Jak zorganizować biblioteki i komponenty, żeby nie dublować elementów dla każdej marki?

Najbezpieczniejszy model to rozdzielenie struktury komponentów od warstwy wizualnej. Komponenty powinny być wspólne dla wszystkich marek, a różnice między markami powinny wynikać z przypiętych tokenów, nie z osobnych kopii tych samych elementów. W praktyce oznacza to, że przycisk, input czy karta istnieją raz jako komponent bazowy, a marka zmienia tylko wartości kolorów, typografii, odstępów czy promieni przez zestawy tokenów.

Dobra organizacja zwykle opiera się na trzech poziomach. Po pierwsze, biblioteka foundation z tokenami i stylami opartymi na tokenach. Po drugie, biblioteka komponentów, która używa wyłącznie tokenów semantycznych, a nie twardo wpisanych wartości. Po trzecie, opcjonalnie warstwa brandowa, jeśli dana marka potrzebuje własnych assetów lub wyjątków, których nie da się obsłużyć samą zmianą tokenów. Dzięki temu większość systemu pozostaje wspólna, a różnice są kontrolowane centralnie.

• Nie duplikuj komponentu, jeśli zmienia się tylko wygląd — użyj tych samych komponentów i innych tokenów dla marki.
• Twórz warianty tylko dla różnic funkcjonalnych — np. stanów, rozmiarów, układów, a nie dla samej zmiany koloru marki.
• Oddziel tokeny globalne od semantycznych — komponent powinien korzystać z ról typu button/primary/background, a nie bezpośrednio z konkretnych wartości.
• Wydzielaj osobne komponenty brandowe tylko tam, gdzie naprawdę zmienia się konstrukcja — np. inna anatomia nagłówka, logo lockup albo specyficzny wzorzec nawigacji.

Kluczowe jest też nazewnictwo. Jeśli komponent odwołuje się do tokenów semantycznych, nie trzeba przebudowywać biblioteki przy dodaniu nowej marki. Podmieniasz zestaw tokenów marki, a komponent zachowuje się tak samo logicznie, tylko przyjmuje inny wygląd. To ogranicza liczbę bibliotek, upraszcza utrzymanie i zmniejsza ryzyko rozjazdu między markami.

Jeżeli jakaś marka wymaga odstępstw, warto stosować zasadę: wspólne domyślnie, osobne wyjątkowo. Duplikowanie całych bibliotek dla każdej marki szybko prowadzi do problemów z aktualizacjami, dokumentacją i spójnością. Lepiej utrzymywać jeden rdzeń komponentów oraz jasno wydzieloną warstwę wyjątków tam, gdzie wspólny model przestaje wystarczać.

Jak kontrolować spójność po zmianach tokenów i uniknąć „rozjazdów” w komponentach?

Spójność po zmianach tokenów utrzymuje się wtedy, gdy komponenty nie odwołują się do wartości „na sztywno”, tylko wyłącznie do właściwych aliasów i ról tokenów. Najczęstszy powód „rozjazdów” to mieszanie poziomów: część elementów korzysta z tokenów semantycznych, a część ma ręcznie wpisane kolory, odstępy lub promienie. W praktyce oznacza to, że po zmianie tokena globalnego jeden komponent aktualizuje się poprawnie, a inny zachowuje starą wartość.

Żeby temu zapobiec, trzeba pilnować jednej zasady: komponent bazowy powinien być przypięty do tokenów odpowiadających jego funkcji, a nie do przypadkowych wartości technicznych. Przykładowo, tło przycisku powinno być powiązane z tokenem roli typu „primary/background”, a nie bezpośrednio z konkretnym kolorem. Dzięki temu zmiana tokenów marki nie wymaga ręcznej korekty wariantów ani nadpisywania stylów w wielu miejscach.

Kontrola spójności wymaga też ograniczenia lokalnych wyjątków. Jeśli instancje komponentów mają dużo ręcznych override’ów, przestają reagować przewidywalnie na zmianę systemu tokenów. Dlatego po aktualizacjach warto sprawdzać przede wszystkim te miejsca, w których dopuszczono nadpisania właściwości wizualnych, użyto wartości lokalnych zamiast tokenów albo zbudowano komponent z warstw pochodzących z różnych, niespójnych bibliotek.

Dobra praktyka to wprowadzanie zmian warstwowo: najpierw aktualizacja tokenów bazowych, potem weryfikacja tokenów semantycznych, a dopiero na końcu kontrola komponentów i ich wariantów. Taka kolejność pozwala szybko ustalić, czy problem wynika z definicji tokena, mapowania aliasu, czy z samej konstrukcji komponentu. Jeśli wszystko jest podłączone poprawnie, komponent po zmianie tokenów nie powinien wymagać ręcznej naprawy.

Warto też traktować komponenty jako element testowy dla tokenów. Po każdej większej zmianie należy sprawdzić reprezentatywny zestaw: przyciski, pola formularzy, stany hover i disabled, typografię, spacing oraz elementy zagnieżdżone. Jeżeli rozjazdy pojawiają się tylko w części ekranów, zwykle oznacza to, że problem nie leży w tokenach, ale w niekonsekwentnym użyciu ich w plikach projektowych.

Najskuteczniejsza metoda to połączenie trzech rzeczy: ścisłego nazewnictwa tokenów, zakazu ręcznego wpisywania wartości w komponentach oraz regularnego przeglądu bibliotek po każdej zmianie. Wtedy zmiana tokena pozostaje zmianą systemową, a nie początkiem ręcznego poprawiania pojedynczych elementów.

Jak przygotować eksport tokenów do kodu i utrzymać zgodność między designem a produktem?

Podstawą jest traktowanie tokenów jako jednego źródła prawdy, z którego korzysta zarówno Figma, jak i kod. W praktyce oznacza to, że nazwy, struktura i typy tokenów muszą być ustalone tak, aby dało się je bezstratnie wyeksportować do formatu używanego w aplikacji, na przykład jako JSON, zmienne CSS, obiekty dla systemu komponentów albo pliki dla platform natywnych. Token nie powinien opisywać konkretnego elementu interfejsu, tylko znaczenie lub rolę, na przykład kolor tła powierzchni, kolor tekstu pomocniczego, odstęp czy promień zaokrąglenia.

Aby eksport był stabilny, warto rozdzielić tokeny na warstwy. Najniżej są wartości bazowe, takie jak konkretne kolory, skale odstępów czy typografia. Wyżej są tokeny semantyczne, które odwołują się do wartości bazowych i opisują zastosowanie w interfejsie. W środowisku wielomarkowym każda marka może mieć własne wartości bazowe, ale semantyka powinna pozostać wspólna. Dzięki temu komponent w kodzie odwołuje się do tego samego tokenu semantycznego niezależnie od marki, a zmienia się tylko przypisana wartość.

Kluczowe jest też spójne nazewnictwo. Nazwy muszą być jednoznaczne, przewidywalne i możliwe do wykorzystania po stronie kodu bez ręcznych wyjątków. Jeśli w Figma token nazywa się color.background.primary, to po eksporcie powinien dać się mapować do analogicznej struktury w repozytorium. Im mniej ręcznych transformacji między narzędziami, tym mniejsze ryzyko rozjazdu między projektem a produktem.

Zgodność utrzymuje się nie przez jednorazowy eksport, tylko przez proces. Zmiana tokenu powinna przechodzić przez kontrolowaną aktualizację: edycję w źródle, eksport do formatu dla deweloperów, walidację i publikację nowej wersji. W praktyce oznacza to wersjonowanie tokenów, tak aby zespół wiedział, która wersja obowiązuje w projekcie i która została wdrożona. Bez wersjonowania łatwo doprowadzić do sytuacji, w której Figma pokazuje już nowe wartości, a produkt działa jeszcze na starych.

Ważna jest również walidacja techniczna. Przed udostępnieniem tokenów do implementacji trzeba sprawdzić, czy wszystkie odwołania są poprawne, nie ma osieroconych aliasów, duplikatów nazw ani wartości nieobsługiwanych przez docelową platformę. Dotyczy to szczególnie kolorów z przezroczystością, jednostek odstępów, typografii i cieni, bo te atrybuty często wymagają jawnej konwersji między środowiskami projektowymi i developerskimi.

Żeby utrzymać zgodność z produktem, komponenty w kodzie powinny korzystać z tokenów bezpośrednio, a nie z wpisanych ręcznie wartości. Jeśli projektant zmienia token semantyczny, a komponent korzysta z niego jako zmiennej, aktualizacja jest przewidywalna i możliwa do prześledzenia. Jeśli natomiast wartości są kopiowane ręcznie do kodu, zgodność kończy się w momencie pierwszej zmiany.

Najważniejsza zasada jest prosta: eksport tokenów nie może być osobnym, ręcznym etapem „na koniec”, tylko częścią utrzymywanego systemu. Dopiero wtedy design i produkt pozostają zsynchronizowane nie tylko przy starcie, ale także przy kolejnych zmianach marek, motywów i komponentów.

Testy z Claude Code: jak przyspieszyć QA bez obniżania jakości 27 maja 2026

Claude Code w praktyce: jak AI zmienia tworzenie oprogramowania od zera do wdrożenia 25 maja 2026