Przyszłość systemów projektowych

System projektowy łatwo pomylić z katalogiem komponentów. Biblioteka przycisków i formularzy pomaga zachować spójność, ale sama nie odpowiada na ważniejsze pytania: kto podejmuje decyzje, jak zmiana trafia do produktów i po czym wiadomo, że system jest używany.

Dojrzały system jest infrastrukturą produktu. Łączy reguły wizualne, kod, dostępność, dokumentację oraz proces utrzymania.

#Tokeny opisują znaczenie, nie tylko wartości

Płaska lista kolorów i odstępów szybko przestaje wystarczać. Bardziej odporna struktura ma kilka warstw:

1. prymitywy — surowe wartości, na przykład konkretny kolor;
2. tokeny semantyczne — rola w interfejsie, na przykład tło akcentu;
3. tokeny komponentu — użycie w konkretnym stanie przycisku lub pola.

Dzięki temu tryb jasny, ciemny albo kolejna marka może zmieniać mapowanie semantyczne bez przepisywania każdego komponentu.

Prace nad wspólnym formatem prowadzi Design Tokens Community Group. Standard formatu jest ważny, ale nie zastąpi nazewnictwa dopasowanego do produktu. Token yellow-500 opisuje wygląd; color-action-primary opisuje decyzję.

#API komponentu jest częścią doświadczenia

Propsy i warianty określają, jak łatwo zbudować poprawny ekran. Jeśli każdy komponent ma kilkanaście niezależnych przełączników, zespół może tworzyć kombinacje, których nikt nie zaprojektował ani nie przetestował.

Coraz częściej lepiej działa kompozycja mniejszych elementów niż jeden komponent próbujący obsłużyć każdy scenariusz. Granice nadal są potrzebne: system powinien ułatwiać rozwiązania dostępne i spójne, a utrudniać przypadkowe odstępstwa.

Dostępność powinna być częścią kontraktu komponentu. Pole formularza potrzebuje etykiety i sposobu przekazania błędu; modal potrzebuje zarządzania fokusem; element interaktywny potrzebuje obsługi klawiatury. Dokumentacja bez działających ograniczeń przerzuca odpowiedzialność na każdy zespół osobno.

#Jedno źródło prawdy nie musi oznaczać jednego narzędzia

Projekt i kod mają inne zadania. Problemem nie jest istnienie Figmy, Storybooka i repozytorium, lecz brak jasno określonego właściciela każdej decyzji.

Praktyczny podział może wyglądać tak:

Narzędzia takie jak Figma Code Connect mogą łączyć komponenty projektowe z implementacją. Automatyzacja pomaga, lecz nie rozstrzyga, która zmiana jest zgodna z produktem.

#System wielomarkowy potrzebuje rozdzielenia warstw

W produktach white-label i pracy dla wielu marek szczególnie ważne jest oddzielenie:

• logiki interakcji i dostępności;
• struktury komponentu;
• tokenów marki;
• treści i reguł lokalnych.

Jeśli logo, kolor i promień zaokrąglenia są zaszyte w logice komponentu, każda nowa marka tworzy kolejne wyjątki. Jeżeli wszystko jest dowolnie konfigurowalne, system traci spójność. Dobry model wskazuje, co może zmieniać się między markami, a co pozostaje wspólnym standardem jakości.

#Governance decyduje, czy system przetrwa

System projektowy wymaga właściciela i procesu podobnie jak inny produkt wewnętrzny. Minimum obejmuje:

• sposób zgłaszania potrzeby lub błędu;
• kryteria dodania nowego wariantu;
• wersjonowanie i opis zmian;
• zasady wycofywania komponentów;
• plan migracji produktów;
• mierzenie adopcji.

Sama liczba komponentów jest słabą miarą sukcesu. Lepsze pytania to: ile ekranów korzysta ze wspólnej wersji, jak długo trwa aktualizacja i ile lokalnych kopii nadal istnieje.

#Kiedy nie budować pełnego systemu?

Mały produkt nie zawsze potrzebuje osobnego zespołu, rozbudowanego portalu i setek tokenów. Czasem wystarczy dobrze zorganizowana biblioteka, kilka zasad i wspólne komponenty formularzy.

Pełniejszy system zaczyna się opłacać, gdy:

• te same wzorce powtarzają się w kilku produktach;
• wiele zespołów rozwija interfejs równolegle;
• marka ma warianty lub rynki;
• dostępność i zgodność muszą być wdrażane konsekwentnie;
• niespójność zaczyna spowalniać rozwój.

Przyszłość systemów projektowych nie polega więc na większej liczbie komponentów. Polega na lepszym przepływie decyzji między projektem, kodem i zespołami, które używają systemu każdego dnia.