Przyszłość systemów projektowych

Systemy projektowe zaczynały jako biblioteki wzorców: katalog przycisków, pól formularzy i stylów typografii, który utrzymywał produkt spójnym wizualnie. To było przydatne. Ale w miarę jak produkty rosły — więcej platform, więcej marek, więcej zespołów — pierwotny model biblioteki wzorców zaczął pękać w szwach.

Następna generacja systemów projektowych jest bardziej architektoniczna niż kosmetyczna. Oto, dokąd zmierza ta dziedzina.

#Tokeny jako warstwa prymitywna

Tokeny projektowe — nazwane wartości dla kolorów, odstępów, typografii, ruchu — nie są nowe, ale sposób ich strukturyzowania szybko dojrzewa. Przesunięcie następuje od płaskich list tokenów do wielopoziomowych architektur tokenów: tokeny prymitywne (surowe wartości jak #ffb800) zasilają tokeny semantyczne (color.accent.default), które zasilają tokeny komponentów (button.background.hover).

Takie warstwowanie sprawia, że theming staje się wykonalny. Zmiana marki lub trybu (jasny/ciemny) sprowadza się do przemapowania jednej warstwy bez dotykania definicji komponentów. Narzędzia takie jak Style Dictionary oraz powstający format W3C Design Token Community Group wnoszą standaryzację do przestrzeni wcześniej rozdrobnionej.

Praktyczna konsekwencja dla zespołów: tokeny powinny istnieć w formacie, który mogą konsumować zarówno projektanci, jak i inżynierowie. Gdy token zmienia się w Figmie, powinien automatycznie propagować się do kodu — nie przez ręczny proces przekazania.

#API komponentów jako decyzje produktowe

API komponentu — propsy, które komponent udostępnia, warianty, które wspiera, zachowanie, które koduje — jest coraz częściej uznawane za decyzję produktową, a nie tylko techniczną. Źle zaprojektowane API tworzy tarcie dla każdego zespołu, który używa komponentu; dobrze zaprojektowane zwielokrotnia tempo w całej organizacji.

Trend zmierza ku kompozycji zamiast konfiguracji: mniejsze prymitywy o jednej odpowiedzialności, które zespoły dowolnie łączą, zamiast dużych monolitycznych komponentów z dziesiątkami propsów próbujących przewidzieć każdy przypadek użycia. Radix UI i Headless UI spopularyzowały ten wzorzec; jest on dziś domyślnym modelem mentalnym poważnych zespołów systemowych.

Dostępność przechodzi z dodatku na końcu do pełnoprawnego ograniczenia na poziomie API. Komponenty, które udostępniają właściwości dostępności jako wymagane propsy, czynią zgodne użycie ścieżką najmniejszego oporu.

#Systemy wielomarkowe i white-label

Najbardziej wymagającym kontekstem dla systemu projektowego jest taki, który musi obsługiwać wiele marek jednocześnie — platformy SaaS z własnym tenantingiem, agencje budujące dla wielu klientów, produkty enterprise z regionalnymi wymaganiami tożsamościowymi.

Systemy sprostające temu wyzwaniu są zbudowane wokół ścisłego rozdzielenia tożsamości marki (tokeny, ruch, styl ilustracji) od logiki strukturalnej (układ, rytm odstępów, wzorce interakcji). Warstwa strukturalna jest współdzielona; warstwa marki jest podmieniana dla każdego najemcy. Zespoły zarządzające takimi systemami coraz częściej traktują warstwę marki jak artefakt wdrożeniowy — generowany z konfiguracji, a nie utrzymywany ręcznie.

#Przepaść między projektowaniem a inżynierią się zamyka

Przez większość historii systemów projektowych istniała warstwa tłumaczenia: projektanci tworzą specyfikacje w Figmie, inżynierowie interpretują je i implementują w kodzie, a oba światy natychmiast się rozjeżdżają. Figma Code Connect, dodatek projektowy do Storybooka oraz narzędzia takie jak Supernova atakują ten problem z różnych stron — próbując sprawić, by jedno źródło prawdy było naprawdę jedno.

Idealnym stanem docelowym jest system, w którym zmiana tokenu lub wariant komponentu dodany w narzędziu projektowym propaguje się do bazy kodu przez automatyzację. Jeszcze tam nie jesteśmy, ale narzędzia zbliżają się do tego szybciej niż w jakimkolwiek momencie krótkiej historii tej dyscypliny.

#Co to oznacza dla zespołów

System projektowy to dziś infrastruktura, a nie projekt. Zespoły, które tak go traktują — obsadzając go na stałe, starannie wersjonując, mierząc jego adopcję — kumulują tempo w czasie. Zespoły, które pozwalają mu dryfować ku niespójności, płacą niewidzialny podatek od każdej funkcji, którą dostarczają.