Design system działa tylko wtedy, gdy ktoś nim zarządza

DesignOps to proces, narzędzia i szkolenia, dzięki którym design system jest używany, aktualny i ma właściciela. Obejmuje zasady wprowadzania zmian, numerowanie wersji, dokumentację i regularne przeglądy stanu systemu. Bez tego system traci spójność w rok: komponenty się dublują, dokumentacja się starzeje, a zespoły go omijają.

Design system to projekt jednorazowy: zaprojektowanie i wdrożenie komponentów oraz zasad. DesignOps to ciągłe utrzymanie systemu, który już istnieje: proces zmian, narzędzia, szkolenia i adopcja w zespołach. Pierwsza usługa kończy się gotowym systemem, druga pilnuje, żeby rok później nadal był w użyciu.

DesignOps jest potrzebny, gdy design system istnieje w Figmie i w kodzie, ale nikt za niego nie odpowiada. Objawy: te same komponenty w kilku wersjach w różnych zespołach, dokumentacja, która nie nadąża za zmianami, brak jasności, kto może system zmieniać, i nowe osoby, które z niego nie korzystają.

Audyt stanu systemu wyceniamy zależnie od jego skali. Stałą opiekę rozliczamy miesięcznie, a opłata zależy od wielkości zespołu i częstotliwości zmian. Wstępną wycenę podajemy po pierwszej rozmowie. O stałej opiece firma decyduje dopiero po audycie, z wynikiem w ręku.

Usługa obejmuje audyt stanu systemu, zasady zmian i numerowania wersji, uporządkowanie albo wdrożenie Storybooka i automatycznego przenoszenia tokenów z Figmy do kodu, szkolenie projektantów i deweloperów, cykliczne przeglądy oraz analitykę użycia komponentów. Efektem jest system używany w organizacji, z jasnym procesem zmian i regularnym przeglądem z liczbami.

Stan design systemu oceniamy w liczbach: przy każdym przeglądzie przechodzimy przez plik w Figmie i oceniamy zdrowie systemu od 0 do 100 w pięciu obszarach. Są to kolory i tokeny, odstępy i układ, typografia, komponenty oraz nazwy i dokumentacja. Wynik porównujemy z poprzednim przeglądem, więc widać, czy system się porządkuje, czy rozjeżdża.

Tak. Pracę otwiera audyt stanu systemu, niezależnie od tego, kto go zbudował: Squares, zespół wewnętrzny czy inny wykonawca. Audyt pokazuje, ile zespołów faktycznie używa systemu, gdzie komponenty się rozeszły i co wymaga naprawy. Po nim wiadomo, co zostaje, a co trzeba uporządkować.

Tak. Szkolenie projektantów i deweloperów z korzystania z systemu i jego rozwijania jest częścią zakresu i nie wymaga osobnego zamówienia. Bez szkolenia nowe osoby w zespole systemu nie używają. W planie pracy następuje ono po ustaleniu zasad zmian i uporządkowaniu narzędzi.

Przeglądy odbywają się co miesiąc albo co kwartał. Do przeglądu potrzebny jest dostęp do pliku systemu w Figmie i do katalogu komponentów w kodzie, na przykład w Storybooku. Każdy przegląd wskazuje odstępstwa od systemu, od najpilniejszego, i mierzy, które komponenty i tokeny są faktycznie używane.

DesignOps jako osobna usługa jest nowy w ofercie i osobnego case study jeszcze nie ma. Opieramy go na design systemach, które zbudowaliśmy: jednym systemie dla czterech marek NoHo Group i design systemie serwisu pompy.app, opisanym raz, żeby rozbudowa nie psuła spójności wyglądu. Stąd wiemy, które decyzje projektowe nie sprawdzają się w praktyce.