Notatki z odcinka Sneak Peek z udziałem Corneliusa, lead product designera w firmie Jump. Wszystkie obserwacje, wnioski i przykłady pochodzą od rozmówców. Checklista i kluczowy insight stanowią interpretację na podstawie treści rozmowy.

TL;DR

Jump to platforma ticketingowa i aplikacyjna dla drużyn sportowych, wymagająca jednego systemu projektowania obsługującego 50+ różnych marek.
Tryby Figmy pełnią tu funkcję silnika personalizacji każdej drużyny — nie tylko obsługują light i dark mode, ale umożliwiają tworzenie trybów niestandardowych, jak „Wolf Mode” dla Minnesota Timberwolves.
System rozróżnia, co zmienia się między drużynami (kolory brandowe, fonty display, border-radius), a co pozostaje stałe (neutrals, typografia użytkowa w Inter, line height).
Tokeny interakcji standaryzują zachowania press i hover dla wszystkich komponentów, eliminując potrzebę każdorazowego opisywania tych wartości inżynierom przy handoffie.
Największe błędy w historii systemu to: zbyt duże komponenty wariantowe powodujące crash Figmy, nieprzemyślana przestrzeń wokół logo skutkująca długiem technicznym oraz architektura trybów niedostosowana do planu Enterprise.
Plik systemu projektowania dzieli się na sekcję dla inżynierów i PM-ów oraz sekcję roboczą dla designerów.
Debug menu w aplikacji mobilnej i Storybook na webie to kluczowe narzędzia do weryfikacji poprawności wdrożenia tokenów interakcji.

Kontekst: jeden system, dziesiątki drużyn

Jump to startup, który zamknął rundę Series A na 23 miliony dolarów i ogłosił, że będzie platformą ticketingową i aplikacyjną dla Minnesota Timberwolves. Firma aktywnie podpisuje kolejne kontrakty z drużynami sportowymi, dlatego liczba obsługiwanych marek rośnie dynamicznie.

Cornelius, lead product designer w Jump, pracuje w dwuosobowym zespole projektantów działającym w firmie zatrudniającej łącznie około 50 osób. Zadanie, przed którym stoi, jest wymagające: jeden system projektowania musi obsłużyć dziesiątki różnych marek, z których każda ma własne kolory, fonty i tożsamość wizualną. Jak podkreśla w rozmowie, ten kontekst jest niezbędny do zrozumienia całego systemu — tłumaczy zarówno potrzebę efektywności, jak i nieuchronność pewnych kompromisów.

Architektura pliku: biznes z przodu, impreza z tyłu

Cornelius organizuje plik Figma według zasady, którą sam określa jako „business in the front, party in the back”. Na górze pliku znajduje się sekcja przeznaczona dla inżynierów i product managerów: specyfikacje komponentów, tokeny kolorów i typografii oraz dokumentacja stanów. Na dole pracuje designer — tam trafiają szkice, iteracje i materiały robocze, których inżynier nie musi oglądać.

Ta sama logika obowiązuje w codziennej pracy. Sekcja handoffowa zawiera gotowe specyfikacje i materiały do QA, natomiast sekcja eksploracji pozostaje przestrzenią nieposortowaną, dostępną wyłącznie dla designerów.

Hierarchia komponentów

System stosuje klasyczny podział na poziomy abstrakcji:

Sub-komponenty (atomy) — najmniejsze elementy, takie jak pojedyncze tokeny kolorów, ikony czy etykiety przycisków.
Komponenty (molekuły) — połączenia atomów: przyciski, chipy, wiersze listy.
Organizmy i szablony — gotowe struktury trudne do szybkiej modyfikacji, personalizowane automatycznie przez system trybów.
Sekcje specjalne — ikony nawigacji, loga drużyn, zdjęcia zawodników oraz narzędzia anotacyjne.

Dwa pliki zamiast jednego

W miarę dojrzewania systemu Cornelius przenosi całą eksplorację do osobnego pliku roboczego w ramach tego samego projektu Figma. Główny plik pozostaje wówczas czysty i szybki w obsłudze. Plik eksploracji z kolei przechowuje badania, studia fontów i stare komponenty w tak zwanym „cmentarzyku” — materiały, do których warto wrócić, lecz które są zbędne w codziennym widoku biblioteki.

Tryby Figmy jako silnik personalizacji marek

Tryby stanowią centralny mechanizm całego systemu. Cornelius demonstruje to na żywo: po zbudowaniu kilku ekranów przepływu zakupu biletów dla North Carolina Courage (kobiecy zespół piłkarski NWSL) zmienia ID drużyny na Bucknell Bison (koszykówka uczelni) — w rezultacie cały przepływ zmienia się natychmiast. Inne zdjęcia stadionu, inny harmonogram meczów, inne kolory — wszystko za sprawą jednej zmiany w ustawieniach trybu.

Co się zmienia, a co pozostaje stałe

Cornelius podkreśla, że kluczem do efektywnego systemu jest minimalizacja tego, co musi być unikalne dla każdej drużyny. Między drużynami zmieniają się: kolor brandowy (brand core, brand light, brand dark) wraz z kolorami interaktywnymi, font display z indywidualnym rozmiarem i letter-spacingiem, border-radius przycisków oraz nazwy drużyny we wszystkich wariantach.

Stałe dla wszystkich drużyn pozostają natomiast typografia użytkowa w Inter, paleta neutrals i line height fontów display. Ten ostatni element jest szczególnie ważny: dzięki zachowaniu tej samej wysokości linii wysokość komponentów nie zmienia się przy przełączaniu między drużynami, co eliminuje niespodziewane przesunięcia layoutu.

Biblioteka zmiennych zawiera też jeden nieoczywisty element: kolory drużyn rywali. Pojawiają się one w komponentach prezentujących harmonogram meczów, gdzie konieczne jest wyświetlenie barw przeciwnika. Obok drużyn aktywnych w systemie znajdują się również konfiguracje drużyn, z którymi Jump jeszcze nie współpracuje — jednak gotowe szablony pozwalają błyskawicznie przygotowywać prezentacje dla potencjalnych klientów, zanim umowa zostanie podpisana.

Team stylesheet jako narzędzie debugowania

Cornelius opracował komponent zwany „team stylesheet”, który wyświetla komplet zmiennych dla każdej drużyny w jednym miejscu. Inżynier może go otworzyć, przełączać między drużynami i natychmiast porównywać różnice — kolory jako wartości hex, rozmiary i letter-spacing dla fontów display, nazwy drużyn we wszystkich wariantach oraz wartości border-radius i paddingu przycisków.

Gdy trzeba skonfigurować nową drużynę, inżynier otrzymuje przede wszystkim ten arkusz. Dla bardziej wymagających klientów — jak Timberwolves, gdzie dostosowano przyciski, tła i stworzono tryb niestandardowy — dokumentacja jest odpowiednio rozbudowana.

Checklista: co przygotować przed konfiguracją nowej drużyny

(Interpretacja na podstawie treści rozmowy)

Kolory brandowe jako wartości hex: brand core, brand light, brand dark, kolory interaktywne
Font display: nazwa kroju, rozmiar dla każdego stylu tekstowego, wartość letter-spacing
Nazwy drużyny: pełna, skrócona, skrót, ewentualny slang
Border-radius i padding przycisków (jeśli odbiegają od wspólnego standardu)
Kolory tła i definicja trybu niestandardowego — wymagane dla drużyn z własnym trybem

Wolf Mode: kiedy light i dark to za mało

Minnesota Timberwolves nie korzystają z light mode ani dark mode. Mają „wolf mode” — granatowy tryb zaprojektowany przez Corneliusa, by lepiej oddać charakter marki drużyny. To przykład tego, jak architektura oparta na trybach pozwala wychodzić poza standardowe założenia i tworzyć unikalne doświadczenia brandowe bez przebudowy całego systemu.

Tokeny interakcji: jak press i hover działają dla każdej marki

Cornelius opisuje własną filozofię zachowania przycisku: w stanie spoczynku leży płasko na powierzchni. Po najechaniu kursorem zbliża się do użytkownika — staje się nieco większy i jaśniejszy. Po kliknięciu cofa się — staje się ciemniejszy i mniejszy. Jak zaznacza, nie chodzi o skeuomorfizm, lecz o subtelną podpowiedź taktylną, która pomaga użytkownikowi zrozumieć, że element jest interaktywny.

Gdyby jednak każda drużyna miała własne kolory stanów pressed i hover, konfiguracja nowego klienta byłaby żmudna. Dlatego system opiera się na nakładkach kolorystycznych.

Interactive surface tokens

Na przycisk w stanie hover nakładana jest warstwa white 300 (przybliżona przezroczystość 30%). Na stan pressed — warstwa mode agnostic black 300. Wartości nie są dokładnie 30%, ponieważ biały i czarny zachowują się chromatycznie inaczej — zostały dostrojone do wartości, które, jak ujmuje to Cornelius, „czują się jak 30%”. W efekcie wystarczy zdefiniować jeden kolor brandowy, a system sam generuje poprawne stany interakcji dla każdej drużyny.

Osobnym przypadkiem jest czarny przycisk w stanie pressed: zawartość wewnątrz opada do 60% opacity zamiast ciemnieć, bo czarny nie może stać się ciemniejszy. System obsługuje tę sytuację automatycznie.

Interactive scale tokens

Nie wszystkie komponenty powinny skalować się w tym samym stopniu. Mały element wymaga większej proporcji powiększenia, żeby zmiana była zauważalna. Z tego powodu system dysponuje trzema tokenami skali: dużym (dla największych elementów), średnim i małym. Inżynier otrzymuje gotową wartość — na przykład fill neutral scale 300 — i nie musi pytać o szczegóły przy każdym nowym komponencie.

Istotna różnica dotyczy platform: na urządzeniach mobilnych hover praktycznie nie istnieje, więc skalowanie w górę przy najechaniu nie jest potrzebne. Skalowanie przy press działa też nieco inaczej na iOS i na webie — największe elementy mogą rosnąć proporcjonalnie bardziej w środowisku przeglądarkowym. Tokeny kodują te różnice osobno dla każdej platformy.

Testowanie poza Figmą

Figma nie obsługuje CSS-owego skalowania proporcjonalnego, dlatego Cornelius testował wartości tokenów skali w JSFiddle, budując tam kształty i weryfikując, jak animacje wyglądają w praktyce. Pliki JSFiddle trafiły do inżynierów webowych jako element dokumentacji — „mówią ich językiem”, jak stwierdza Cornelius. Po stronie deweloperskiej weryfikacja tokenów odbywa się przez debug menu w aplikacji mobilnej, uruchamiane potrząśnięciem telefonu, oraz przez Storybook na webie — choć Cornelius uczciwie przyznaje, że podczas nagrania surfaces w Storybooku akurat nie działały.

Sukces całego systemu Cornelius przypisuje w dużej mierze frontendowym inżynierom, którzy zaangażowali się w budowanie narzędzi najwyższej klasy. Bez debug menu testowanie każdego stanu wymagałoby ręcznego screenshotowania lub nagrywania ekranu i proszenia o wklejanie wartości z kodu do Slacka.

Handoff do inżynierów: specyfikacje, anotacje, Jira

Dla nowych komponentów Cornelius przygotowuje arkusze ze specyfikacjami, stosując kombinację dwóch podejść. Tam, gdzie Figma radzi sobie z natywnym adnotowaniem — kolory, typografia — używa wbudowanego narzędzia. Własny komponent anotacyjny wchodzi natomiast tam, gdzie natywne adnotacje mają ograniczenia. Cornelius wskazuje dwa powody jego istnienia: system powstawał zanim Figma w ogóle miała narzędzie do adnotacji, a dodatkowo natywne narzędzie wciąż ma trudności z jasnym pokazywaniem paddingu między dwoma obiektami. Własny komponent pozwala zmierzyć odległość i od razu przeliczyć ją na token rozmiaru — na przykład 24dp na odpowiadający token z biblioteki.

Przy modyfikacjach istniejących komponentów Cornelius zestawia stary i nowy wariant obok siebie, opisuje dwie lub trzy konkretne zmiany i wyjaśnia, dlaczego są potrzebne — często z referencją do screenshotu z aplikacji pokazującego problem. Opis trafia też do ticketu Jira.

Czego unikać: lekcje z błędów

Za duże komponenty wariantowe

Na początku system zawierał jeden rozbudowany komponent przycisku obejmujący wszystkie warianty naraz — stany, style i tryby. Zarządzanie nim spowalniało Figmę i prowadziło do awarii aplikacji. Cornelius musiał rozbić go na trzy osobne komponenty: button, button destructive i button neutral. Wniosek, który z tego wyciąga: istnieją granice tego, ile wariantów można sensownie upakować w jeden komponent, i warto je poznać, zanim staną się problemem.

Nieprzemyślana przestrzeń wokół logo

Pierwsze wersje logo drużyn miały duży padding wokół grafiki, a wszystkie pierwsze komponenty zaprojektowano pod te wymiary. Gdy jednak pojawiły się ekrany z dziesiątkami małych logo — harmonogramy meczów, zestawienia — okazało się, że zbyt duży odstęp uniemożliwia budowanie zwartych interfejsów.

Dług techniczny istnieje do dziś: w produkcji działa specjalny „spacing container” — dodatkowa warstwa paddingu nakładana na logo przy starych komponentach. Refaktoryzacja czeka, bo trudno uzasadnić jej wartość biznesową wobec konieczności dostarczania nowych funkcji. Wniosek, który Cornelius formułuje wprost: atomy mają efekt motyla — błąd na tym poziomie rozprzestrzenia się na cały system.

Architektura trybów przed planem Enterprise

Przed wykupieniem planu Enterprise Figma ograniczała liczbę trybów w jednym zbiorze do czterech. W rezultacie Cornelius musiał tworzyć podzbiory trybów (3a, 3b, 3c), które „wchodziły” do nadrzędnych bibliotek dark/light. Zamiast jednej biblioteki team modes działały cztery lub pięć. Po przejściu na Enterprise problem zniknął, jednak „duchy” starych bibliotek nadal pojawiają się w niektórych komponentach — Cornelius apeluje do Figmy o mechanizm czyszczenia tych pozostałości.

Display text bez obsługi trybów

Pierwsze komponenty wyświetlające tekst display nie korzystały z trybów — zamiast tego opierały się na menu dropdown z ID drużyny. Po zmianie drużyny tekst nie aktualizował się automatycznie i trzeba go było przepisywać ręcznie. Tryby rozwiązały ten problem, jednak przepisanie wszystkich komponentów wymagało znacznego nakładu pracy.

Checklista: błędy, których uniknąć przy budowie systemu wielomarkowego

(Interpretacja na podstawie treści rozmowy)

Czy rozmiar komponentu wariantowego nie spowalnia Figmy? Jeśli tak — rozbić na kilka mniejszych.
Czy footprint logo jest wystarczająco ciasny przed zaprojektowaniem pierwszych komponentów?
Czy display text jest podpięty pod tryby, a nie pod ręczny dropdown z ID drużyny?
Czy plan Figma dysponuje wystarczającą liczbą trybów w jednym zbiorze? (Plan Enterprise znosi limit czterech trybów.)
Czy po migracji trybów nie pojawiają się pozostałości starych bibliotek w komponentach?

Inspiracje i narzędzia

Projektowanie dark mode Cornelius rozpoczął od konkretnego problemu: odziedziczony system agencji miał dark mode, który był po prostu „bardzo czarny” — czarne tło, czarne karty, czarny interfejs. Żeby znaleźć lepsze rozwiązanie, przeanalizował screenshoty z kilkudziesięciu aplikacji iOS, Google i serwisów takich jak Spotify, badając, jakie kolory tła i kart stosują w trybie ciemnym.

Kluczowe odkrycie przyszło z analizy Nextdoor: ich light mode używa szarego tła z białymi kartami, a dark mode odwraca tę relację — ciemne tło, jaśniejsze karty na wierzchu. To wzorzec, do którego użytkownicy są przyzwyczajeni. Naturalna intuicja, że maksymalny kontrast wymaga czarnych kart na szarym tle, okazuje się zatem niezgodna z oczekiwaniami użytkowników.

Do szybkiego zbierania screenhotów z innych aplikacji Cornelius używa Mobbin z wtyczką do Figmy, która pozwala importować materiały referencyjne bezpośrednio do pliku roboczego.

Narzędzia wspomniane w materiale

Figma — modes, variables, annotations
Mobbin — biblioteka screenhotów aplikacji mobilnych z wtyczką do Figmy
JSFiddle — testowanie animacji i skali interakcji
Storybook — dokumentacja i testowanie komponentów na webie
Jira — zarządzanie ticketami zmian komponentów

Kluczowy insight

Mniej opcji, więcej marek

Standardowo myślimy: dobry system dla wielu marek to system elastyczny — im więcej zmiennych można dostosować, tym więcej klientów można obsłużyć, dlatego projektujemy z myślą o maksymalnej konfigurowalności.

W praktyce okazuje się, że: kluczem do obsłużenia 50+ marek jest radykalne ograniczenie tego, co w ogóle podlega zmianie. Dwuosobowy zespół designerski Jump obsługuje dziesiątki drużyn, bo zdecydował, że zmieniają się tylko cztery zmienne: kolory brandowe, font display, border-radius i nazwy. Wszystko inne — typografia użytkowa, neutrals, line height, logika interakcji — jest zablokowane. To nie jest ograniczenie systemu. To jego siła.

Dlaczego to jest istotne: każda dodatkowa zmienna, którą wpuszczamy do systemu „dla elastyczności”, mnoży kombinacje konfiguracji, wydłuża czas wdrożenia nowego klienta i zwiększa ryzyko błędu. System, który pozwala na wszystko, nie skaluje się na nic.

Test na jutro: następnym razem, gdy projektujesz system dla więcej niż jednej marki lub kontekstu, zamiast pytać „co powinno być konfigurowalne?” — zapytaj „co absolutnie musi pozostać niezmienne?” i zacznij od tej listy. Sprawdź, ile pozornie koniecznych zmiennych można wyeliminować bez utraty wartości dla klienta.

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: Sneak Peek — odcinek z Corneliusem z Jump

Tag: Handoff Design Engineering

Jak zbudować system projektowania Figma dla 50+ marek sportowych #EN376