Design system w Figmie: od tokenów po handoff do kodu

Tak, Figma nadaje się na design system, o ile zaczniesz od tokenów, zbudujesz komponenty z auto layout i ustalisz governance. Natywne Variables, biblioteki zespołowe i Library Analytics w zupełności wystarczą, by pracować w podejściu tokens‑first. Zacznij od tokenów, zbuduj główne komponenty, wyznacz właściciela biblioteki i włącz analitykę przed szeroką publikacją.

Krótko mówiąc:

• Pełny system projektowy opłaca się przy pracy kilku osób i wieloletnim rozwoju produktu; dla jednorazowej strony wystarczy lekka biblioteka stylów.
• Tokeny twórz przed komponentami, zaczynając od skal kolorów, odstępów i typografii; nowe dodawaj dopiero wtedy, gdy wartości się powtarzają.
• Buduj komponenty z układem automatycznym, projektuj od razu wszystkie stany i dopasuj nazwy warstw oraz właściwości do kodu.
• Przed publikacją wyznacz właściciela, sprawdź kontrast WCAG 2.1, skanuj ręcznie wpisane wartości, opisz zmiany i zaplanuj wycofanie komponentów.
• Figma Blog podaje, że projektanci z dostępem do systemu pracują średnio o 34% szybciej; Library Analytics pokazuje użycie komponentów.

Co Figma oferuje zespołom tworzącym design system

Figma pozycjonuje się jako źródło prawdy dla design systemów: komponenty, tokeny i dokumentacja leżą w jednym miejscu, a deweloperzy dostają specyfikacje w Dev Mode bez opuszczania pliku. Dla Ciebie oznacza to mniej pytań w stylu „która wersja przycisku jest aktualna“.

Najważniejsze elementy, na których oprzemy cały proces:

• biblioteki zespołowe: publikujesz style i komponenty raz, a projektanci używają ich we wszystkich plikach,
• Variables: przechowują tokeny i obsługują tryby, więc nie duplikujesz ramek,
• Library Analytics: pokazują, które komponenty faktycznie pracują, a które leżą nieużywane,
• Dev Mode i Code Connect: łączą projekt z repozytorium kodu.

Pełny design system ma sens, gdy nad produktem pracuje kilka osób i powstaje on przez lata. Przy jednorazowej stronie wizytówce wystarczy lekka biblioteka stylów, a rozbudowana struktura tylko by Cię spowalniała. Jeśli dopiero zaczynasz, zajrzyj najpierw do naszego praktycznego przewodnika po makietach w Figma.

Tokeny i Figma Variables: podejście tokens first

Figma Variables przechowują surowe wartości (kolory, liczby, ciągi tekstowe, wartości logiczne) i pozwalają je alias ować. Dzięki temu tokenem „kolor przycisku głównego“ wskazujesz na token bazowy, a zmiana jednej wartości przenosi się na cały system.

Zasady, które sprawdzają się u nas w praktyce:

• nazwy semantyczne w układzie kategoria/rola/wariant, np. color/action/primary,
• trzy poziomy: wartości bazowe, tokeny semantyczne, tokeny komponentów,
• kolekcje pogrupowane tematycznie (kolory, odstępy, typografia),
• format nazw zgodny z DTCG, żeby później łatwo wyeksportować tokeny do kodu.

Tokeny to fundament, więc pracę zaczynamy od nich, a dopiero potem rysujemy przyciski. Odwrócona kolejność kończy się komponentami z zaszytymi na sztywno wartościami, które trzeba poprawiać ręcznie.

Porada profesjonalisty: nie twórz tokenu dla każdej wartości, która pojawiła się w makiecie. Zacznij od skali kolorów, odstępów i typografii, a nowe tokeny dodawaj dopiero wtedy, gdy ta sama wartość powtarza się w projekcie.

Komponenty w Figmie: auto layout, warianty i nazewnictwo

Komponent bez auto layout łamie się przy pierwszej zmianie długości tekstu. Dlatego ustawiamy go jako warunek wstępny, a nie dodatek na końcu. Po stronie wariantów projektuj wszystkie stany naraz, bo dopisywanie brakujących później zwykle kończy się niespójnością.

Reguły, których się trzymamy:

• stany do zaprojektowania od razu: default, hover, disabled, error, loading,
• nazwy warstw i właściwości zgodne z nazwami w kodzie, co ułatwia późniejszy handoff,
• spójne nazewnictwo ze znakiem slash i krótki opis przy każdym komponencie,
• kontrolowane wydania z changelogiem zamiast cichych poprawek w tle.

Ostatni punkt ma znaczenie, bo tworzenie komponentów i ich utrzymanie to dwie różne umiejętności. Zmiana w bibliotece trafia do wszystkich plików, więc bez zapisu, co się zmieniło i dlaczego, zespół szybko traci zaufanie do systemu. Jeśli chcesz zobaczyć, jak te elementy współgrają w pełnym przykładzie, przejrzyj Simple Design System od Figmy, czyli otwarty wzorzec łączący Variables, style, komponenty i Code Connect z bazą kodu w Reaccie.

Tryby i theming: jak testować konteksty w jednej bibliotece

Tryby zmiennych pozwalają trzymać w jednym tokenie kilka wartości, np. dla jasnego i ciemnego motywu albo różnych rozmiarów urządzeń. Kolekcję z kilkoma trybami możesz zastosować do całej strony, pojedynczego komponentu lub grupy elementów.

Praktyczne zastosowania, które warto przetestować:

• tryb wysokiego kontrastu dla dostępności,
• zmienne tekstowe, dzięki którym sprawdzisz, jak interfejs znosi dłuższe etykiety,
• zmienne liczbowe dla odstępów na telefonie, tablecie i komputerze.

Najczęstszy problem to konflikt trybów: komponent dziedziczy tryb z ramki nadrzędnej i na ekranie pojawia się mieszanka jasnych i ciemnych elementów. Zapobiegasz temu, ustawiając domyślny tryb dla całej kolekcji i sprawdzając każdy komponent w każdym trybie jeszcze przed publikacją. Taka kontrola może ograniczyć liczbę poprawek po wydaniu.

Governance: właściciel, proces wydawania i audyty przed publikacją

Bez nazwanego właściciela i procesu wycofywania komponentów biblioteka zamienia się w cmentarzysko komponentów. Design system traktujemy jak produkt, który ma nie tylko rosnąć, lecz także się kurczyć, gdy elementy tracą sens.

Przed każdą publikacją przechodzimy tę samą listę:

1. Skan w poszukiwaniu wartości, które nie są tokenami (kolory i odstępy wpisane ręcznie).
2. Test kontrastu pod kątem WCAG 2.1, zgodnie z praktykami opisanymi przez Design Systems Collective.
3. Sprawdzenie, czy każdy komponent ma komplet stanów.
4. Wpis w changelogu i komunikat dla zespołów, które z biblioteki korzystają.
5. Plan wycofania dla komponentów, które zastępujemy nowymi.

Przy audycie dostępności pomoże nasz artykuł o audycie WCAG.

Porada profesjonalisty: wycofywanie komponentów ogłaszaj z wyprzedzeniem. Zespół, który odpowiednio wcześnie zobaczy ostrzeżenie, zdąży wymienić element bez presji.

Library Analytics: jak mierzyć adopcję i co z tego wynika

Bez pomiaru nie wiesz, czy system w ogóle jest używany. Library Analytics pokazują, które komponenty są „koniami roboczymi“, a które prawie nikt nie wstawia, więc wysiłek optymalizacyjny kierujesz tam, gdzie zwróci się najbardziej.

Metryki, które śledzimy:

• użycie biblioteki i poszczególnych komponentów,
• odsetek odłączonych instancji (detachment rate),
• zaangażowanie w dokumentację,
• wskaźniki spójności.

Dla większych zespołów warto zautomatyzować zbieranie danych. Pinterest opracował metrykę adopcji i narzędzie FigStats, które analizuje tylko aktywne pliki i strony przekazania, a sam pomiar opiera się na REST API Figmy.

Według Figma Blog, projektanci z dostępem do design systemu pracują średnio 34% szybciej. Dlatego tak ważne jest, by wiedzieć, czy ludzie faktycznie z systemu korzystają.

Wyniki zamieniaj na zadania: często odłączany komponent wymaga poprawki, a nieużywany to kandydat do wycofania.

Handoff do deweloperów: Code Connect i eksport tokenów

Code Connect mapuje komponenty z Figmy na fragmenty kodu. Tworzysz pliki szablonów .figma.ts lub .figma.tsx, publikujesz je przez CLI, a snippet pojawia się w Dev Mode obok komponentu.

Jak to ułożyć w praktyce:

• pliki Code Connect trzymaj w repozytorium razem z kodem i traktuj jak kod produkcyjny, z przeglądem zmian,
• tokeny eksportuj w formacie DTCG i konwertuj narzędziami (np. Tokens Studio) na zmienne CSS lub typy w TypeScripcie,
• nazwy komponentów i właściwości w Figmie utrzymuj zgodne z nazwami w kodzie,
• przed publikacją dodatkowo sprawdzaj plik lintem, np. figmalint, który wyłapuje błędy tokenizacji i dostępności.

Natywne narzędzia dają duży wgląd w kod, ale brakuje im lintingu na poziomie samego projektu, więc zewnętrzny audyt przed wydaniem nadal się opłaca.

Checklista startowa: pierwsze sprinty z design systemem

Nie musisz budować wszystkiego naraz. Proponujemy kilka kroków, które dają działającą bazę w kilka tygodni:

1. Sprint 0: inwentaryzacja istniejących ekranów i decyzja, że pracujecie tokens‑first.
2. Sprint 1–2: podstawowe tokeny i pięć głównych komponentów z auto layout, potem publikacja biblioteki.
3. Po dwóch tygodniach: audyt kontrastu, pierwsze metryki adopcji, wyznaczenie właściciela i rytmu wydań.

Porada profesjonalisty: wybierz na start najczęściej używane komponenty, takie jak przyciski, pola formularzy, karty, nagłówki i nawigacja. Szybko zobaczysz efekt, a zespół łatwiej przyjmie system, który od razu oszczędza mu czas.

Perspektywa autora: projekt i wdrożenie w jednych rękach

Design system przestaje być ładnym plikiem w Figmie dopiero wtedy, gdy trafia do kodu bez strat po drodze. Najwięcej rozjazdów widzę tam, gdzie projektant i deweloper nigdy nie rozmawiają o nazwach tokenów. Dlatego łączymy design, kod i SEO w jednym procesie. Przykłady takich wdrożeń znajdziesz w naszych realizacjach, a przy projekcie wdrożeniowym chętnie porozmawiamy.

— Marcin

Jak możemy pomóc w zaprojektowaniu i wdrożeniu design systemu

Projektujemy interfejsy w Figmie, wdrażamy frontend, budujemy CMS i podłączamy tokeny do pipeline’u kodu. Dzięki temu, że design, kod i SEO prowadzimy w jednym procesie, nie tracisz czasu na przekazywanie ustaleń między kilkoma wykonawcami. Zobacz naszą ofertę web design UI/UX i napisz, jaki produkt chcesz oprzeć na spójnym systemie, a omówimy pierwszy sprint.

Najczęściej zadawane pytania

Do czego służy Figma?

Figma to narzędzie do projektowania interfejsów, makiet i prototypów, w którym zespół pracuje wspólnie w jednym pliku. Z jej pomocą buduje się też biblioteki komponentów i całe design systemy.

Czym jest design system?

To zestaw tokenów, komponentów i zasad, który zapewnia spójność interfejsu w całym produkcie. Dzięki niemu zespół nie projektuje tych samych elementów od zera.

Jak zacząć tworzyć design system w Figmie?

Zacznij od tokenów w Variables, potem zbuduj kilka głównych komponentów z auto layout i opublikuj bibliotekę. Przed szerszym wdrożeniem ustal właściciela i włącz Library Analytics.

Jakie są przykłady design systemów?

Dobrym punktem wyjścia jest Simple Design System od Figmy, który pokazuje, jak Variables, komponenty i Code Connect współpracują z bazą kodu. Warto go przejrzeć, zanim zaprojektujesz własną strukturę.

Źródła

• Overview of variables, collections, and modes – Figma Learn - Help Center
• Figma Design System Guide 2026: Tokens, Governance & Scale — Hedrick
• Getting started with Code Connect CLI | Developer Docs

Rekomendacje

• Makiety w Figma: praktyczny przewodnik krok po kroku
• UI vs UX: jedna różnica, którą musisz zrozumieć od razu