Design Systems: Od Ghost Towns do zrównoważonej praktyki #EN178

Poniższy artykuł stanowi zbiór notatek z podcastu „Content Strategy Insights” (odcinek 169), w którym Dan Mall, założyciel Design System University i autor książki „Design that Scales”, dzielił się swoimi obserwacjami na temat tworzenia zrównoważonych praktyk design systemów. Wszystkie przedstawione przemyślenia, strategie i rekomendacje pochodzą od rozmówców podcastu.

TL;DR

Większość design systems umiera jako „ghost towns” – dobrze zbudowane komponenty, których nikt nie używa
Piloting kluczowy – nie buduj komponentów, potem każ zespołom używać, ale współpracuj z zespołami najpierw
4 korzyści, ale ulga najważniejsza – efficiency, consistency, innovation + odpoczynek i mniej wypalenia
Zmiana mindset z „noble” na „humble” – design systems to praca ogrodnika, nie heroiczny projekt
Ewolucja: project → product → practice – sukces wymaga ciągłej ewangelizacji i rytualów
Content-first approach – zaczynanie od treści w HTML, nie od komponentów w Figma
Prawdziwy Agile kontra pseudo-Agile – większość zespołów robi model kaskadowy w treściach/projektowaniu, agile tylko w programowaniu
Praca umysłowa ≠ praca przemysłowa – ograniczone obciążenie poznawcze przeciwko nieograniczonym możliwościom przemysłu
Irracjonalne powody przyjęcia – ludzie wybierają systemy jak drogie buty – z powodów emocjonalnych

Design systems mają jeden zasadniczy problem. Ludzie budują świetne komponenty, ale nikt ich nie używa. Dan Mall nazywa ten fenomen „ghost towns” – miasta duchów pełne pustych budynków. Jednak rozwiązanie tego problemu wymaga fundamentalnej zmiany w sposobie myślenia o systemach projektowania.

Problem ghost towns i graveyards

Większość design systems rozwija się według podobnego schematu. Para designer-developer dostrzega nieefektywność w pracy i tworzy zestaw komponentów. Komponenty są dobrze zaprojektowane, kod jest czysty, dokumentacja kompletna. Problem pojawia się jednak, gdy próbują podzielić się swoim dziełem z innymi zespołami.

Mall zauważa, że to co działa świetnie dla pary designer-developer, po udostępnieniu innym zespołom po prostu upada. W rezultacie organizacje gromadzą mnóstwo dobrze zrobionych design systems, których nikt nie używa. Z czasem te „ghost towns” zamieniają się w „graveyards” – cmentarze zakopanych projektów.

Dlaczego tak się dzieje? Mall wskazuje na błędne założenie: „Ludzie myślą, że jeśli stworzą najlepsze komponenty, to ludzie będą ich używać. Ale nie znam wielu produktów w naszym świecie, które tak działają.”

Cztery korzyści design systems (i ta najważniejsza)

Mall wyróżnia cztery główne korzyści design systems. Pierwsze trzy to typowe argumenty: efficiency, consistency, innovation. Czwarta jednak, jego ulubiona, jest rzadko omawiana.

„Jak robimy to w sposób, który daje nam ulgę, więcej odpoczynku, więcej energii?” – pyta Mall. Dlatego uważa, że o tym aspekcie mówi się najmniej, a może jest najważniejszy.

Problem polega na tym, że zespoły używają oszczędności czasu na pakowanie większej ilości pracy. Zamiast robić jedną rzecz w trzech miesiącach i dać sobie przerwę, pakują podwójną ilość pracy w te same sześć miesięcy. Mall ostrzega: „Wszystko to więcej, więcej, więcej. A widzimy, jaki to ma wpływ na ludzi – szybciej się wypalamy, ludzie odchodzą z pracy, quiet quitting.”

Zmiana mindset – od nobility do humility

Mall proponuje fundamentalną zmianę w sposobie myślenia o design systems. Zamiast „noble” (szlachetnego) podejścia, potrzebujemy „humble” (pokornego).

„Ogrodnictwo jest pokorne. Nie wiem, czy ktoś opisałby ogrodnictwo jako szlachetne” – wyjaśnia Mall. Ogrodnik brudzi sobie ręce, klęka w ziemi, codziennie podlewa rośliny. Nie można podlać raz i czekać, że deszcz się tym zajmie.

Ta metafora oddaje istotę pracy nad design systems. To nie heroiczny projekt, ale codzienna, brudna praca maintenance. Praca, o której nie pisze się blog postów, ale która jest niezbędna do wzrostu.

Piloting – kluczowy pierwszy krok

Mall uczy dwóch fundamentalnych rzeczy w design systems. Pierwsza to piloting – specyficzny sposób wprowadzania komponentów do systemu.

„Nie robimy komponentów, a potem każemy zespołom ich używać” – wyjaśnia Mall. Piloting to odwrotny proces. Najpierw należy współpracować z zespołami, zrozumieć ich problemy, a dopiero potem budować komponenty, które rzeczywiście rozwiązują ich trudności.

Drugą rzeczą jest proces i przepływ pracy – jak praktycznie pracować gdy już mamy design system. Tutaj Mall wprowadza swoje podejście content-first.

Content-first approach

Jedną z najważniejszych lekcji Mall jest odwrócenie tradycyjnego przepływu pracy. Zamiast zaczynać od komponentów, trzeba zacząć od treści.

„Kiedy mamy pełny design system, gdzie powinniśmy zacząć? Designerzy i programiści naturalnie zaczynają od designu i programowania. Pytam – w oparciu o co?”

Mall cytuje zasadę z Agile Manifesto: „Working software over comprehensive documentation”. W kontekście design systems oznacza to pisanie treści bezpośrednio w kodzie, zamiast dokumentów i wireframów.

Przepływ pracy content-first według Mall:

Otwórz edytor HTML i napisz treść w plain text
Zapisz i otwórz w przeglądarce – zobacz treść bez stylowania
Aplikuj komponenty stopniowo – nagłówki, karty, tabele
Testuj różne opcje wyświetlania – w sekundach, nie godzinach
Dodaj funkcjonalność i interakcje na podstawie treści

Mall podkreśla: „Jeśli możemy przepływać treść przez komponenty, to właśnie tam jest moc design systems.” Bez design systems nie da się szybko testować różnych sposobów prezentacji tej samej treści.

Ewolucja – od projektu do praktyki

Mall wyróżnia trzy etapy ewolucji design systems: Project → Product → Practice

Większość zespołów utyka w fazie „product”. Budują komponenty, myśląc że „jeśli to zbudujemy, to przyjdą”. Mall porównuje to do analogii z gotowaniem: „Możemy ugotować posiłek od zera albo mieć gotowe dania z mikrofalówki. Ma to sens – jest szybciej, ale ma też swoją cenę.”

Komponenty bez praktyki to jednak martwe narzędzia. Mall wskazuje na błędne myślenie: „Ludzie polegają na obiektywności systemu. Myślą, że jeśli kod jest dobrze napisany, pliki Figmy doskonałe, to ludzie będą przyciągnięci do tego.”

Irracjonalne powody przyjęcia

Mall zauważa, że ludzie wybierają produkty z irracjonalnych powodów. „To jak ludzie kupujący buty za 3000 dolarów albo torebkę. To irracjonalne, ale jest w tym coś, co sprawia, że czujesz się dobrze.”

Przyjęcie design systems działa podobnie – ludzie muszą poczuć ból, który system rozwiązuje, albo zobaczyć korzyść, która znacznie przewyższa koszty.

Peter Principle w design systems

Mall odnosi się do Peter Principle: „Przechodzisz z tworzenia plakatów, książek, stron internetowych do wspierania różnych typów ludzi, przypadków użycia, potrzeb, umiejętności.” To ogromny skok – od pracy indywidualnej do zarządzania systemami w skali.

„Prawie wszystko to nauka na błędach użytkowników” – zauważa Mall. Dlatego uważa, że jest lepszy sposób – uczenie się z błędów i sukcesów innych.

Dan Pink i motywacja 21. wieku

Mall cytuje pracę Dana Pinka o motywacji: „Autonomy, mastery, purpose” – to motywuje ludzi w nowoczesnej ekonomii opartej na wiedzy.

„Myślenie 'musimy robić więcej, bo skończyliśmy wcześniej’ to podejście z 20. wieku. Jesteśmy w 21. wieku” – podkreśla Mall. Prawdziwa motywacja w pracy umysłowej to nie więcej pracy, ale lepsze warunki do rozwoju.

Mall zaleca konkretne rytuały piątkowe:

Pisanie blog postów o nowych komponentach
Wysyłanie wiadomości w Slack
Planowanie postów w social media
Aktualizacja dokumentacji
Wysyłanie newsletterów do zespołów
Organizacja prezentacji i demo

Praktyka wymaga nowych nawyków, a nowe nawyki są trudne.

Konwergencja technologii

Mall zwraca uwagę na konwergencję design systems z headless CMS, microservices i micro front-endami. „Teraz jest dobry czas na design systems, bo mamy wszystkie rzeczy, które są potrzebne do pełnego wykorzystania.”

Kluczowe jest mapowanie całego ekosystemu: „Musimy zmapować nie tylko design system, ale wszystko inne – jakie mamy API, jak to działa z naszym CMS, CRM, DAM.” Design system sam w sobie to puste narzędzie.

Prawdziwy Agile kontra pseudo-Agile

Mall wskazuje na ironię w sposobie, w jaki zespoły rozumieją Agile. „Większość zespołów mówi, że są agile, ale tak naprawdę nie są.”

Zespoły robią model kaskadowy (waterfall) w treściach, architekturze informacji i projektowaniu. Dopiero w programowaniu stają się agile – dzielą pracę na dwutygodniowe sprinty. „To nie jest prawdziwy Agile.”

Prawdziwy Agile oznacza, że „rzeki mogą łączyć się w każdym punkcie”. Czasem treść pojawia się na początku, czasem na końcu projektu. Czasem insight przychodzi w ósmym tygodniu pracy. Kluczowe: nie zaczynać od nowa, tylko „wpłynąć” nową informację.

Praca umysłowa kontra praca przemysłowa

Mall tłumaczy różnicę między pracą przemysłową a współczesną pracą umysłową. „Robimy teraz knowledge work. Gdy robiliśmy industrial work, pakowanie większej ilości pracy miało sens” – lepsze narzędzia nie oznaczały większego obciążenia poznawczego.

„Jako ludzie mamy ograniczoną pojemność obciążenia poznawczego” – wyjaśnia Mall. Nasze mózgi po prostu nie mają pojemności, żeby przeciążać się pracą.

Dlatego stosowanie przemysłowego podejścia do pracy umysłowej nie działa. Nawet gdy wynajdujemy bardziej efektywne narzędzia i lepsze systemy, możemy zrobić coś innego z korzyściami – zamiast pakować więcej pracy, dać sobie więcej odpoczynku.

AI w design systems

Mall widzi AI jako przyspieszenie tego, do czego design systems już zmierzały – automatyzacji mniejszych, nudnych, najczęściej używanych elementów.

„To jest dokładnie to, czego chcieliśmy od design systems. Nagle zostało to na nas zrzucone w ostatnim roku, więc mogliśmy być trochę nieprzygotowani.”

Jednocześnie rozumie obawy: „Ludzie ciężko pracowali tygodniami nad komponentem, a teraz mogę to dostać w sekundach od bota.” Mall wierzy, że znajdziemy równowagę między automatyzacją a zachowaniem kontroli nad procesem.

Praktyczne porady

Mall kończy praktyczną radą: „Ścieżka prawie zawsze będzie nieoczekiwana, więc tego się spodziewajcie.”

Używa metafory podróży: „Kiedy idziecie do celu, czasem musicie zrobić objazd. Większość zespołów uważa to za porażkę w pracy nad design systems.” Czasem zablokowana autostrada oznacza piękną trasę krajobrazową.

„Bądźcie bardziej zaradni w tym, jak to robicie. Zróbcie objazd, jedźcie malowniczą trasą, zatrzymajcie się na postój” – radzi Mall. Elastyczność w implementacji nie oznacza rezygnacji z celu.

Checklista: Jak uniknąć design system ghost town

Diagnostyka – czy twój system to ghost town?

Komponenty są dobrze zbudowane, ale zespoły ich nie używają
Brak regularnej komunikacji o systemie
Tylko twórcy systemu go rozwijają
Brak feedbacku od użytkowników
System nie ewoluuje z potrzebami organizacji

Piloting – zanim zbudujesz komponenty

Współpracuj z zespołami PRZED budową – nie buduj, potem każ używać
Zbadaj rzeczywiste potrzeby i problemy użytkowników
Testuj rozwiązania z małą grupą przed skalowaniem
Iteruj na podstawie feedbacku z pilotu
Dopiero po sukcesie pilotu buduj finalne komponenty

Budowanie praktyki (rób to regularnie)

Piątkowe rytuały: wyznacz jeden dzień w tygodniu na design system
Wysyłaj newsletter o nowych komponentach
Pisz w Slack o update’ach
Organizuj prezentacje i demo
Aktualizuj dokumentację
Planuj posty w social media (jeśli public)

Przepływ pracy content-first

Zacznij od treści w plain text
Otwórz w przeglądarce bez stylowania
Dopiero potem aplikuj komponenty
Testuj różne opcje wyświetlania
Dodaj funkcjonalność na bazie treści

Mapowanie ekosystemu

Zmapuj dostępne API
Sprawdź integrację z CMS
Oceń współpracę z CRM
Uwzględnij DAM w systemie
Zaplanuj microservices
Przemyśl micro front-endy

Kulturowa integracja

Traktuj jako „humble work”, nie „noble project”
Szkolenie zespołów z używania systemu
Zbieranie feedbacku od użytkowników
Regularne spotkania z zespołami
Dokumentowanie sukcesów i porażek
Akceptacja „objazdu” w implementacji

Ewolucja: project → product → practice

Project: zbuduj podstawowe komponenty
Product: stwórz dokumentację i wersjonowanie
Practice: zintegruj z kulturą organizacyjną
Ciągła ewangelizacja systemu
Regularne rytuały komunikacyjne
Długoterminowe planowanie rozwoju

Kluczowy insight

Paradoks pierwszego komponentu

Standardowo myślimy: Budujemy najlepsze komponenty, dokumentujemy je, a potem przekonujemy zespoły do używania.

W praktyce okazuje się, że: Musisz najpierw współpracować z zespołami, zrozumieć ich ból, a dopiero potem budować komponenty, które ten ból rozwiązują.

Dlaczego to jest istotne: Przyjęcie nie zależy od jakości technicznej, ale od tego, czy ludzie czują potrzebę rozwiązania konkretnego problemu. Najlepsze komponenty świata nie będą używane, jeśli nie rozwiązują prawdziwych problemów zespołów.

Test na jutro: Następnym razem gdy planujesz nowy komponent, zamiast od razu go projektować, spróbuj najpierw porozmawiać z 3-5 osobami z zespołów, które będą go używać, i sprawdź czy faktycznie mają problem, który chcesz rozwiązać.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je w podcaście „Content Strategy Insights”, odcinek 169: https://www.youtube.com/watch?v=fxyQV8zKF4Q&t=22s