Poniższe notatki powstały na podstawie masterclassu o konfiguracji zmiennych Figma, prowadzonego przez Kirka McNeilla z UI Collective – eksperta z wieloletnim doświadczeniem w budowaniu systemów projektowych dla klientów enterprise. Wszystkie przedstawione przemyślenia, obserwacje i wnioski pochodzą od prowadzącego.
TL;DR
- Wybierz odpowiednią architekturę: 3-warstwowa (brand-alias-mapped) dla enterprise, 2-warstwowa (primitive-semantic) dla prostszych projektów
- Buduj skale kolorów matematycznie: używaj 20% opacity na białym/czarnym tle dla spójnej progresji
- Najpierw komponenty, potem skala: zbuduj design system przed utworzeniem skali numerycznej
- Organizuj zmienne logicznie: tekst i ikony powinny używać tych samych kolorów dla spójności
- Oddziel light mode od dark mode: finalizuj accessibility w light mode przed implementacją dark mode
- Użyj „jumper variables”: definiuj jak odstępy zmieniają się między urządzeniami
- Testuj na rzeczywistych projektach: skala powinna odpowiadać faktycznym potrzebom designowym
Najważniejsze insights z masterclassu:
- Różne kolory mogą mieć różne zakresy skal (nie wszystko musi być 100-950)
- Font weights muszą dokładnie odpowiadać nazwom w Figmie
- Text primary ≠ text default (primary to dla linków i elementów interaktywnych)
- Dark mode = odwrócenie wszystkich wartości naraz, nie po kolei
- Mapped collection zawiera TYLKO kolory, reszta zostaje w alias
Dlaczego profesjonalna konfiguracja zmiennych ma znaczenie
Prowadzący masterclass, który zbudował ponad 50 systemów projektowych dla klientów enterprise i prawdopodobnie ponad 100 tysięcy komponentów, identyfikuje główny problem jako błędne podejścia innych twórców. Jak sam przyznaje, pracuje nad komponentami nawet o 23:00 wieczorem, w swoje urodziny czy w Boże Narodzenie.
Ekspert zauważa istotny problem: „Ostatnio widzę wielu ludzi biorących to, czego uczę, i dodających własne modyfikacje, jednak pomijają kluczowe części i wprowadzają ludzi w błąd.”
Jego wiedzę zdobył od współzałożyciela UI Collective – Mike’a, który prowadzi firmę budującą enterprise design systemy, a wcześniej był design executive zarządzającym zespołem 60-70 designerów.
Prawidłowa konfiguracja zmiennych stanowi fundament skalowalnego design systemu. Bez solidnych podstaw każda kolejna warstwa będzie niestabilna.
Dwa podejścia do organizacji zmiennych
Metoda 2-warstwowa (primitive + semantic)
Ekspert wyjaśnia, że popularne systemy jak Untitled UI wykorzystują to podejście. Figma również promuje tę metodę w swoich tutorialach. Składa się z primitive collection (surowe wartości) oraz semantic collection (kolory z przypisanymi rolami).
Metoda 3-warstwowa (brand + alias + mapped) – zalecana dla enterprise
Prowadzący preferuje to podejście dla klientów enterprise ze względu na lepszą skalowalność dla multi-brand systemów oraz czystszą organizację różnych brandów w alias collection.
Błędny mit innych twórców: Ekspert podkreśla, że słyszy od wielu kreatorów, iż 2-warstwowe podejście jest absolutnie nie do przyjęcia. Tymczasem oba podejścia mają swoje zastosowanie. Jeśli używasz 2-warstwowego podejścia, nie musisz przebudowywać całego systemu – nadal działa i pokrywa podstawową funkcjonalność.
Brand Collection – fundament systemu
Brand collection zawiera wszystko w najczystszej formie. Ekspert porównuje ją do „odwróconego trójkąta”, gdzie górna część zawiera absolutnie wszystko.
Budowanie skal kolorów metodą 100-scale
Prowadzący zdecydowanie odradza podejście typu „red lightest, red lighter, red light” ze względu na brak skalowalności. Zamiast tego zaleca system 100-scale: Red 100, 200, 300, 400, 500, 600, 700, 800, 900, 950 z możliwością dodawania wartości pośrednich (np. red 150 między 100 a 200) oraz matematyczną spójnością progresji.
Prawidłowe tworzenie gradacji
Ekspert szczegółowo opisuje proces tworzenia skal:
Dla jaśniejszych odcieni:
- Użyj kolorów z opacity na białym tle
- Dla odcieni 500→100: opacity 80%, 60%, 40%, 20%
- Color match każdy odcień dla uzyskania hex code
Dla ciemniejszych odcieni:
- Te same kolory z opacity na czarnym tle
- Zachowaj matematyczną spójność
Prowadzący ostrzega przed błędną radą z YouTube, gdzie niektórzy twórcy sugerują używanie ciemniejszego odcienia szarości zamiast czarnego. Jeśli jaśniejsze kolory bazują na białym, przeciwieństwem muszą być kolory bazujące na czarnym. W przeciwnym razie matematyka skal będzie błędna.
Fonty i skala numeryczna
Ważny mit do obalenia: Ekspert często słyszy od twórców, że każdy kolor musi mieć dokładnie tę samą logikę skal. To absolutnie nieprawda. Różne kolory i kombinacje kolorów mają różną dostępność w zależności od parowania. Dlatego możesz potrzebować wprowadzić wartości 1000 lub inne dla accessibility.
W brand collection należy umieścić font family (np. Inter) jako string variable oraz font weights odpowiadające dokładnie nazwom w Figmie (np. „Semi Bold” z spacją dla Inter, „SemiBold” bez spacji dla Roboto).
Kluczowa rada eksperta: Skala to bardzo zaawansowany temat design systemów. Nie poleca budowania skali jako pierwszej rzeczy. To bardzo trudne – wielkości komponentów, gap między większymi komponentami, wysokości i szerokości jeśli są fixed. Idealnie powinno się zbudować fonty, komponenty, moduły, żeby zorientować się jakich odstępów potrzebujesz.
Prowadzący podkreśla wagę spójnej skali numerycznej opartej na wielokrotnościach 4, z jedynym wyjątkiem wartości 1 (dla 1px border). Dla większych wartości można przeskakiwać (np. z 40 do 48, potem 56).
Kluczowy punkt o nazewnictwie: Wielu designerów twierdzi, że skala może nazywać się po prostu według wartości – 96 zamiast 1200. Jednak gdy ta wartość musi się zmienić z 96 na 100, można zmienić wartość, ale nazwa zostanie ta sama więc kod się nie zepsuje. Jeśli jednak zaczniemy zmieniać nazwy zmiennych, kod się zepsuje.
Alias Collection – przypisywanie ról kolorom
Alias collection to miejsce, gdzie surowe skale z brand collection otrzymują konkretne role semantyczne.
Przekształcanie skal w role
Ekspert wyjaśnia na przykładzie Coca-Coli – primary scale (czerwony kolor marki) oraz error scale (też czerwony dla formularzy) wykorzystują tę samą skalę z brand collection, jednak mają różne role.
Korzyści tego podejścia:
- Konsekwencja: komponenty używają właściwych ról semantycznych
- Skalowalność: łatwa zmiana kolorów bez modyfikacji komponentów
- Zarządzanie brandami: różne marki w jednym systemie
- Maintenance: centralna kontrola nad zmianami kolorów
Kiedy budujesz komponenty, chcesz używać kolorów error, nie primary. W ten sposób utrzymujesz spójność w całym systemie.
Zarządzanie wieloma brandami
Dla podobnych brandów (jak Coke vs Diet Coke) wystarczy zduplikować grupę primary, zmienić połączenie ze skalą red na gray, a wszystkie inne właściwości pozostają identyczne.
Branded House vs House of Brands – kluczowe rozróżnienie według McNeilla:
- Branded House (np. Coca-Cola, Diet Coke, Coke Zero) – podobne marki o zbliżonej filozofii designu, różniące się głównie kolorami primary/secondary, można zarządzać w jednej alias collection
- House of Brands (np. Coca-Cola, Fanta, Sprite) – całkowicie różne marki z odrębnymi kolorami, typografią i filozofiami designu – potrzebują osobnych collections dla każdej marki
Duży błąd designerów to próba wpasowania brandów które mają całkowicie różne skale kolorów w alias collection. W takich przypadkach komponenty mogą być całkowicie różne w sposobie aplikowania kolorów.
Mapped Collection – kolory dla komponentów
Mapped collection zawiera wyłącznie kolory stosowane w komponentach. McNeill jasno stwierdza, że border radius i border width zostają w alias collection, ponieważ promień zaokrąglenia rzadko zmienia się między trybem jasnym a ciemnym, jednak często różni się między markami.
Organizacja kolorów tekstu
Text default to podstawowe kolory tekstów (body, heading, caption, placeholder) połączone z neutral scale. Text on-color to te same hierarchie, ale dla tekstu na kolorowym tle – połączone z foundations white dla kontrastu.
Ekspert tłumaczy różnicę: wielu designerów myli to z przełączaniem dark mode. Tymczasem w projektach masz elementy light i dark jednocześnie.
Text primary vs text default
Kluczowe rozróżnienie według eksperta: Text default to standardowe kolory tekstów, Text primary to kolory dla elementów interaktywnych jak linki.
Praktyczny przykład: Link „Learn more” wykorzystuje text primary default, a po hover text primary hover.
Surface, border i focus states
Prowadzący zaleca duplikowanie logiki między tekstem a innymi elementami – Surface primary default/hover (te same wartości co text), Border primary default/hover (często identyczne z surface), Icon primary default/hover (identyczne z text dla spójności).
Dlaczego surfaces nie potrzebują on-color: Powierzchnie generalnie nie wchodzą w grę przy sprawdzaniu accessibility. To zazwyczaj tylko tekst i ikony potrzebują tego on-color żeby uzyskać właściwy poziom WCAG AA color contrast.
Dlaczego ikony nie mają hierarchii: Ikony nie mają heading, body, caption, placeholder – po prostu nie mają tej roli. Dlatego można usunąć defaults i on-color grouping, ale te role nadal się przydadzą.
Ikony i tekst powinny mieć identyczne kolory. Jeśli ikona ma inny hover niż tekst, użytkownicy nie będą wiedzieć, co się dzieje.
Dla elementów interaktywnych należy dodać border focus variables (zazwyczaj ta sama wartość co default) z 2px border na wszystkich stronach elementu.
T-shirt sizing dla border widths: Zamiast używać 100-scale, ekspert pokazuje alternatywę: extra small (1px), small (2px), medium (4px), large (8px).
Dlaczego border może być identyczny z surface: Często pojawia się pytanie – jeśli są identyczne, po co je potrzebować? Odpowiedź to zawsze skalowalność. Co jeśli są tym samym kolorem teraz, ale standardy marki zmienią się delikatnie?
Light mode vs Dark mode
Kluczowa rada eksperta: Największy błąd designerów to przeskakiwanie do dark mode bez finalizacji light mode pod kątem accessibility.
Dlaczego nie można testować komponentów po kolei: Problem polega na tym, że jeśli testujesz komponent w dark mode, nie działa i robisz zmiany w tym kolorze żeby działał w dark mode pod kątem accessibility, to może spowodować że inny komponent przestanie działać w dark mode. Musisz balansować między light mode a dark mode i ciągle przełączać się między trybami zmieniając zmienne.
Proces implementacji dark mode:
- Nie testuj komponentów po kolei – zmień wszystkie zmienne naraz
- Odwróć wartości – najciemniejszy kolor w light mode = najjaśniejszy w dark mode
- Idź tak szybko: Kiedy budujesz dark mode, powinieneś iść tak szybko. Nie powinieneś nawet o tym myśleć, bo masz odwrócić je najpierw, zobaczyć z czym masz do czynienia, a potem robić zmiany.
- Dopiero potem drobne korekty
Responsive Collection – projektowanie dla różnych urządzeń
Responsive collection zapewnia, że wszystkie projekty są responsywne. Gdy przełączasz z desktop na mobile frame, elementy z fill będą responsywne, jednak parent width karty będzie potrzebował zdefiniowanej wartości szerokości.
Frame widths dla różnych urządzeń: Desktop (1440px), tablet (1024px), mobile (440px). Ekspert zauważa, że w jednej agencji zawsze robili projekty w 1920×1080 z różnych powodów.
Hierarchia typograficzna z Type Scale
Prowadzący zaleca narzędzie Type Scale do tworzenia spójnych hierarchii z base font size zawsze na 16px – cokolwiek poniżej 16 pikseli, zaczynasz mieć więcej problemów z accessibility.
Proces z Type Scale:
- Major Third scale jako dobry punkt startowy
- Problem: narzędzie pokazuje wartości dziesiętne (np. 25.888px)
- Rozwiązanie: zaokrąglanie do wielokrotności 4
- Błędne podejście innych: Wielu twórców mówi – wybierz dowolną liczbę w okolicy tej wartości, 39 dla H3, 49 zamiast 48. Problem w tym że nie następuje naturalny grid.
Line height i paragraph spacing: text size × 1.2 (lub 1.4) zaokrąglone do wielokrotności 4. Line height może być preferential, ma mniejszy wpływ. Paragraph spacing można dostosować, ale dla line height zdecydowanie sugeruje ten multiplier.
„Jumper variables” dla responsive odstępów
Koncepcja autorska: zmienne definiujące jak odstępy zmieniają się między urządzeniami.
Praktyczne przykłady z realnych projektów (na podstawie analizy Untitled UI):
- Konsekwentne użycie 64px, 96px, 32px w różnych kombinacjach
spacing/xl-to-medium: 96px na desktop → 64px na mobilespacing/2xl-to-small: 128px na desktop → 32px na mobilespacing/large-to-medium: 64px na desktop → 64px na mobile (bez zmiany)
Kluczowa obserwacja: Jeśli mam mnóstwo różnych elementów z odstępami, posiadanie kombinacji dla każdego to za dużo. Jednak dlatego ważne jest zbudowanie projektów najpierw – możesz nie potrzebować każdej możliwej kombinacji.
Najważniejsze błędy do uniknięcia
Kluczowe błędy według eksperta:
- Budowanie skali przed komponentami – będziesz próbować wciskać brand identity w skalę, zamiast na odwrót
- Niespójność w wielokrotnościach (mieszanie 3, 4, 7, 8)
- Przeskakiwanie do dark mode bez finalizacji light mode
- Założenie że wszystkie kolory muszą mieć identyczne zakresy skal
- Różne wartości kolorów dla tekstu i ikon w tym samym kontekście
Podsumowanie
Ekspert, który zbudował ponad 50 systemów projektowych, podkreśla znaczenie systematycznego podejścia. Kluczem do sukcesu nie jest idealna konfiguracja od początku, ale zrozumienie potrzeb projektowych przed abstrakcją.
Lista kontrolna – kolejność implementacji:
- ✓ Zbuduj kilka kluczowych komponentów i układów
- ✓ Określ potrzebne kolory, odstępy i typography
- ✓ Stwórz brand collection z matematycznymi skalami
- ✓ Zorganizuj alias collection z rolami semantycznymi
- ✓ Skonfiguruj mapped collection tylko z kolorami
- ✓ Przetestuj accessibility w light mode
- ✓ Zaimplementuj dark mode przez odwrócenie wartości
- ✓ Dodaj responsive collection z „jumper variables”
Kluczowy insight
Paradoks skali liczbowej
Standardowo myślimy: Zaczynamy od stworzenia idealnej skali numerycznej (4, 8, 12, 16, 20…), a potem dopasowujemy do niej komponenty i odstępy.
W praktyce okazuje się, że: Musisz najpierw zbudować kluczowe komponenty i układy, żeby odkryć jakich wartości rzeczywiście potrzebujesz, a skalę stworzyć na samym końcu.
Dlaczego to jest istotne: Jak ostrzega McNeill – jeśli zbudujesz skalę pierwszą, będziesz próbować wciskać brand identity w skalę, zamiast na odwrót. W rezultacie komponenty wyglądają sztucznie, bo są ograniczone przez arbitralną matematykę zamiast rzeczywiste potrzeby projektu.
Test na jutro: Następnym razem gdy zaczniesz system projektowy, zamiast od razu tworzyć skalę odstępów, spróbuj najpierw zaprojektować 3-5 kluczowych komponentów (karty, buttony, formularze) i sprawdź jakie wartości odstępów rzeczywiście wykorzystujesz.
Szybka lista weryfikacji
Zanim opublikujesz swój system zmiennych, sprawdź czy:
- ✓ Używasz trójwarstwowej struktury (Brand, Alias, Mapped) dla złożonych projektów
- ✓ Twoje skale kolorów i liczb mają nazwy generyczne (np. blue-100, scale-500), nie opisowe
- ✓ Masz zdefiniowane zmienne on-color dla zapewnienia kontrastu na kolorowych tłach
- ✓ Finalizujesz tryb jasny i accessibility przed implementacją trybu ciemnego
- ✓ Twój model brandowy (Alias z trybami vs. osobne kolekcje) odpowiada relacjom między markami
Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Design System & Figma Variable Set Up – Full Tutorial
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.