Poniższy artykuł to notatki z prezentacji Sarrah Vesselov na temat budowania systemu designu Lattice w firmie Honeycomb. Wszystkie obserwacje, wnioski i przemyślenia pochodzą od prezenterki i są oparte na jej doświadczeniach zawodowych.

TL;DR

Systemy designu wymagają dedykowanego zaangażowania – próby robienia „przy okazji” prowadzą do porażki
„Małe potworki” organizacyjne mogą zabić najlepiej zaplanowane projekty (przestarzały kod, niekonsystencje, odpriorytyzowanie)
Fałszywy optymizm w kierownictwie szkodzi bardziej niż szczera komunikacja o problemach
Rozbieżność między VP Product a VP Engineering może torpedować projekty przez miesiące
Zero energii bez wsparcia – lepiej zatrzymać projekt niż spalić zespół
Czasami najbardziej strategicznym ruchem jest świadome wstrzymanie projektu
Szczera komunikacja o problemach jest absolutnie kluczowa dla sukcesu

Gdy organizacja dorasta i potrzebuje spójności

Honeycomb znajdowało się w kluczowym momencie wzrostu. Baza klientów systematycznie rosła, co z kolei generowało zapotrzebowania na większą dojrzałość produktu. Zespoły sprzedaży i marketingu potrzebowały więcej profesjonalizmu w rezultatach dostarczanych przez produkty.

Vesselov zidentyfikowała dwie główne potrzeby organizacji: szybkość realizacji oraz spójność wizualną. W przestrzeni observability konkurencja dynamicznie rosła, dlatego firma musiała podnieść poprzeczkę jakościową.

Co ciekawe, uzyskanie poparcia kierownictwa okazało się zaskakująco proste. Zespół szybko zrozumiał potencjalne korzyści płynące z systemu designu. Wszyscy byli gotowi do współpracy.

Wczesne sukcesy projektu Lattice

Zespół opracował jasny i logiczny plan działania:

Visual rebrand (konieczny refresh przestarzałego brandu)
Audyt istniejących rozwiązań designerskich
Stworzenie biblioteki Figma umożliwiającej współpracę zespołu
Ustalenie foundations w Storybook
Systematyczny rollout aktualizacji oraz ulepszeń w interfejsie użytkownika

Vesselov szczególnie podkreśla sukces rebrandingu wizualnego. Wprowadzono żywsze kolory, poprawiono typografię oraz vertical rhythm i spacing. Wcześniej zespół korzystał z tego, co prezenterka nazywa „sztuką deweloperską” – rozwiązań tworzonych przez inżynierów bez udziału designerów.

Istniał wyraźny dysonans między marketingiem a produktem. Jak obrazowo opisuje Vesselov: „Wchodziłeś na stronę marketingową i myślałeś 'wow, fajna firma’, a potem logowałeś się do produktu, który przypominał arkusz Excela.”

Proces tworzenia dedykowanej strony w Zero Height zajął zaledwie jeden dzień. To, co wcześniej wymagało miesięcy współpracy z programistami, udało się zrealizować w kilka godzin.

Pierwsze implementacje przyniosły natychmiastowe i widoczne rezultaty. Typography oraz kolory rozprzestrzeniły się przez wszystkie komponenty interfejsu. Szczególnie istotna okazała się poprawa spacing, która umożliwiła prezentację znacznie większej ilości informacji na ekranie.

Zespół zaprezentował osiągnięcia podczas demo day w ramach spotkania all hands. Reakcje były bardzo pozytywne.

Pierwsze „potworki” – ukryte problemy techniczne

Vesselov wprowadza barwną metaforę „małych potworków” – pozornie drobnych problemów, które mogą zniszczyć cały projekt.

🔴 Pierwszy potworek: Przestarzały kod Implementacja Storybook była znacznie przestarzała. Brakowało aktualnej dokumentacji oraz najnowszych funkcjonalności. W rezultacie zespół potrzebował inżynierów do naprawy infrastruktury, co oznaczało kolejne opóźnienia.

🔴 Drugi potworek: Chaos w implementacjach Okazało się, że firma nie posiadała prawdziwych, zunifikowanych komponentów. Wszędzie można było znaleźć różne implementacje – hex, rgb, design tokens. Każda zmiana wymagała żmudnego przeszukiwania całej bazy kodu.

W tym momencie stało się jasne, że projekt wymaga znacznie szerszego audytu z perspektywy inżynieryjnej. Mimo że audyt designerski został już przeprowadzony, zespół nie wiedział, jak strukturować kod, aby był skalowalny i łatwy w utrzymaniu.

Kluczowy problem: brak dedykowanych zasobów

Vesselov przedstawia timeline swojej pracy w firmie. Rozpoczęła jako jedyna osoba w zespole designu w styczniu 2020 roku. Mimo pandemii Honeycomb wierzył w wizję i umożliwił budowanie zespołu.

Lattice był jedynym projektem w obszarze design ops. Pozostałe inicjatywy dotyczyły visual design oraz product design.

Projekt umarł w lipcu 2021 roku. Głównym powodem był brak odpowiedniego doświadczenia front-end w zespole inżynieryjnym. Firma zatrudniała świetnych full-stack engineers, jednak nie posiadała specjalistów front-end. Co więcej, istniejący zespół nie wykazywał szczególnego zainteresowania tego typu problemami.

Podjęto decyzję o zatrudnieniu front-end engineers. Proces rekrutacji oraz onboardingu wymaga jednak czasu. W rezultacie cały projekt Lattice został wstrzymany.

Vesselov opisuje tę sytuację jako „bardzo prawdziwą, ale niewidzialną ścianę” między zespołem a jakimkolwiek postępem. Mimo zatrudnienia front-end engineers, inicjatywy z mapy drogowej „wyssały cały tlen z pokoju”.

„Na cały kwartał po prostu odpuściliśmy” – szczerze przyznaje Vesselov.

Dlaczego robienie „przy okazji” nie działa

Po zatrudnieniu specjalistów front-end wszystkie inicjatywy z mapy drogowej zdominowały uwagę zespołu. Lattice pochodził sprzed miesięcy – stracił momentum, choć nie stracił formalnego wsparcia.

Z perspektywy biznesowej trudno argumentować za systemem designu. Organizacja ma konkretną mapę drogową do zrealizowania. Sprzedaż liczy na określone funkcjonalności, marketing obiecał klientom nowe możliwości.

Systemy designu nie generują natychmiastowej satysfakcji. Klienci nie mówią „wow, świetny nowy komponent!” – przeciwnie, pytają „gdzie ta funkcja, na którą czekam od sześciu miesięcy?”

Zespół zdecydował się na alternatywne podejście: tworzenie komponentów w ramach pracy nad funkcjonalnościami. Koncepcja „two for one” wydawała się atrakcyjna.

Vesselov przyznaje, że nie była optymistyczna. Miała intuicyjne przeczucie, że „potworki” powrócą.

Powrót potworków: odpriorytyzowanie i fałszywa nadzieja

🔴 Trzeci potworek: Systematyczne odpriorytyzowanie Pod koniec projektów czas zawsze jest ograniczony. Praca nad komponentami nie ma natychmiastowego wpływu na doświadczenie użytkownika, więc zostaje odłożona. Fraza „będziemy iterować później” stała się mantą, jednak „później” nigdy nie nadchodziło.

🔴 Czwarty potworek: Brak przestrzeni na współpracę Designer pracował nad trzema projektami jednocześnie, inżynier nad dwoma. Nie było fizycznej możliwości prowadzenia pogłębionych rozmów o systemach designu. Zabrakło miejsca na strategiczne dyskusje o skalowalności rozwiązań.

🔴 Piąty potworek: Fałszywy optymizm Według Vesselov, najgroźniejszy ze wszystkich. Kierownictwo żyło w przekonaniu, że projekt się rozwija. „Zrobiliśmy formularze!” – tak, ale jeden formularz, wykonany na zamówienie, bez systematycznego rollout. To była jedynie iluzja postępu.

Zespół osiągnął impas. Z jednej strony potrzebowali Lattice do realizacji celów biznesowych. Z drugiej nie mogli zatrzymać realizacji mapy drogowej. Jednocześnie nie było możliwości robienia postępów bez dedykowanego zaangażowania zasobów.

✅ Czy Twój design system jest gotowy na sukces?

Sprawdź czy masz:

Pełne zaangażowanie: Świadome poparcie liderów, którzy rozumieją że to długoterminowa inwestycja, a nie projekt na jeden kwartał
Dedykowane zasoby: Zespół (lub choćby jedną osobę), którego głównym zadaniem jest praca nad systemem, a nie robienie tego „przy okazji”
Odpowiednie kompetencje: Inżynierów z doświadczeniem w budowaniu skalowalnych i łatwych w utrzymaniu systemów front-end
Audyt długu technicznego: Zidentyfikowany istniejący dług techniczny, który może spowolnić lub zablokować prace
Realistyczne metryki: Umiejętność odróżnienia tworzenia jednorazowych rozwiązań od budowania prawdziwych, reużywalnych komponentów
Plan komunikacji: Strategię regularnego informowania o postępach, a co ważniejsze – o problemach i blokerach

Przełomowa rozmowa z coachem kariery

Vesselov przeprowadziła rozmowę z liderami R&D. Nie było to dyskusja o wartości projektu – wszyscy rozumieli jego znaczenie. To była raczej „rozmowa jak na pogrzebie”, gdzie uczestnicy ze smutkiem stwierdzili, że mimo wiedzy o wadze projektu, nie można go zrealizować w obecnych okolicznościach.

Vesselov czuła się jak osobista porażka. Podjęła kolejną próbę – przekształciła Lattice w OKR. Zaplanowała cotygodniowe spotkania, ograniczyła scope do minimum – koncentrując się tylko na bannerach. Mimo to inicjatywa nie przyniosła rezultatów.

Zwróciła się do swojego career coacha. Ta rozmowa okazała się przełomowym momentem – uświadomiła sobie, że „komunikowała się z nimi, ale ich nie słuchała”. VP Product był zadowolony ze stopniowego postępu. VP Engineering był natomiast zdezorientowany – był przekonany, że projekt wymaga dedykowanego podejścia.

Coach zadał kluczowe pytanie: „Co by się stało, gdybyś powiedziała – Lattice umarł, rezygnuję z tego projektu?”

Vesselov odpowiedziała: „Czułabym się jak porażka.”

„Dlaczego to miałaby być Twoja porażka?” – zapytał coach.

Vesselov nie potrafiła odpowiedzieć na to pytanie.

Jako liderzy często przyjmujemy na siebie zbyt dużą odpowiedzialność. Nie jesteśmy superbohaterami. Vesselov przyznaje, że mimo dobrych intencji, świadczyła zespołowi niedźwiedzią przysługę.

Prezenterka uświadomiła sobie paradoks sytuacji: „To był absolutnie właściwy czas na design system, ale jednocześnie zupełnie niewłaściwy czas”.

Podkreśla istotny punkt dotyczący hierarchii lojalności: jej „pierwszym zespołem” są VP-owie – z nimi powinna uzgadniać strategię. Zespół, którym bezpośrednio zarządza, to również jej home team, ale priorytetem jest zgodność z kierownictwem wyższego szczebla.

Rozwiązanie: szczerość jako strategia

Vesselov powróciła do VP Engineering z prośbą: „Chcę usłyszeć wszystko, co czujesz na temat Lattice. Po prostu będę słuchać.”

Następnie udała się do VP Product: „Nie mogę tego dłużej robić.” Szczegółowo wyjaśniła swoje powody.

VP Product zrozumiał sytuację: „To ma sens, szanuję tę decyzję. Musimy poważnie przedyskutować dodanie tego do mapy drogowej.”

Lattice nie umarł definitywnie. Od 2023 roku ma stać się dedykowanym projektem – Vesselov nazywa go „głazem”, dużym przedsięwzięciem z pełnym zespołem oraz miernikami sukcesu.

Trzy kluczowe wnioski dla liderów

Vesselov formułuje trzy główne lekcje z całego doświadczenia:

Komunikuj zarówno dobre, jak i złe wiadomości. Jako liderzy naturalnie dążymy do pozytywnego nastawienia, jednak szczera komunikacja o problemach jest kluczowa dla sukcesu. Podtrzymywanie fałszywej nadziei nie służy projektowi.

Nie inwestuj energii w system designu bez rzeczywistego zaangażowania organizacji. Prowadzi to do wypalenia zawodowego. To również zły przykład przywództwa, który wysyła mieszane sygnały do zespołu.

Zachowaj otwartość i elastyczność. Istnieje wiele ścieżek prowadzących do celu. Gdy jedna się zamyka, należy aktywnie szukać alternatyw.

Vesselov konkluduje: zawsze pojawią się „potworki” na drodze do sukcesu. To sposób radzenia sobie z nimi decyduje o różnicy między sukcesem a porażką – zarówno dla lidera, jak i zespołu.

Można pracować dla potworków lub sprawić, by potworki pracowały na Twoją korzyść.

Kluczowy insight

Aby ruszyć, musisz stanąć

Standardowo myślimy: Że gdy ważny projekt traci impet, należy go kontynuować za wszelką cenę, realizując choćby najmniejsze zadania, aby utrzymać pozory postępu.

W praktyce okazuje się, że: Takie „podtrzymywanie przy życiu” tworzy iluzję postępu i pogłębia chaos. Najskuteczniejszym działaniem jest świadome, publiczne zatrzymanie prac, co zmusza liderów do podjęcia jednoznacznej decyzji o prawdziwym priorytecie i dedykacji zasobów.

Dlaczego to jest istotne: Taki ruch zamienia powolną, frustrującą agonię projektu w jednoznaczny wybór: albo angażujemy się w pełni, albo świadomie rezygnujemy. Oszczędza to miesiące zmarnowanej energii i zasobów.

Test na jutro: Następnym razem gdy utkniesz w projekcie, który nie ma wystarczających zasobów, zamiast szukać kolejnego małego zadania do zrobienia „przy okazji”, spróbuj napisać do interesariuszy e-mail o tytule „Pauza w projekcie X – potrzebna decyzja strategiczna” i sprawdź, jak szybko znajdzie się czas na rozmowę o realnych zasobach.

Ten wpis zawiera notatki z prezentacji Sarrah Vesselov pt. „Building design systems that work for your whole Organisation”. Oryginalne nagranie dostępne jest tutaj: https://www.youtube.com/watch?v=2ljl0aUdcpg

Tag: Case Study

Dlaczego system designu w Honeycomb prawie umarł – lekcje od Sarrah Vesselov #EN300