Multibrandowy Design System – jak w Silky Coders przyspieszamy rozwój marek LPP

W Silky Coders tworzymy rozwiązania UX/UI oraz technologię, która pozwala je wdrażać. Pracując nad ekosystemami wizualnymi brandów LPP, stanęliśmy przed wyzwaniem: jak rozwijać je równolegle, szybciej i bardziej przewidywalnie, bez utraty ich odrębności. Skala i tempo rozwoju LPP sprawiły, że potrzebowaliśmy rozwiązania, które nie tylko odpowie na bieżące potrzeby, ale stworzy fundament pod dalszy, coraz bardziej zróżnicowany wzrost. 

Rozwijając aplikacje mobilne i sklepy internetowe dla pięciu marek LPP, szybko zobaczyliśmy, że osobne porządkowanie designu i kodu nie wystarczy. Potrzebowaliśmy jednego środowiska pracy i spójnego modelu działania dla projektantów i developerów. Odpowiedzią na tę potrzebę stał się Multibrandowy Design System – wewnętrzny produkt, który porządkuje warstwę wizualną, wspiera skalowanie rozwiązań w organizacji i łączy design z developmentem. 

Od początku patrzyliśmy na ten obszar wspólnie, bo dobrze zaprojektowane rozwiązanie bez wdrożenia nie ma pełnej wartości, a wdrożenie bez uporządkowanego projektu szybko generuje chaos i niespójności. 

W rozmowach między projektantami i zespołami developerskimi regularnie wracały te same problemy: 

• dokumentacja styli i komponentów była rozproszona między markami i platformami, 

• wdrażanie zmian oraz usprawnień było czasochłonne i nie zawsze efektywne, 

• skalowanie podobnych rozwiązań między markami i platformami wymagało zbyt dużo pracy manualnej, 

• utrzymanie spójności między designem a kodem stawało się coraz trudniejsze wraz ze wzrostem skali. 

Ważnym etapem w rozwoju tego podejścia była współpraca z zespołem Android. Wspólnie przygotowaliśmy proof of concept, który pomógł nam doprecyzować model pracy, jaki chcemy dalej rozwijać jako proces i wewnętrzny produkt dla organizacji. Podczas dedykowanego spotkania zaprezentowaliśmy live demo: zmieniliśmy wybrane wartości w Figmie, a chwilę później zobaczyliśmy ich efekt po stronie technologii na przykładowym ekranie. To utwierdziło nas w przekonaniu, że warto rozwijać ten kierunek wspólnie z zespołami technologicznymi.

Fundamentem tej zmiany stały się design tokeny, czyli uporządkowana warstwa wartości opisujących elementy wizualne, takie jak kolory, typografia, odstępy, zaokrąglenia czy cienie. Zamiast wpisywać konkretne wartości w wielu miejscach, definiujemy je raz i korzystamy z nich zarówno po stronie designu, jak i technologii. Dzięki temu zyskaliśmy jedno źródło prawdy. 

Równie ważne było uporządkowanie architektury tokenów. Wcześniej wiele decyzji wizualnych opierało się głównie na warstwie prymitywnej z nazwami takimi jak Iron, Ash czy Red, co słabo opisywało kontekst użycia. Dziś, obok warstwy prymitywnej, korzystamy także z warstwy semantycznej i komponentowej, które precyzyjnie obrazują znaczenie i zastosowanie wartości w interfejsie. Tę architekturę zaprojektowaliśmy w sposób multibrandowy, dzięki czemu marki korzystają ze wspólnego fundamentu, zachowując własny charakter i elastyczność. 

W przypadku Androida poszliśmy krok dalej i zautomatyzowaliśmy część przejścia od projektu do implementacji. Zmiany przygotowywane w Figmie są pobierane przez API i przetwarzane przez parser do formy wykorzystywanej bezpośrednio po stronie technologii. 

W praktyce oznacza to, że developerzy nie muszą już ręcznie wprowadzać zmian w warstwie wizualnej. Pracują na wcześniej opisanych zależnościach, a wdrożenie sprowadza się głównie do przyjęcia zmiany, weryfikacji z QA i drobnych korekt. Dzięki temu czas wprowadzania skrócimy z kilku dni do nawet kilku godzin. 

Zmianę odczuli także projektanci. Dzięki nowej architekturze uprościliśmy środowisko projektowe w Figmie, redukując liczbę bibliotek wymagających bieżącej opieki z 34 do 10. To ułatwiło utrzymanie systemu i zwiększyło przewidywalność pracy. W przypadku tej samej inicjatywy realizowanej jednocześnie dla pięciu marek działamy dziś nawet do 80% szybciej. Tworząc rozwiązanie dla jednego brandu, w praktyce przygotowujemy już bazę dla pozostałych. Przeniesienie komponentu lub widoku oznacza dziś automatyczne dziedziczenie właściwych fundamentów i stylowania, bez potrzeby ręcznej pracy. 

Z efektów tej zmiany korzystają już także zespoły pracujące z narzędziami opartymi o AI, w tym agentami wykorzystującymi MCP. Uporządkowana architektura zmiennych, lepiej przygotowane komponenty i precyzyjnie opisane warianty sprawiają, że takie narzędzia lepiej pracują na nowych bibliotekach niż na poprzednim rozwiązaniu. W praktyce oznacza to mniej błędnych interpretacji, mniej poprawek i krótszy czas dojścia do gotowego prototypu, implementacji w kodzie. 

Ta inicjatywa powstała oddolnie, z konkretnych potrzeb projektowych i technologicznych, i szybko zaczęła przynosić realne efekty. W jednym z projektów świadomie rozszerzyliśmy zakres wdrożenia na dodatkowe dwie marki, mimo że pierwotna wycena obejmowała tylko jedną. Estymacja pozostała jednak na tym samym poziomie. To dobrze pokazuje potencjał wspólnej, dobrze zaprojektowanej architektury. 

Korzyści widzą też same zespoły. Projektanci i developerzy zyskują większą kontrolę nad procesem, a uporządkowany system i większa przewidywalność zmian ułatwiają współpracę z QA i weryfikację wdrożeń. 

Po doświadczeniach z platformą Android rozwijamy to samo podejście po stronie iOS i Web, pracując wspólnie z liderami technicznymi tych platform. Równolegle rozwijamy narzędzia wspierające codzienną pracę projektantów i developerów, w tym rozwiązania oparte o AI. Z pomocą sztucznej inteligencji stworzyliśmy także kilka wtyczek do Figmy, które wspierają codzienną pracę osób rozwijających rozwiązania multibrandowe. 

Nie traktujemy tego jako zamkniętego projektu. To sposób myślenia o współpracy między designem i technologią, który pozwala szybciej reagować na potrzeby biznesu i skuteczniej odpowiadać na tempo zmian w ecommerce.