TL;DR

Nauka kodowania przez designerów przyspiesza proces projektowy i poprawia komunikację z zespołami technicznymi
Token Studio powstało z frustracji brakiem możliwości używania design tokenów bezpośrednio w narzędziach designu
Wprowadzenie zmiennych przez Figma zmusiło Token Studio do przesunięcia fokusa na bardziej zaawansowane przypadki użycia
Wdrożenie to największe wyzwanie systemów designu – rozwiązanie techniczne to tylko połowa sukcesu
Różne poziomy tokenów wymagają przemyślanej hierarchii i nazewnictwa
Komunikacja między zespołami jest kluczowa dla skutecznego wdrożenia systemu designu
Podejście stopniowe pozwala zacząć od prostych elementów i stopniowo rozbudowywać system

Droga od agencji do GitHub

Jan Six rozpoczął karierę w agencjach, gdzie przez sześć lat pracował nad projektami print i digital design. Frustracja wynikająca z modelu „zrób i zapomnij” pchnęła go jednak w stronę product designu. Chciał pracować nad projektami, które mają wpływ na życie użytkowników i można je ciągle optymalizować.

Przełomowym momentem była praca w małym startupie, gdzie ograniczone zasoby zmusiły go do nauki programowania. Możliwość samodzielnego budowania projektów okazała się jedną z najlepszych decyzji rozwojowych. Six zauważa, że rozumienie możliwości technicznych pozwala designerom lepiej oceniać wykonalność swoich pomysłów.

Obecnie pracuje jako staff product designer w GitHub, skupiając się na pull requestach i Copilot. Jego doświadczenie z kodem pozwala mu płynnie przechodzić między projektowaniem w Figmie a implementacją w kodzie.

Genesis Token Studio – od frustracji do produktu

Pomysł na Token Studio narodził się z praktycznej potrzeby. Six pracował nad platformą SaaS wymagającą różnych motywów wizualnych dla różnych klientów. Podczas pracy z design tokenami w kodzie odkrył brak możliwości ich bezpośredniego użycia w narzędziach designu.

Wiedział, że może używać design tokenów w kodzie i istniały narzędzia transformacji do CSS variables, ale nie mógł używać ich w narzędziu designu. Pierwsza wtyczka była bardzo prosta – przyjmowała JSON z design tokenami i aplikowała je do projektów w Figmie.

Różnica między Token Studio a innymi projektami polegała na ciągłym napływie nowych pomysłów. Six nie czuł, że projekt jest skończony – zawsze widział kolejne możliwości rozwoju. Już kilka miesięcy po pierwszym wydaniu udostępnił projekt jako open source.

Współpraca z Mike’em rozpoczęła się, gdy Mike zgłaszał feature requesty. W rezultacie rosnąca liczba zgłoszeń i potrzeb społeczności zmusiła ich do sformalizowania zespołu.

Odpowiedź na zmienne Figmy

Wprowadzenie zmiennych przez Figma w 2023 roku mogło wydawać się zagrożeniem dla Token Studio. Six zauważa jednak, że wbudowane zmienne Figmy rozwiązały prostsze przypadki użycia – jak przełączanie między light i dark theme czy zarządzanie dwoma brandami.

Dlatego Token Studio ewoluowało w kierunku bardziej zaawansowanych potrzeb. Platforma skupia się teraz na maintainerach systemów designu, którzy potrzebują większej kontroli i funkcjonalności niż oferują natywne zmienne.

Rozwój obejmuje także pracę nad platformą niezależną od narzędzi. Six opisuje wizję pojedynczego formatu design tokenów, który napędza wszystkie decyzje designerskie we wszystkich narzędziach bez manualnego wysiłku.

Współpraca z PenPot, open source’owym narzędziem designu, to krok w kierunku tej wizji. Mimo to celem jest stworzenie mostów między różnymi narzędziami designu.

Systemy designu – definicja i komponenty

Według Six, dobry system designu to obejmowanie wszystkich decyzji zespołowych dotyczących spójności produktu. Obejmuje to paletę kolorów, typografię, bibliotekę komponentów oraz wzorce i reguły.

Kluczową zaletą jest eliminacja zgadywania. Gdy system jest dobrze zaprojektowany, product designerzy i inżynierowie nie muszą zastanawiać się nad wyborem odpowiednich wartości.

Design tokeny działają podobnie do CSS variables – definiujesz wartości zmiennych i przypisujesz je do właściwości jak color czy background. Możesz tworzyć zagnieżdżone referencje, gdzie jedna zmienna odnosi się do drugiej, budując system bardziej odporny na błędy.

Six używa metafory dobrze zaprojektowanych klocków Lego – komponenty w systemie designu pozwalają inżynierom budować funkcjonalności przez składanie gotowych elementów, co znacząco przyspiesza cykl rozwoju produktu.

Design tokeny stanowią atomowe decyzje systemu. Six wyróżnia różne poziomy:

Core tokens – podstawowe wartości jak „red-500” na skali 100-900
Semantic tokens – nazwy funkcjonalne jak „foreground-default” czy „background-default”
Component tokens – specyficzne dla komponentów jak „button-primary-background”

Six zaleca rozpoczęcie od tokenów semantycznych, które są prostsze w implementacji niż głęboko zagnieżdżone hierarchie komponentów.

Rekomendowane źródła wiedzy:

Six wskazuje na artykuły ekspertów branży jako źródło głębszej wiedzy:

Nathan Curtis – „Naming Design Tokens” (kilka lat stary, ale wciąż aktualny)
Brad Frost – „Multidimensional Theming” (wyjaśnia dlaczego potrzebujemy spójnych wzorców nazewnictwa)

Dwie perspektywy: konsument vs. maintainer

Unikalna pozycja Six – jednocześnie konsument systemów w GitHub i twórca narzędzi dla maintainerów – daje mu wszechstronną perspektywę.

Jako konsument GitHub Primer (systemu designu GitHub), Six ceni przede wszystkim szybkość, efektywność i ograniczoną liczbę wyborów. Musi skupić się na rozwijaniu pomysłów, nie na systemizacji.

Najważniejszą cechą dobrego systemu jest zaufanie. Six podkreśla: Mogę ufać, że dopóki wybieram odpowiednie kolory z systemu, nie spotkam niespodzianek przy przełączaniu na dark mode czy high contrast. GitHub ma kilka trybów kolorystycznych – dark, dark high contrast i high contrast – ale system niezawodnie działa we wszystkich.

Zaufanie do systemu eliminuje zgadywanie – kluczowa korzyść, którą Six docenia zarówno jako konsument, jak i twórca narzędzi dla maintainerów.

Ta perspektywa konsumenta wpływa na rozwój Token Studio. Six podkreśla znaczenie myślenia o end-to-end użytkownikach, nie tylko o bezpośrednich użytkownikach narzędzia.

Role organizacyjne w systemach designu

Six obserwuje pojawianie się nowych ról zawodowych związanych z systemami designu:

Design system architect – nadzorowanie logiki całego systemu
Content design specialist – tworzenie dokumentacji i stron z wytycznymi
Token specialist – dedykowana osoba do budowania logiki design tokenów
Technical liaison – zapewnienie użyteczności systemu dla inżynierów

Strona techniczna pozostaje kluczowa – systemy muszą być użyteczne nie tylko dla designerów, ale równie mocno dla inżynierów. Adopcja w całej firmie to podstawa sukcesu.

Wdrożenie – największe wyzwanie

Według Six, wdrożenie to najważniejszy element sukcesu systemu designu. System, którego używa tylko część zespołów, traci znaczną część swojej efektywności.

Problem powstaje, gdy różne zespoły mają różne potrzeby, a system nie uwzględnia wszystkich wymagań. W konsekwencji zespoły, które nie mogą korzystać z systemu, pozostają z własnymi rozwiązaniami.

Six wyjaśnia: Jeśli możesz sprawić, że cała firma będzie mogła używać twojego systemu designu, każda mała zmiana ma ogromny wpływ na efektywność.

Komunikacja między zespołami przed definiowaniem systemu jest kluczowa. Różne zespoły mogą mieć różne wymagania, które należy poznać i uwzględnić.

Praktyczne kroki wdrożenia

Six zaleca podejście stopniowe dla firm rozpoczynających pracę z systemami designu. Pierwszy krok to audyt istniejących rozwiązań – ile różnych implementacji przycisków ma zespół?

Rozmowy z zespołem o czasie spędzanym na wybieraniu odpowiednich komponentów wobec korzystaniu z predefiniowanych elementów pokazują potencjalne oszczędności.

Lista kontrolna implementacji systemu designu:

Audyt obecnego stanu – policz różne wersje przycisków, kolorów, fontów
Zdefiniuj paletę kolorów – ogranicz opcje wyboru
Ustal typografię i spacing – określ podstawowe wartości
Udostępnij tokeny zespołowi – z odpowiednią dokumentacją
Wprowadź automatyzację – zsynchronizuj design z kodem
Monitoruj wdrożenie – sprawdzaj czy wszystkie zespoły korzystają z systemu

Six podkreśla znaczenie dokumentacji: Wiele zespołów zapomina o właściwej dokumentacji i po prostu udostępnia CSS variables.

Dokumentacja i narzędzia

Dobra dokumentacja powinna być łatwo odkrywalna dla zespołu. Six wskazuje na GitHub Primer docs jako przykład wyczerpującej dokumentacji, zastrzegając że nie każdy zespół potrzebuje tak zaawansowanego rozwiązania.

Dla mniejszych systemów wystarczy zespołowa wiki, jeśli jest to miejsce, gdzie zespół naturalnie szuka informacji. Kluczowe jest myślenie o konsumencie i sposobie, w jaki będzie chciał się do dokumentacji dostać.

Automatyzacja procesów między designem a kodem to następny krok. Token Studio oferuje takie możliwości przez plugin Figma i platformę, która może służyć jako single source of truth dla zespołu – centralne miejsce zarządzania wszystkimi decyzjami designerskimi.

Przyszłość Token Studio

Wizja Six wykracza poza Figma. Celem jest stworzenie platformy niezależnej od narzędzi, która będzie mostkiem między różnymi aplikacjami designerskimi.

Współpraca z PenPot to krok w kierunku implementacji natywnej integracji design tokenów w narzędziu open source. Długoterminowa wizja obejmuje rozszerzenie na narzędzia jak Sketch, Framer, InDesign czy Illustrator.

Six opisuje: Chcemy oferować funkcjonalność jak w wtyczce Figma także dla innych narzędzi, aby ukończyć wizję pojedynczego formatu design tokenów.

Studio platform jest obecnie dostępna na liście oczekujących dla zespołów wszystkich rozmiarów. Six można znaleźć na tokens.studio oraz na Bluesky pod nickiem @yan6.

Kluczowe spostrzeżenie

Mniej wyborów = lepsza adopcja

Standardowo myślimy: Dobry system designu to ten, który oferuje designerom więcej opcji i elastyczności – różne warianty buttonów, szeroki zakres kolorów, multiple spacing options.

W praktyce okazuje się, że: Najlepsze systemy designu celowo ograniczają wybory. Six podkreśla, że ceni systemy, które nie zmuszają go do zastanawiania się nad szczegółami, bo musi skupić się na pomysłach, nie na systemizacji.

Dlaczego to jest istotne: Gdy designerzy mają za dużo opcji, tracą czas na podejmowanie decyzji zamiast rozwiązywać problemy użytkowników. Paradoksalnie, ograniczenie wyborów przyspiesza proces projektowy i zwiększa spójność produktu.

Test na jutro: Następnym razem gdy definiujesz system designu, zamiast dodawać kolejne warianty komponentów spróbuj usunąć połowę istniejących opcji i sprawdź czy zespół projektuje szybciej.

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: UI Breakfast Podcast – Episode 292: Using Tokens in Design Systems with Jan Six

Tag: Design System Architect

Design tokeny w praktyce – jak Token Studio ewoluuje razem z branżą #EN151