Poniższy artykuł stanowi notatki z wywiadu przeprowadzonego w podcaście „Thunder Nerds” z Sarah Vesselov i Taurie Davis, autorkami książki „Building Design Systems”. Wszystkie prezentowane przemyślenia, obserwacje i wnioski pochodzą od rozmówczyń.

TL;DR

Design system różni się od style guide – to kompleksowy język komunikacji, nie tylko wizualia
Wartość trzeba komunikować różnie – zwrot z inwestycji dla biznesu, efektywność dla deweloperów
Leksykon i gramatyka – kluczowe koncepcje autorstwa Davis do zrozumienia design systemów
Książka skierowana do całych zespołów – nie tylko designerzy, lecz również project managerowie i deweloperzy
GitLab sprawdził się przy pisaniu – version control okazał się lepszy niż tradycyjne narzędzia wydawnicze
Implementacja pozostaje trudna – nawet eksperci napotykają wyzwania w praktyce
Sprzedawanie wymaga strategii – zdobycie poparcia organizacji to osobny proces

Sarah Vesselov i Taurie Davis poznały się podczas pracy w GitLab, gdzie Davis pełniła funkcję interim UX managerki. Vesselov, po objęciu stanowiska managerki, jako pierwsze zadała pytanie: „dlaczego ona nie jest managerką?”. Ich współpraca nad design systemem w firmie stała się później podstawą książki „Building Design Systems”.

Vesselov wcześniej zdobyła National Scholastic Art and Writing Awards za fotografię. Do web developmentu trafiła przypadkowo – podczas tworzenia portfolio dla animacji odkryła, że programowanie daje natychmiastową gratyfikację w przeciwieństwie do animacji, gdzie trzeba „kliknąć, renderować i czekać”. Davis z kolei studiowała fotografię analogową, jednak przeszła na communication design ze względów praktycznych.

Czym naprawdę jest design system

Autorki podkreślają fundamentalną różnicę między trzema często mylonymi pojęciami:

Style guide – zawiera elementy wizualne
Component library – zbiór komponentów aplikacji
Design system – kompleksowy język komunikacji o designie

Według Davis: „Design system to język komunikacji o designie w organizacji. To nie tylko wizualia czy komponenty – to sposób komunikowania się o designie i działania designu dla konkretnej bazy użytkowników.”

Rozróżnienie to ma kluczowe znaczenie dla zrozumienia, dlaczego design systemy przynoszą wartość całej organizacji, nie wyłącznie designerom.

Leksykon i gramatyka jako fundament

Davis opracowała koncepcję leksykonu i gramatyki design systemów, którą Vesselov uznaje za najważniejszy element ich książki. Przełom nastąpił dzięki feedbackowi od recenzenta technicznego, który zadał pytania, na które trudno było odpowiedzieć prostymi słowami.

Vesselov wspomina: „Na początku rozmawialiśmy o design systemach jak o języku designu – o łączeniu mniejszych elementów w większe. Jednak nie układało się to w spójną całość.”

Gdy autorki otrzymały trudne pytania od recenzenta, Davis „rozłożyła to na części” i przepracowała całe podejście. Wprowadzenie koncepcji leksykonu i gramatyki sprawiło, że sposób komunikowania o design systemach stał się znacznie jaśniejszy – było to zupełnie nowe spojrzenie na problem, którego wcześniej nie przedstawiano w literaturze.

Komunikowanie wartości różnym zespołom

Sprzedawanie design systemów w organizacji wymaga dostosowania przekazu do konkretnych odbiorców. Vesselov wskazuje różne strategie:

Dla stakeholderów biznesowych – zwrot z inwestycji i metryki finansowe
Dla zespołów produktowych – lepsza adopcja przez użytkowników
Dla deweloperów – oszczędności czasu i zwiększona efektywność
Dla designerów – spójność i możliwość skalowania designu

Jak wyjaśnia Vesselov: „Jeśli rozmawiasz ze stakeholderami nastawionymi na liczby, musisz mówić o zwrocie z inwestycji.”

To podejście można zastosować nie tylko do design systemów, lecz do całej pracy designowej i UX. Nawet front-end developerzy mogą wykorzystać te techniki podczas komunikowania wartości rozwiązywania długu technicznego.

Książka dla całych zespołów

Autorki świadomie napisały publikację, która nie jest przeznaczona wyłącznie dla designerów. Davis wyjaśnia: „Design systemy są dla wszystkich. To może być inżynier, project manager, designer. Cała idea polega na tym, że design systemy służą każdemu.”

Zamiast skupiać się na konkretnych implementacjach technicznych, które szybko się dezaktualizują, autorki pozostały na wysokim poziomie abstrakcji. Vesselov dodaje: „Celem było opisanie tego, czym design system jest i czym nie jest, jakie kroki podejmować przy implementacji oraz czyje poparcie potrzebujesz w organizacji.”

Inżynierowie zyskują spójne komponenty i efektywniejszy development. Project managerowie lepiej planują zasoby i harmonogramy. Designerzy pracują bardziej konsekwentnie i mogą skalować swoje rozwiązania. Wszyscy członkowie zespołu odnoszą konkretne korzyści z dobrze zaprojektowanego design systemu.

Realistyczne oczekiwania wobec implementacji

Jednym z najważniejszych przesłań książki jest przygotowanie na trudności. Nawet posiadając wiedzę o design systemach, implementacja pozostaje wymagająca.

Davis podkreśla: „Cała sekcja studium przypadku pokazuje wszystkie problemy, na które natrafiliśmy. Mimo że mieliśmy wiedzę o design systemach i umieliśmy o nich mówić, nadal mieliśmy problemy ze sprzedaniem idei. To nie będzie łatwe przez cały czas.”

Kluczowe jest znalezienie osoby, która będzie „bykiem, który z tym pobiegnie” – kogoś, kto naprawdę uwierzy w design system i będzie go forsował w organizacji. Takie realistyczne podejście pomaga zespołom przygotować się na wyzwania i nie zniechęcać się pierwszymi przeszkodami.

Ciekawostką pozostaje timing książki – design systemy „eksplodowały” podczas jej pisania, a do czasu publikacji osiągnęły szczyt popularności. Autorki albo idealnie wybrały moment, albo same przyczyniły się do tego trendu.

GitLab jako narzędzie do pisania książki

Genesis książki był nietypowy – Vesselov często występowała publicznie i została approached przez wydawcę z propozycją napisania książki. Gdy zobaczyła w propozycji „co-author?”, pomyślała o Davis: „Nie chcę pisać swojej pierwszej książki sama”. Design system był oczywistym wyborem tematu, ponieważ to była dziedzina, w której czuły się najbardziej kompetentne.

Autorki wypracowały praktyczne podejście do współpracy nad tekstem. Davis opisuje: „To było jak nasza codzienna praca. Zamiast reviewować kod, reviewowaliśmy zdania.” Utworzyły repozytorium z plikami markdown, a następnie korzystały z pull requestów do komentowania zmian.

Największe problemy sprawiały narzędzia wydawcy oraz Google Docs. Autorki doświadczyły „okropnych konfliktów scalania” w Google Docs, gdzie rozwiązywanie konfliktów nie dawało oczekiwanych rezultatów. Google Docs ma również ograniczenia w liczbie rewizji, co dodatkowo komplikowało pracę.

Vesselov radzi: „Nie próbujcie używać tego, co oferują wydawcy, dopóki nie jesteście gotowi przekazać im materiału. Używajcie narzędzi, które znacie i które działają.”

Współpraca i różne style

Autorki przyznają, że reprezentowały różne style pisania – Vesselov bardziej konwersacyjny, Davis bardziej bezpośredni. Vesselov opisuje ich dynamikę: „Czułam, że naprawdę się uzupełniamy – ja jestem trochę zwariowana i szalona, Taurie jest bardziej stonowana.”

Ta różnorodność perspektyw wzmocniła końcowy efekt, choć wymagała dodatkowej pracy nad harmonizacją treści. Vesselov była odpowiedzialna za komunikację ze stakeholderami i rozpowszechnianie idei design systemów, podczas gdy Davis skupiała się na implementacji. Te uzupełniające się perspektywy sprawiły, że książka oferuje pełny obraz procesu – od strategii biznesowej po praktyczne wdrożenie.

Davis natychmiast wsparła nową menagerkę, kontynuując prowadzenie niektórych spotkań, aby dać Vesselov czas na aklimatyzację. Jak wspomina Vesselov: „Kto pomaga swojemu nowemu managerowi nauczyć się zarządzania? To była wyjątkowa sytuacja.”

Checklist implementacji design systemu

Na podstawie doświadczeń Vesselov i Davis można stworzyć praktyczną listę kontrolną:

Przed rozpoczęciem:

Zdefiniuj różnice – upewnij się, że zespół rozumie różnicę między style guide, component library i design system
Zidentyfikuj stakeholderów – określ, kto musi dać poparcie w organizacji
Przygotuj argumenty – dostosuj komunikację wartości do różnych grup (ROI dla biznesu, efektywność dla deweloperów)

Podczas implementacji:

Opracuj leksykon – stwórz wspólny język komunikacji o designie
Ustal gramatykę – określ reguły łączenia elementów systemu
Wybierz właściwe narzędzia – używaj tego, co zespół już zna i co działa
Dokumentuj proces – zapisuj decyzje i wyzwania dla przyszłych projektów

Przygotuj się na wyzwania:

Oczekuj oporów – nawet z dobrą wiedzą implementacja będzie trudna
Planuj iteracje – system będzie ewoluował wraz z potrzebami organizacji
Buduj wsparcie – znajdź sojuszników w różnych zespołach

Praktyczne zastosowanie

Książka „Building Design Systems” jest dostępna pod adresem buildingdesignsystems.design. Autorki regularnie prowadzą warsztaty i prezentacje, dzieląc się swoimi doświadczeniami z implementacji design systemów.

Vesselov obecnie pracuje nad Jenkins X, natomiast Davis kontynuuje pracę jako product designer. Obie pozostają aktywne w społeczności designerskiej i są otwarte na kontakt przez Twitter DM.

Kluczowy insight

Pytaj „dlaczego nie oni?”

Standardowo myślimy: Nowy manager przejmuje kontrolę, pokazuje swoją wartość i buduje autoritet przez implementację własnych pomysłów.

W praktyce okazuje się, że: Najlepsi liderzy zaczynają od pytania „dlaczego osoba z kompetencjami nie ma tej roli?”. Vesselov jako nowa managerka w GitLab nie próbowała udowodnić swojej wartości – zamiast tego pierwszym pytaniem było „dlaczego Davis nie jest managerką?”.

Dlaczego to jest istotne: Ta zmiana perspektywy z „co ja wnoszę” na „co przegapiliśmy” ujawnia ukryte talenty w zespole oraz buduje współpracę zamiast rywalizacji.

Test na jutro: Następnym razem gdy obejmujesz nową rolę lub dołączasz do zespołu, zamiast pokazywać co potrafisz, spróbuj zapytać „kto tutaj ma kompetencje, które nie są wykorzystane?” i sprawdź jak zmienia się dynamika współpracy.

Ten wpis stanowi część 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ć. Oryginalne źródło znajdziesz w podcaście „Thunder Nerds” – wywiad z Sarah Vesselov i Taurie Davis o książce „Building Design Systems„.

Tag: Taurie Davis

Design systemy to język całej organizacji – notatki z podcastu z Sarah Vesselov i Taurie Davis #EN302