Design system, którego zespoły naprawdę używają
Przez kilka lat prowadziłem design system w dużej instytucji finansowej. Na trzech platformach naraz – web, iOS, Android – dla wielu zespołów produktowych.
Trzy platformy, trzy prędkości
Design system istniał, ale żył w trzech wersjach naraz. Każda platforma szła własnym tempem. To, co w Figmie wyglądało spójnie, w kodzie rozjeżdżało się między web, iOS i Androidem.
Zespoły kopiowały komponenty, zamiast ich używać. Szybciej było zrobić coś po swojemu niż znaleźć źródło prawdy. System był na papierze, ale w codziennej pracy prawie nie istniał.
Skala, w której to działało
Siedem zespołów produktowych na trzech platformach – web, iOS i Android. Ponad 50 komponentów w bibliotece, pełna architektura tokenów – prymitywy i warstwa semantyczna – oraz dokumentacja w jednym miejscu, w Storybooku.
W tej skali nie da się utrzymać spójności siłą woli. Utrzymują ją decyzje: architektura, proces zmian i nawyki zespołów.
Najpierw decyzje, potem komponenty
- Uporządkowałem architekturę tokenów – jedno źródło prawdy dla web, iOS i Androida.
- Ustawiłem governance: kto decyduje o zmianach, jak wchodzą do systemu, kto je zatwierdza.
- Przeniosłem dokumentację do Storybooka, żeby zespoły miały jedno miejsce zamiast trzech.
- Zbudowałem proces adopcji tak, żeby używanie systemu było łatwiejsze niż obchodzenie go.
- Prowadziłem szkolenia wewnętrzne dla designerów i developerów.
System z dokumentu, do którego nikt nie zaglądał, stał się narzędziem, którego używa się codziennie.
Zespoły przestały budować od zera
Nowy ekran zaczął powstawać z istniejących klocków, nie z komponentów robionych od nowa. Zespoły przestały pytać „gdzie jest źródło" i zaczęły same zgłaszać braki systemu. Nikt nie zgłasza braków w czymś, czego nie używa.
Najważniejsze: system działał dalej, kiedy odchodziłem. Zostały decyzje i proces, nie zależność ode mnie.
Komponenty można dorobić. Governance buduje się miesiącami
Największym problemem design systemu rzadko jest brak komponentów. Jest nim brak decyzji – kto za co odpowiada i jak system się zmienia.
Komponenty dorobisz szybko. Trudniejsze jest to, żeby system miał właściciela i przetrwał zmiany w zespołach. Bez tego najlepsza biblioteka cicho umiera.
Masz podobną sytuację?
Jeśli Twój system też istnieje głównie na papierze – najczęściej zaczyna się od audytu: pełnej diagnozy tego, co masz naprawdę. A jeśli system działa, ale nie ma gospodarza – zobacz, jak wygląda stałe wsparcie zespołu.
Komponenty można dorobić. Governance buduje się miesiącami – i od niego wszystko zależy.
Napisz dwa zdania: jaki masz system i gdzie zaczyna się rozjeżdżać. To wystarczy na start – odpowiadam w 1–2 dni robocze.
radoslaw.latarski@gmail.com · LinkedIn · Zarezerwuj rozmowę →
Rozmowa bez zobowiązań i bez prezentacji handlowej. Czasem wystarczy jedna rozmowa, żeby zobaczyć problem inaczej.