Design system w Figma bez chaosu: tokeny, style, zmienne i governance w 12 zasadach

1. Wprowadzenie: czym jest design system w Figma i skąd bierze się „chaos”

Design system w Figma to spójny zestaw reguł i zasobów, który pomaga projektować interfejsy szybciej i bardziej konsekwentnie. W praktyce obejmuje zarówno to, co projektujemy (np. elementy UI), jak i jak to robimy (np. wspólne decyzje o kolorach, typografii, odstępach oraz sposobie wprowadzania zmian). Figma jest tu narzędziem, w którym te decyzje są materializowane w postaci wspólnych bibliotek i ustawień używanych przez zespół.

Warto odróżnić design system od kilku pojęć, które często się mieszają:

• UI kit to zestaw gotowych elementów do użycia, ale niekoniecznie z jasnymi zasadami utrzymania i rozwoju.
• Biblioteka komponentów w Figma to współdzielone komponenty i style; jest częścią design systemu, ale nie wyczerpuje tematu.
• Guidelines to opis zasad (np. w dokumentacji), jednak bez spójnego odzwierciedlenia w zasobach Figma szybko stają się „martwe”.

„Chaos” w design systemie w Figma zwykle nie bierze się z braku narzędzi, tylko z braku jednej, wspólnej logiki zarządzania decyzjami projektowymi. Pojawia się wtedy, gdy zespół rośnie, projektów przybywa, a elementy zaczynają żyć własnym życiem: podobne komponenty występują w wielu wersjach, style są tworzone ad hoc, a zmiany w jednym miejscu nie propagują się przewidywalnie do reszty.

Najczęstsze źródła „chaosu” to:

• Niespójne źródła prawdy: część decyzji jest w stylach, część w lokalnych ustawieniach plików, część w ręcznych obejściach, a część „w głowach” osób w zespole.
• Mieszanie warstw abstrakcji: w jednym miejscu zapisujemy wartości „surowe” (np. konkretny kolor), a w innym już znaczenie (np. kolor dla akcji) — i te poziomy zaczynają się dublować lub przecinać.
• Nadmiar wariantów i duplikatów: zamiast klarownych reguł, powstają kolejne „prawie takie same” komponenty, bo tak było szybciej w danym projekcie.
• Brak kontroli zmian: aktualizacje biblioteki są publikowane bez ustalonych kryteriów, przez co użytkownicy biblioteki tracą zaufanie do stabilności systemu.
• Niejednoznaczne nazewnictwo: gdy nazwy nie mówią, czy coś jest decyzją globalną, kontekstową czy jednorazową, zasoby trudno znaleźć i trudno ich używać konsekwentnie.

Kluczowe jest przyjęcie prostego założenia: design system w Figma ma minimalizować liczbę decyzji podejmowanych „na bieżąco” podczas projektowania, a maksymalizować liczbę decyzji podejmowanych raz i używanych wielokrotnie. Do tego potrzebne są mechanizmy, które Figma oferuje (np. style, zmienne, komponenty i biblioteki), ale przede wszystkim potrzebna jest spójna metoda ich użycia. Bez niej nawet najlepsze funkcje narzędzia przyspieszają… produkcję kolejnych wyjątków.

12 zasad budowy design systemu bez chaosu (tokeny, styles vs variables, komponenty, warianty)

Chaos w design systemie w Figma zwykle nie bierze się z braku komponentów, tylko z braku reguł: co jest decyzją projektową, gdzie to zapisujemy, jak to nazywamy i kto może to zmieniać. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj. Poniższe zasady porządkują cztery obszary, które najczęściej „rozjeżdżają” system: tokeny, style i zmienne, komponenty oraz warianty.

• 1) Zdefiniuj, czym jest „decyzja projektowa” i zapisuj ją tylko raz.
  Jeśli coś ma wpływ na spójność UI (kolor, odstęp, promień, typografia, cień), traktuj to jako decyzję systemową i przechowuj w jednym źródle prawdy. Unikniesz sytuacji, w której ten sam efekt istnieje w kilku miejscach (np. styl, lokalny kolor i jeszcze override w komponencie).

• 2) Oddziel tokeny (znaczenie) od wartości (implementacja).
  Token opisuje rolę („tekst podstawowy”, „tło surface”), a nie konkretną liczbę czy kod koloru. Wartość może się zmieniać (np. w rebrandingu), a rola pozostaje. Dzięki temu system jest odporny na zmiany i łatwiejszy do skalowania.

• 3) Z góry zdecyduj: kiedy używasz Styles, a kiedy Variables.
  Styles są wygodne do nadawania spójnego wyglądu i szybkiego stosowania (np. style tekstu). Variables są lepsze, gdy potrzebujesz kontekstu i przełączania (np. tryb jasny/ciemny, motywy, brandy, stany, platformy). Chaos pojawia się, gdy ten sam atrybut jest raz stylem, raz zmienną bez jasnej reguły.

• 4) Ustal jedną ścieżkę „token → użycie”.
  Każde użycie w UI (tekst, tło, obramowanie) powinno wskazywać na systemowy byt: styl albo zmienną (lub styl oparty o zmienną). Unikaj „lokalnych wyjątków” na poziomie warstwy, bo z czasem stają się ukrytym fork-iem design systemu.

• 5) Projektuj tokeny semantycznie, nie paletowo.
  Paleta (np. odcienie niebieskiego) jest materiałem wejściowym. System powinien operować na rolach (np. „primary”, „on-primary”, „border-subtle”). Paletę zostaw do kontroli i mapowania, a semantykę wykorzystuj w komponentach i makietach.

• 6) Ustal minimalny zestaw „dozwolonych wartości” dla odstępów i rozmiarów.
  Najwięcej bałaganu powstaje w spacingu: dziesiątki niemal identycznych odstępów, trudnych do odtworzenia i utrzymania. Ograniczony zestaw kroków (np. skala) upraszcza projektowanie, review i późniejsze wdrożenie.

• 7) Traktuj komponenty jak API: mają być przewidywalne i stabilne.
  Komponent nie jest „ładnym kawałkiem UI”, tylko interfejsem, z którego korzystają inni. Ma jasno określone parametry (warianty, właściwości), stabilne zachowanie w auto-layout i minimalną liczbę zaskoczeń przy podmianie treści.

• 8) Warianty służą do kontrolowanych różnic, nie do katalogowania wszystkiego.
  Warianty opisują sensowne osie zmienności (np. rozmiar, stan, typ). Jeśli tworzysz warianty dla każdej drobnej różnicy wizualnej, biblioteka puchnie, a użytkownicy zaczynają duplikować komponenty zamiast wybierać właściwe ustawienie.

• 9) Nazwij osie wariantów tak, by odpowiadały decyzjom, a nie wyglądowi.
  Dobre nazwy to takie, które mówią „po co” (np. „state”, „intent”, „density”), a nie „jak to wygląda” (np. „nieco jaśniejszy”). Ułatwia to komunikację i ogranicza dyskusje o drobnych odcieniach w miejscach, gdzie liczy się znaczenie.

• 10) Preferuj składanie komponentów nad duplikowaniem.
  Jeśli ten sam element występuje w wielu miejscach (np. ikona, label, badge), nie kopiuj jego definicji do kolejnych komponentów w formie „wbudowanej na stałe”. Składanie (komponent w komponencie) ogranicza rozjazdy i przyspiesza aktualizacje.

• 11) Ogranicz liczbę miejsc, w których można „nadpisać” wygląd.
  Im więcej dowolności (swobodne kolory, ręczne odstępy, niekontrolowane text styles), tym szybciej system traci spójność. Dobra praktyka to projektowanie komponentów tak, by większość potrzeb pokrywały właściwości i warianty, a nie ręczne poprawki na instancji.

• 12) Ustal zasady ewolucji: kiedy dodajesz, kiedy łączysz, a kiedy usuwasz.
  Bez reguł rozwoju system rośnie w sposób przypadkowy: dochodzą kolejne tokeny, style i komponenty o podobnym znaczeniu. Prosta polityka: dodawaj tylko gdy istniejący element nie spełnia roli, łącz gdy są duplikaty semantyczne, usuwaj (lub deprecjonuj), gdy element jest nieużywany lub zastąpiony.

Te zasady nie wymagają od razu perfekcyjnej biblioteki. Wymagają konsekwencji: jedna definicja decyzji projektowej, jasny podział odpowiedzialności między tokenami, stylami i zmiennymi oraz komponenty budowane jak przewidywalne narzędzia, a nie kolekcja wyjątków.

3. Tokeny w praktyce: struktura, naming, przykładowa konwencja (kolory, typografia, spacing)

Tokeny to najmniejsze, nazwane „klocki” decyzji projektowych: kolor, rozmiar tekstu, odstęp, promień zaokrąglenia, cień. W Figma najczęściej materializują się jako Variables (zmienne) oraz częściowo jako Styles (style). Tokeny są po to, by zamiast „pamiętać wartości” (np. #111827, 16 px, 24 px) używać nazw o znaczeniu i spójnych reguł mapowania.

3.1. Po co tokeny: jedna decyzja, wiele zastosowań

• Skalowanie: zmiana jednego tokena (np. spacing) aktualizuje wiele miejsc.
• Spójność: te same decyzje w UI i w komponentach, bez „prawie takich samych” wartości.
• Wielość trybów: tokeny wspierają różne konteksty (np. light/dark, high contrast) bez ręcznej podmiany.
• Most między design a dev: tokeny są językiem wymiany – łatwiej je zmapować na implementację.

3.2. Tokeny a Style i Variables: kiedy co ma sens

Kluczowa zasada: tokeny opisują decyzję (np. „tekst podstawowy”), a nie tylko wartość (np. 14 px). Dzięki temu w razie zmiany skali lub motywu nie musisz przemodelowywać całego systemu.

3.3. Struktura tokenów: od „surowych” do „semantycznych”

Najczęściej spotkasz dwa poziomy (czasem trzy):

• Foundation / Base – surowe wartości, bez kontekstu użycia (np. skala szarości, kroki spacing).
• Semantic – znaczenie w UI (np. tło powierzchni, tekst drugorzędny, obramowanie).
• Component (opcjonalnie) – tokeny specyficzne dla komponentu (np. padding przycisku), jeśli rzeczywiście potrzebujesz niezależnej kontroli.

W praktyce: base zmienia się rzadko, semantic częściej (np. w dark mode), a component tylko, gdy komponent ma uzasadnioną autonomię.

3.4. Naming: proste reguły, które redukują chaos

Dobre nazewnictwo tokenów powinno być: jednoznaczne, czytelne i przewidywalne. Trzy praktyczne reguły:

• Używaj hierarchii: kategorie oddzielaj „/” (czytelne w pickerach w Figma).
• Opisuj rolę, nie kolor (na poziomie semantic): „text/primary”, nie „text/gray-900”.
• Stosuj stałe słownictwo: te same słowa dla tych samych pojęć (primary/secondary, bg/text/border).

3.5. Przykładowa konwencja: kolory

Base (foundation) – skale kolorów, bez znaczenia UI:

• color/base/gray/50…900
• color/base/blue/50…900
• color/base/red/50…900

Semantic – role w interfejsie:

• color/text/primary, color/text/secondary, color/text/inverse
• color/bg/canvas, color/bg/surface, color/bg/elevated
• color/border/default, color/border/subtle
• color/feedback/success, color/feedback/warning, color/feedback/danger
• color/action/primary, color/action/primary-hover (jeśli rozdzielasz stany)

Jeśli wspierasz tryby (np. light/dark), ten sam token semantyczny (color/text/primary) dostaje inną wartość w zależności od mode.

3.6. Przykładowa konwencja: typografia

W typografii łatwo wpaść w pułapkę „zbyt wielu stylów”. Tokenizacja pomaga rozdzielić parametry (base) od ról (semantic).

Base (pojedyncze właściwości lub zestawy, zależnie od podejścia):

• type/font/family/sans, type/font/family/mono
• type/size/12…48
• type/line/16…56
• type/weight/regular, type/weight/medium, type/weight/bold

Semantic (role w UI, które mapujesz do Text Styles i/lub zmiennych):

• type/text/body, type/text/body-strong
• type/text/caption
• type/heading/h1, type/heading/h2, type/heading/h3
• type/ui/button, type/ui/label

W praktyce projektowej często najwygodniej jest mieć Text Styles nazwane semantycznie (np. type/text/body), a ich parametry (rozmiar, wysokość linii, grubość) wynikały z ustalonej skali.

3.7. Przykładowa konwencja: spacing

Spacing tokenizuje się wyjątkowo dobrze, bo reguły są proste i łatwe do egzekwowania.

Base (skala odstępów):

• space/0, space/2, space/4, space/8, space/12, space/16, space/24, space/32, space/40, space/48

Semantic (opcjonalnie, gdy chcesz opisać intencję):

• space/layout/gutter
• space/layout/section
• space/component/padding

Jeśli dopiero porządkujesz system, zacznij od samej skali space/… i pilnuj jej użycia. Semantykę dodawaj dopiero, gdy widzisz powtarzalne wzorce i realną potrzebę sterowania nimi niezależnie.

3.8. Minimalny przykład mapowania (dla spójności)

Poniżej skrótowy przykład pokazujący ideę mapowania: semantyka wskazuje na bazę. To nie jest „implementacja”, tylko sposób myślenia o zależnościach.

// base
color/base/gray/900 = #111827
color/base/gray/50  = #F9FAFB

// semantic
color/text/primary  = {color/base/gray/900}
color/bg/surface    = {color/base/gray/50}

// spacing
space/16 = 16
space/component/padding = {space/16}

Najważniejsze: konsekwentna struktura (base → semantic) i nazwy, które mówią „po co”, a nie „z czego”. To wystarcza, by tokeny stały się stabilnym fundamentem dla stylów i komponentów, zamiast kolejną warstwą chaosu.

4. Komponenty i biblioteki: architektura, warianty, składanie, ograniczanie duplikatów

Komponenty w Figma to „nośniki decyzji” — zamykają w sobie wygląd, zachowanie i ograniczenia użycia. Biblioteka (library) porządkuje je, ułatwia dystrybucję i aktualizacje w wielu plikach. Chaos bierze się najczęściej nie z braku komponentów, ale z nadmiaru podobnych, niejasnych zasad wariantów i kopiowania elementów zamiast ich reużycia.

Architektura komponentów: warstwy, nie katalogi

Najstabilniejsze systemy buduje się warstwowo: od najmniejszych elementów po gotowe wzorce UI. Taka architektura ogranicza duplikaty, bo każdy poziom ma jasną rolę.

• Primitives / atoms – ikony, podstawowe kształty, typowe „części” (np. handle, dot, divider). Zwykle bez logiki produktu.
• Controls – interaktywne elementy UI: button, input, checkbox, toggle. To tu pojawia się większość wariantów (stan, rozmiar, typ).
• Composites – składanki z kontrolkami: search field z ikoną, input z helperem, toolbar, pagination.
• Patterns – większe układy: header, modal layout, empty state, list item. Dają szybkość, ale łatwo je „przekompować”.
• Templates / screens (opcjonalnie) – rzadziej w bibliotece, częściej jako przykłady użycia; zbyt wysoki poziom zwiększa ryzyko konfliktów i wariantów specyficznych dla funkcji.

Zasada: jeśli jakiś element często „pęka” przy użyciu w różnych miejscach, to znak, że powinien być niżej (bardziej atomowy) albo mieć lepiej zaprojektowane warianty.

Biblioteka w praktyce: co trzymać w library, a co w pliku produktu

Biblioteka powinna przechowywać to, co ma być stabilne i powtarzalne. Wszystko, co jest jeszcze płynne lub silnie zależne od kontekstu, lepiej utrzymać lokalnie — inaczej system zaczyna „puchnąć” od wyjątków.

Warianty: mniej, ale mądrzej

Warianty są najczęstszą przyczyną rozrostu komponentów. Dobra praktyka to projektowanie wariantów jako osi (properties), które dają realną wartość i są wspólne dla wielu użyć.

• Co zwykle ma sens jako wariant: rozmiar (sm/md/lg), typ (primary/secondary/tertiary), stan (default/hover/pressed/disabled), ikona (none/leading/trailing), gęstość (compact/comfortable).
• Co często nie powinno być wariantem: tekst (label), długość, konkretny kolor „na potrzeby ekranu”, mikroukład zależny od treści, „specjalna wersja dla strony X”.

Heurystyka: jeśli właściwość wariantu ma więcej niż 5–6 wartości i nie wynika z zasad systemu, rozważ przeniesienie jej do treści (np. tekst) albo do składania z mniejszych elementów.

Składanie (composition): buduj z klocków, nie z duplikatów

Zamiast tworzyć osobne komponenty dla każdej kombinacji, warto składać UI z kilku przewidywalnych elementów:

• Sloty – miejsca na opcjonalne elementy (ikona, badge, akcja po prawej). Sloty zmniejszają liczbę wariantów.
• Auto Layout – zapewnia odporność na różne długości treści i zmiany spacingu bez klonowania komponentów.
• Nested components – kontrolka składa się z mniejszych komponentów (np. button zawiera label + opcjonalną ikonę jako osobny komponent).
• Component properties (np. boolean/instance swap) – pozwalają włączać/wyłączać części i podmieniać instancje bez mnożenia wariantów.

Składanie jest najtańszą drogą do skali: zamiast utrzymywać 30 odmian „kafla”, utrzymujesz 1 kafel z czytelnymi slotami i kilkoma osiami wariantów. Doświadczenie Cognity pokazuje, że uporządkowanie wariantów i composition przynosi szybkie i zauważalne efekty w codziennej pracy — zwłaszcza gdy zespół wcześniej walczył z „bliźniakami” komponentów.

Ograniczanie duplikatów: sygnały ostrzegawcze i proste reguły

Duplikaty rzadko powstają „złośliwie”. Zwykle wynikają z braku widoczności, niejednoznacznych nazw lub zbyt trudnego komponentu do użycia. Poniżej zestaw praktyk, które redukują to ryzyko.

• Jedna rzecz = jeden komponent: jeśli coś ma tę samą rolę UI, nie twórz alternatyw tylko dlatego, że różni się detalem. Detal rozwiąż wariantem, slotem albo tokenem/stylami.
• Odróżniaj „podobne” od „różne”: dwa przyciski mogą wyglądać podobnie, ale jeśli mają różne zasady (np. inna semantyka i stany), to lepiej dwa komponenty niż jeden „kombajn”.
• Nie klonuj z canvasu: użycie powinno zaczynać się od Assets / wyszukiwania komponentu, nie od kopiuj-wklej z ekranu.
• Ustal miejsce prawdy: komponent ma jeden „master” w bibliotece. Lokalna modyfikacja instancji powinna być wyjątkiem, nie normą.
• Przeglądaj „bliźniaki”: regularnie szukaj komponentów o podobnych nazwach lub wyglądzie i scalaj je, zanim rozrost stanie się nieodwracalny.

Nazewnictwo i odkrywalność: architektura informacji w Assets

Nawet najlepszy komponent będzie duplikowany, jeśli nie da się go łatwo znaleźć. Dlatego nazwy i grupowanie to część architektury systemu.

• Używaj hierarchii „Kategoria / Komponent” (np. Controls/Button, Forms/Text field, Navigation/Tab) zamiast przypadkowych nazw.
• Nazywaj zgodnie z rolą, nie wyglądem (np. „Button” zamiast „Blue CTA”).
• Unikaj skrótów nieoczywistych — spowalniają wyszukiwanie i zwiększają liczbę „prawie takich samych” komponentów.

Kiedy tworzyć nowy komponent, a kiedy rozszerzyć istniejący

• Dodaj wariant, gdy różnica jest przewidywalna, powtarzalna i wynika z zasad (np. rozmiar, stan, typ).
• Dodaj slot / property, gdy różnica dotyczy opcjonalnego elementu (ikona, badge, akcja) albo podmiany części.
• Stwórz nowy komponent, gdy zmienia się semantyka i zasady użycia (np. „Button” vs „Icon button” z inną powierzchnią klikalną i stanami).
• Zostaw lokalnie, gdy to jednorazowy przypadek lub eksperyment — system nie powinien przechowywać prototypowych wyjątków.

// Minimalna „checklista” przed dodaniem komponentu do biblioteki
// 1) Czy element będzie użyty w >= 2 miejscach?
// 2) Czy ma jasno zdefiniowaną rolę i zasady użycia?
// 3) Czy da się go znaleźć po nazwie i kategorii?
// 4) Czy warianty są osiami (nie listą wyjątków)?
// 5) Czy da się go składać (sloty) zamiast mnożyć odmiany?

Cel biblioteki komponentów to nie „mieć wszystko”, tylko zmniejszyć koszt spójności: łatwo wdrażać, łatwo używać, łatwo zmieniać. Architektura warstwowa, umiarkowane warianty i składanie z klocków to najkrótsza droga do systemu, który rośnie bez chaosu.

5. Dokumentacja i wdrożenie w zespole: zasady użycia, onboarding, przykłady i anti-patterny

Nawet najlepiej zbudowana biblioteka w Figma zaczyna żyć własnym życiem, jeśli zespół nie ma jasnych zasad: co wolno używać, jak tego używać i gdzie szukać odpowiedzi. „Chaos” zwykle nie wynika ze złej woli, tylko z braku wspólnego kontekstu: nowe osoby kopiują komponenty zamiast wstawiać instancje, ktoś „na szybko” robi lokalny styl, a po miesiącu nikt nie pamięta dlaczego. Dokumentacja i proces wdrożenia mają ten koszt obniżyć: skrócić czas decyzji, ograniczyć duplikaty i ujednolicić wynik.

5.1. Co dokumentować, żeby to działało (minimum skuteczne)

Dokumentacja design systemu w Figma powinna odpowiadać na pytania użytkownika biblioteki, a nie opisywać jej „od środka”. Dobre minimum to:

• Jak zacząć: gdzie jest biblioteka, jak ją podpiąć, jak wstawiać komponenty i jak publikować zmiany (dla osób z uprawnieniami).
• Zasady użycia: kiedy używać komponentu vs kiedy tworzyć nowy; co jest „dozwolone” w override’ach; czego nie ruszać.
• Przykłady: szybkie, wizualne „do/don’t” dla najczęstszych elementów (np. przyciski, pola, alerty, nagłówki sekcji).
• Anti-patterny: typowe błędy i ich konsekwencje (np. odłączone instancje, lokalne style, ręczne kolory).
• FAQ / decyzje: krótka lista ustaleń, które zwykle wracają (np. „czy wolno zmieniać padding w komponencie?”).

5.2. Zasady użycia: proste reguły, które ograniczają rozjazdy

Zasady powinny być krótkie, testowalne i łatwe do egzekwowania podczas review. Poniżej zestaw, który zwykle daje największy efekt:

• Zawsze używaj instancji z biblioteki, a nie kopii (kopie są niewidoczne dla update’ów).
• Nie odłączaj instancji („Detach”) bez powodu. Jeśli musisz, dodaj komentarz dlaczego i rozważ zgłoszenie braku do systemu.
• Override tylko w granicach: zmieniaj wyłącznie to, co system przewiduje (np. tekst, ikona, stan), a nie „architekturę” komponentu.
• Nie twórz lokalnych stylów/zmiennych do elementów, które mają odpowiedniki w systemie. To najszybsza droga do duplikatów.
• Nie wpisuj wartości „z ręki” (kolor, odstęp, rozmiar), jeśli istnieje token/style/zmienna. Wartość ręczna nie skaluje się przy zmianach.
• Używaj komponentów layoutowych (np. kontenerów, sekcji) jeśli są dostępne, zamiast odtwarzać układ z prostokątów.

5.3. Onboarding: jak wprowadzić nowych bez mnożenia wyjątków

Onboarding powinien minimalizować liczbę rzeczy do zapamiętania na start. Najlepiej działa podejście „20 minut do pierwszego poprawnego ekranu”. Skuteczny schemat:

• 1) Start pack: link do biblioteki, link do pliku z dokumentacją, jedna strona „Getting started”.
• 2) Zasady w 10 punktach: skrót tego, co wolno/nie wolno (np. instancje zamiast kopii, brak lokalnych stylów).
• 3) Przykładowy ekran referencyjny: jeden ekran z poprawnie użytymi komponentami (do podejrzenia struktury warstw i właściwości).
• 4) Zadanie kontrolne: odtworzenie małego widoku (np. formularz + CTA) z użyciem biblioteki — z krótkim review.
• 5) Kanał pytań: jedno miejsce na zgłoszenia braków i wątpliwości (żeby nie powstawały „lokalne obejścia”).

5.4. Przykłady: „do/don’t” jako najszybsza dokumentacja

Najłatwiejszą do utrzymania formą dokumentacji są przykłady wprost w Figma: obok komponentu pokazujesz poprawne zastosowanie i najczęstsze błędy. To skraca dyskusje, bo decyzja jest wizualna. Poniżej przykłady formatów, które zwykle działają:

• Do/Don’t dla przycisku: kiedy używać primary/secondary/tertiary, kiedy disabled, jak z ikoną.
• Do/Don’t dla spacingu: poprawne użycie siatki/odstępów systemowych vs „dopychanie” ręczne.
• Wzorce treści: przykład krótkich labeli, długości tytułów, zachowania przy przepełnieniu (truncation/wrapping) — bez wchodzenia w szczegółowe reguły typografii.

5.5. Anti-patterny, które najczęściej produkują chaos

Poniższe błędy są częste, bo pozornie „przyspieszają” pracę, ale po kilku sprintach podnoszą koszt utrzymania. Warto je spisać i konsekwentnie wyłapywać w review:

5.6. Review pracy w plikach produktu: lekka kontrola jakości

Review nie musi być ciężkim procesem. Wystarczy krótka lista kontrolna, którą da się przejść w kilka minut przed handoffem lub publikacją widoku do deva:

• Czy użyto instancji komponentów z biblioteki (bez kopii)?
• Czy nie ma odłączonych instancji bez uzasadnienia?
• Czy użyto systemowych wartości dla kolorów/typografii/odstępów (bez „manualnych” wpisów)?
• Czy stany (hover/disabled/error) są spójne i wynikają z komponentów, a nie z ręcznych zmian?
• Czy nietypowy przypadek jest opisany komentarzem i/lub zgłoszony do systemu?

5.7. Handoff do developmentu: co ma być czytelne bez domysłów

Wdrożenie systemu w zespole kończy się dopiero wtedy, gdy projekt jest czytelny dla osób implementujących. Bez wchodzenia w szczegóły tokenów i architektury, podstawy są proste:

• Nazywaj sekcje i komponenty tak, aby dało się je wyszukać i odnieść do biblioteki.
• Unikaj „warstw śmieci”: ukryte prostokąty, zduplikowane ramki, nieużywane style.
• Utrzymuj spójne stany na widoku (np. formularz w error state powinien używać tych samych komponentów i stanów co reszta).
• Pokazuj zachowanie tam, gdzie to potrzebne: przykładowo warianty dla różnych długości treści lub breakpointów (w formie prostych przykładów).

Najważniejsze: dokumentacja ma zmniejszać liczbę pytań i zwiększać przewidywalność. Jeśli zespół po tygodniu nadal „robi po swojemu”, to zwykle nie problem narzędzia, tylko brak jasnych zasad, przykładów i lekkiego review.

6. Governance: ownership, proces zmian, review, kontrola wersji i release notes

Design system bez governance szybko zamienia się w zbiór „czyichś” komponentów i stylów, które każdy modyfikuje po swojemu. Governance to zestaw ról, zasad i rytuałów, które określają: kto może zmieniać system, jak te zmiany przechodzą przez weryfikację oraz jak są komunikowane i wdrażane w produktach. Celem nie jest biurokracja, tylko przewidywalność: mniej regresji, mniej duplikatów i szybsze decyzje.

Ownership: kto jest właścicielem czego

Najczęstszy błąd to brak rozdzielenia odpowiedzialności między „bibliotekę” a „użytkowanie”. Ustal minimalny model ownership już na starcie.

• Owner systemu (produktowy) – ustala priorytety rozwoju systemu, pilnuje spójności z roadmapą produktów.
• Maintainerzy (design) – odpowiadają za jakość komponentów, wariantów, tokenów/zmiennych i dokumentację zmian.
• Maintainerzy (dev) – dbają o zgodność implementacji (np. tokeny w kodzie), wpływ zmian na front oraz kompatybilność wsteczną.
• Reviewerzy (cross-functional) – reprezentują zespoły produktowe; weryfikują wpływ zmian na użycie w realnych ekranach.
• Konsumenci – zgłaszają potrzeby i problemy, ale nie „przepychają” zmian bez procesu.

Praktyczna zasada: kto utrzymuje standard, ten zatwierdza zmiany standardu. Pozostałe osoby mogą proponować, prototypować i zgłaszać wnioski.

Model dostępu i uprawnień w Figma

Governance zaczyna się od ograniczenia miejsc, gdzie powstaje prawda o systemie. W Figma najczęściej oznacza to:

• Jedno źródło prawdy dla biblioteki (publikowane biblioteki), zamiast wielu podobnych plików „tymczasowych”.
• Uprawnienia edycji tylko dla maintainerów; reszta zespołu korzysta z biblioteki jako konsumenci.
• Wyraźna separacja: plik do budowy systemu vs pliki produktowe (żeby „poprawki na szybko” nie trafiały do biblioteki).

Proces zmian: od zgłoszenia do publikacji

Najlepszy proces jest krótki, ale konsekwentny. Kluczowe jest rozróżnienie, czy zmiana jest naprawą, rozszerzeniem, czy breaking change.

• Intake – zgłoszenie potrzeby (problem, brakujący komponent, niespójność). Minimalnie: cel, kontekst użycia, zrzuty, wpływ na UI.
• Triaging – ocena: pilność, zakres, czy to już istnieje, czy da się rozwiązać przez właściwe użycie zamiast nowego bytu.
• Proposal – propozycja rozwiązania (warianty, konsekwencje, ograniczenia). W tym miejscu decyduje się też, czy zmiana wymaga migracji.
• Implementation – przygotowanie w bibliotece (komponenty/tokenu/zmienne). Unikaj „cichych” zmian bez śladu w historii.
• Review – weryfikacja jakości, dostępności, spójności, wpływu na istniejące ekrany.
• Publish – publikacja biblioteki i komunikacja zmiany.
• Adoption – wsparcie we wdrożeniu: instrukcja migracji, oznaczenie deprecated, monitorowanie problemów.

Review: co sprawdzać, żeby nie generować długu

Review powinno być powtarzalne i oparte o checklistę, a nie „kto jak czuje”. Minimalny zakres:

• Spójność semantyczna – czy nazwy oddają rolę (a nie wygląd), czy nie duplikują istniejących bytów.
• Kompatybilność wsteczna – czy dotychczasowe użycia nie „rozjadą się” po publikacji.
• Wpływ na skalowanie – czy zmiana nie wymusza lawiny nowych wariantów / wyjątków.
• Dostępność – kontrast, stany interakcji, czytelność typografii (na poziomie zasad, nie audytu każdego ekranu).
• Gotowość do adopcji – czy jest krótki opis zmiany i wskazówka „kiedy używać / kiedy nie”.

Kontrola wersji: jak wersjonować design system w Figma

Wersjonowanie porządkuje komunikację. Nawet jeśli Figma nie wymusza semver, warto mieć konwencję wersji biblioteki i traktować publikacje jako releasy.

Dobry nawyk: nie publikuj majorów „w piątek” i nie łącz ich z drobnymi poprawkami — utrudnia to adopcję i diagnozę problemów.

Deprecation i okna przejściowe

Usuwanie elementów bez okresu przejściowego to najprostsza droga do chaosu w plikach produktowych. Zamiast tego:

• Oznaczaj deprecację (np. w nazwie lub opisie komponentu) i podaj zamiennik.
• Ustal okno przejściowe (np. 1–2 cykle sprintów lub konkretna data).
• Nie zmieniaj znaczenia w ciszy – jeśli komponent ma inną rolę, to zwykle powinien być nowym bytem.

Release notes: minimum, które realnie pomaga

Release notes są mostem między biblioteką a zespołami produktowymi. Muszą odpowiadać na pytania: co się zmieniło, kogo to dotyczy i co trzeba zrobić. Forma może być prosta, ale stała.

• Wersja i data
• Added – nowe elementy i kiedy ich używać
• Changed – zmiany zachowania/wyglądu, wpływ na istniejące projekty
• Fixed – poprawki bez wpływu na API systemu
• Deprecated – co znika i jaki jest zamiennik
• Migration notes – konkretne kroki, jeśli wymagane

Design System v1.8.0 (2026-03-19)
Added:
- Badge: nowe warianty statusów (info/success/warning/error)
Changed:
- Button: ujednolicone stany focus (bez zmian w wymiarach)
Deprecated:
- Tag/Legacy (zastąp przez Badge)
Migration:
- W nowych ekranach używaj Badge; stare Tag/Legacy migruj do końca kwartału

Rytuały i kanały komunikacji

Nawet najlepszy proces nie zadziała bez regularności. Minimalny zestaw rytuałów:

• Stały slot na triage (np. raz w tygodniu) – krótkie decyzje: akcept / odrzuć / doprecyzuj.
• Release cadence – przewidywalna częstotliwość publikacji (np. co 2 tygodnie), żeby zespoły wiedziały, kiedy spodziewać się zmian.
• Jedno miejsce prawdy dla zmian (np. strona w pliku systemu lub dedykowany dokument) – bez rozproszenia po wątkach.
• Office hours – krótki dyżur maintainerów na pytania o użycie i planowane zmiany.

Mierniki, które sygnalizują chaos (i warto je monitorować)

• Wzrost duplikatów podobnych komponentów / wariantów
• Niska adopcja nowych elementów mimo publikacji (sygnał: brak komunikacji lub zbyt trudna migracja)
• Częste regresje po publikacji (sygnał: brak checklisty review albo zbyt szerokie zmiany naraz)
• „Hotfixy” w produktach zamiast zmian w bibliotece (sygnał: brak zaufania do procesu lub zbyt wolne releasy)

7. Przykładowa struktura plików w Figma (workspace, pliki, strony) + checklisty: audyt istniejącego systemu

Najwięcej „chaosu” w design systemie w Figma nie bierze się z braku komponentów, tylko z braku czytelnej struktury: gdzie co jest, co jest źródłem prawdy, co jest tylko przykładem, a co jest już przestarzałe. Dobra struktura workspace’u i plików pozwala szybciej znaleźć właściwy element, ogranicza duplikaty oraz ułatwia kontrolę zmian.

Workspace: jak poukładać zespoły i projekty

Na poziomie workspace’u celem jest oddzielenie rzeczy stabilnych (biblioteki) od rzeczy zmiennych (projekty produktowe). Najczęstszy i najbardziej praktyczny podział to:

• Obszar „Design System”: miejsce na pliki-biblioteki, dokumentację oraz materiały do utrzymania standardów.
• Obszary produktowe (projekty): pliki robocze zespołów, funkcji i inicjatyw, które konsumują bibliotekę.
• Sandbox / Playground: przestrzeń do testów, eksperymentów i szybkich proof-of-conceptów bez ryzyka „zabrudzenia” biblioteki.

Kluczowe jest, aby biblioteki były publikowane z jednego, jasno wskazanego miejsca, a projekty produktowe miały minimalną liczbę własnych „lokalnych systemów”.

Pliki: minimalny zestaw bez rozdrabniania na siłę

W Figma łatwo przesadzić w dwie strony: trzymać wszystko w jednym pliku (trudno zarządzać) albo rozbić na kilkanaście plików (trudno zrozumieć). Bazowy zestaw, który sprawdza się w większości organizacji:

• 00 — Foundations: definicje bazowe używane wszędzie (np. kolory, typografia, spacing) oraz ich uporządkowana prezentacja.
• 01 — Components: komponenty wielokrotnego użytku (od prostych po złożone) przygotowane do użycia w projektach.
• 02 — Patterns (opcjonalnie): powtarzalne układy i rozwiązania, które nie zawsze są pojedynczym komponentem (np. wzorce formularzy, nawigacji, pustych stanów).
• 03 — Guidelines & Documentation: zasady użycia, przykłady, krótkie „jak używać”, decyzje i konwencje.
• 99 — Archive: miejsce na wycofane elementy, snapshoty i rzeczy „tylko do wglądu”, poza bieżącym obiegiem.

Jeśli zespół jest mały, często wystarczą dwa pliki: Foundations i Components, a dokumentację trzyma się na dedykowanych stronach w jednym z nich. Z kolei w dużych organizacjach lepsze bywa wydzielenie dokumentacji, żeby nie mieszać jej z biblioteką publikowaną do użycia.

Strony w pliku: konsekwencja ważniejsza niż perfekcja

Strony są „menu” pliku. Dobrze działają, gdy odzwierciedlają sposób myślenia użytkowników biblioteki: gdzie znajdę to, czego potrzebuję? Przykładowy układ stron w pliku Components:

• Start / Read me: do czego służy plik, jak go używać, co jest źródłem prawdy.
• Core: najbardziej podstawowe komponenty (przyciski, inputy, ikonografia jako elementy UI).
• Navigation: komponenty nawigacyjne.
• Data display: elementy prezentacji danych.
• Overlays: elementy warstwowe (np. dialogi, dropdowny).
• Forms: zestaw elementów formularzy i ich typowe konfiguracje.
• Examples: przykłady użycia i gotowe kompozycje demonstracyjne (nie jako źródło prawdy).
• WIP / Staging: elementy w przygotowaniu, niepublikowane lub publikowane warunkowo.

Najważniejsza zasada: źródło prawdy (to, co ma być używane) powinno być odseparowane od przykładów i WIP. Dzięki temu użytkownicy biblioteki rzadziej „kopiują coś z makiety” zamiast korzystać z właściwego komponentu.

Nazewnictwo i sygnały porządku (bez wchodzenia w detale)

Nawet prosta struktura zacznie się sypać, jeśli brakuje sygnałów, co jest aktualne i wspierane. Wystarczą lekkie konwencje:

• Numery porządkowe w nazwach plików: łatwiejsze sortowanie i nawigacja.
• Jednoznaczne etykiety stron: „Examples”, „WIP”, „Archive” zamiast kreatywnych nazw.
• Wyraźne odróżnienie elementów przeznaczonych do publikacji od szkiców.
• Ograniczona liczba miejsc, w których „wolno” tworzyć nowe elementy systemu.

Checklisty: audyt istniejącego design systemu w Figma

Poniższe listy pomagają szybko ocenić, czy system jest używalny i skalowalny. To audyt nastawiony na porządek i wykrycie źródeł chaosu, a nie na szczegółową poprawność każdego elementu.

A. Audyt workspace’u i dostępu

• Czy istnieje jedno, łatwe do wskazania miejsce „Design System” (oddzielone od projektów produktowych)?
• Czy pliki biblioteczne są jednoznacznie rozpoznawalne po nazwie i kolejności?
• Czy jest przestrzeń typu Sandbox, w której można testować bez wpływu na bibliotekę?
• Czy uprawnienia do edycji bibliotek są ograniczone do osób odpowiedzialnych, a reszta zespołu ma komfort użycia?
• Czy nowe osoby wiedzą, gdzie zacząć (czy jest „Start / Read me”)?

B. Audyt plików: liczba, podział i odpowiedzialność

• Czy wiadomo, które pliki są źródłem prawdy, a które są tylko projektami?
• Czy nie ma duplikatów bibliotek o podobnym zakresie (np. „Components v2”, „UI Kit new”, „Library final”)?
• Czy podział na pliki nie jest przypadkowy (np. osobny plik na każdy komponent bez potrzeby)?
• Czy istnieje jasno wydzielone miejsce na archiwum i rzeczy wycofane?
• Czy da się wskazać właściciela/odpowiedzialność za każdy plik biblioteczny?

C. Audyt stron: nawigacja i ryzyko „kopiuj-wklej”

• Czy w każdym pliku jest strona startowa z krótką instrukcją użycia?
• Czy strony są nazwane konsekwentnie i przewidywalnie (bez skrótów zrozumiałych tylko dla autora)?
• Czy elementy do użycia są oddzielone od „Examples”, „WIP” i „Archive”?
• Czy użytkownik biblioteki może znaleźć komponent w mniej niż minutę?
• Czy przykłady nie podszywają się pod źródło prawdy (np. wyglądają jak „właściwe komponenty”)?

D. Audyt spójności wizualnej i porządku w bibliotece

• Czy widać powtarzające się elementy, które powinny być jednym komponentem, a są wieloma wariantami „na dziko”?
• Czy podobne komponenty mają podobną strukturę (łatwe do porównania i utrzymania)?
• Czy w bibliotece nie ma elementów jednorazowych (zrobionych pod konkretny ekran)?
• Czy widać miejsca, gdzie zespół omija bibliotekę, bo „szybciej zrobić od zera”?

E. Audyt publikowania i użycia w projektach

• Czy biblioteka jest faktycznie używana w plikach produktowych (a nie tylko istnieje)?
• Czy zespoły nie tworzą lokalnych zamienników komponentów, bo nie ufają bibliotece?
• Czy w projektach produktowych nie ma podpinanych „starych” bibliotek równolegle z nowymi?
• Czy elementy z biblioteki są używane jako instancje, a nie kopiowane i odpinane?
• Czy jest jasne, które elementy są wspierane, a które „legacy”?

F. Szybkie sygnały, że system wchodzi w chaos

• Wiele plików o podobnych nazwach i niejasnym statusie („final”, „new”, „v2”, „do not use”).
• Brak strony startowej i brak „jednego miejsca prawdy”.
• Mieszanie dokumentacji, eksperymentów i komponentów produkcyjnych na tych samych stronach.
• Regularne kopiowanie elementów z ekranu zamiast użycia biblioteki.
• Trudność w odpowiedzi na proste pytanie: „skąd mam wziąć właściwy przycisk?”

Dobrze zaprojektowana struktura workspace’u, plików i stron działa jak mapa: ogranicza przypadkowość, zmniejsza liczbę „równoległych prawd” i sprawia, że design system jest łatwy do użycia bez dodatkowych wyjaśnień.

Na zakończenie – w Cognity wierzymy, że wiedza najlepiej działa wtedy, gdy jest osadzona w codziennej pracy. Dlatego szkolimy praktycznie.

Wykresy dla danych z długim ogonem: skala logarytmiczna, winsoryzacja i alternatywy 15 kwietnia 2026

Kolory w wizualizacji danych: palety przyjazne daltonistom i standardy firmowe 2026 13 kwietnia 2026