B2B: System projektowy Syndigo - ujednolicona biblioteka komponentów i pipeline design-to-code
O projekcie
Przegląd projektu
- Rola: Senior Manager, UX Design w Syndigo — od listopada 2023 do teraz (ponad 10 lat doświadczenia w UX)
- Rozwiązanie: Jeden, skonsolidowany, połączony z kodem system projektowy obejmujący cały pakiet produktów Syndigo …. zastępujący rozproszone, powielone biblioteki komponentów jednym zarządzanym źródłem prawdy, podłączonym bezpośrednio do Storybook, GitHub i firmowych narzędzi do prototypowania z AI.
- Cel: Dać projektantom, inżynierom front-end i menedżerom produktu jeden spójny system, na którym budują, eliminując rozjazd, zamykając lukę między projektem a kodem i pozwalając całej organizacji działać szybciej bez utraty spójności czy dostępności. Dołączyłem do Syndigo … platformy danych produktowych B2B obejmującej produkty MDM, PXM i syndykacji … jako Senior Manager UX Design. Moja odpowiedzialność była trojaka:
Prowadzenie projektowania produktu od początku do końca w kluczowych produktach, w tym w platformie Nutrition Analysis i Syndication Tracker , przy jednoczesnym nadzorze nad projektantem pracującym przy nich razem ze mną.
Przejęcie rozproszonego, niezarządzanego systemu projektowego i przebudowanie go w jedno, spójne, połączone z kodem źródło prawdy.
Zarządzanie i rozwój zespołu 8+ projektantów produktu, z raportowaniem do VP of Design oraz współpracą z Director of Design i inżynierią front-end.
Proces projektowy
Przebudowę przeprowadziłem w wyraźnych etapach, każdy oparty na audycie.
- Audyt: zinwentaryzowałem każdy komponent we wszystkich produktach, zestawiłem Figmę z produkcją i oznaczyłem każdy duplikat oraz niespójność.
- Konsolidacja: sprowadziłem każdy zestaw duplikatów do jednego kanonicznego komponentu, opisałem każdy jego anatomią, wariantami i historią wersji oraz wprowadziłem przejrzysty przepływ pracy — pomysł, w toku, ukończone — z ticketami dołączonymi do ramek projektowych.
- Code Connect i Storybook: dla wszystkich 70+ komponentów napisałem pliki Code Connect i kod komponentów oraz skonfigurowałem Storybook, aby pokazywał projekt i żywą, oprogramowaną formę obok siebie.
- Integracja z GitHub: przy braku przedstawiciela UX w repozytorium inżynieria przyznała mi dostęp, a ja commitowałem pliki komponentów i Code Connect bezpośrednio do GitHub, zamykając pętlę design-to-code.
- Prototypowanie z AI: jako pierwszy w firmie użyłem Figma MCP, aby zamieniać projekty w oprogramowane, klikalne prototypy do testów przed developmentem, a następnie ograniczyłem Lovable i Claude Design do komponentów systemu, tak aby zespoły mogły generować wyłącznie prace zgodne z systemem.
- Dostępność: zbudowałem i zweryfikowałem każdy komponent tak, aby spełniał standardy WCAG AAA.
Dostępność
System zbudowano tak, aby spełniał standardy WCAG AAA. Komponenty zaprojektowano z myślą o czytnikach ekranu — z semantyczną strukturą, rolami ARIA i czytelnymi etykietami — i przetestowano bezpośrednio z oprogramowaniem czytającym ekran. Kolor obsłużono pod kątem wielu form daltonizmu, tak aby żadna informacja nigdy nie opierała się wyłącznie na kolorze. Zgodność sprawdzano zautomatyzowanymi narzędziami dostępności i ujęto w spisanych wytycznych, dzięki czemu każdy zespół mógł budować i współtworzyć system w sposób dostępny.
Wskaźniki wpływu
70+ komponentów skonsolidowanych w jedno, połączone z kodem źródło prawdy.
Pierwszy w Syndigo pipeline od projektu do inżynierii, weryfikujący projekty oprogramowanymi prototypami przed budową.
Ogólnofirmowe prototypowanie zgodne z systemem, przyjęte w zespołach produktowych i projektowych dzięki Lovable i Claude Design.
Skrócony czas cyklu od projektu do developmentu dzięki spójnym, połączonym z kodem komponentom.
Kontekst i sformułowanie problemu
System projektowy nie miał struktury i praktycznie żadnego zarządzania. Ten sam komponent często istniał w kilku niespójnych wersjach w różnych produktach, a nic nie łączyło projektu z wdrożonym kodem: żadnego Storybook, żadnych połączonych z kodem komponentów i żadnej obecności UX w GitHub.
Efektem był rozjazd. Projektanci, inżynierowie i menedżerowie produktu inaczej interpretowali system, co spowalniało dostarczanie i zmuszało inżynierów do odbudowywania UI z niespójnych specyfikacji.
Analiza interesariuszy
- Inżynierowie front-end: potrzebowali komponentów, które odpowiadały zamysłowi projektowemu i trafiały prosto do produkcji, zamiast odbudowywania ich z niespójnych specyfikacji.
- Projektanci produktu: mój zespół potrzebował jednego zarządzanego zestawu komponentów, aby móc skupić się na rozwiązywaniu problemów, a nie na odtwarzaniu UI.
- Menedżerowie produktu: potrzebowali szybko prototypować i testować pomysły, nie oddalając się od rzeczywistego produktu.
Audyt systemu
Zanim cokolwiek zmieniłem, zbadałem, jak system był faktycznie używany, aby przebudowa opierała się na dowodach.
- Inwentaryzacja komponentów: skatalogowałem każdy używany komponent i zidentyfikowałem duplikaty.
- Mapowanie Figma-do-produkcji: porównałem biblioteki projektowe z wdrożonym UI, aby zlokalizować rozjazd.
- Wywiady z zespołem: rozmawiałem z projektantami i inżynierami o tym, gdzie system pomagał, a gdzie go obchodzili.
- Wtyczka UI Relay: zbudowałem własną wtyczkę do Figmy do prowadzenia systemu — mapowanie komponentów do kodu, śledzenie pokrycia i kondycji kodu, generowanie i synchronizacja kodu komponentów, zarządzanie tokenami i szablonami oraz oznaczanie luk do naprawienia — zamieniając zarządzanie i design-to-code w ciągły przepływ pracy, a nie jednorazowe porządki.
Wyzwania i rozwiązania
Kluczowym wyzwaniem było brakujące ogniwo między projektem a kodem. Wobec braku obecności UX w repozytorium zapewniłem sobie dostęp do GitHub i sam przejąłem odpowiedzialność za pliki Code Connect i komponentów, tak aby decyzje projektowe docierały do produkcji wiernie, zamiast być reinterpretowane.
Fragmentacja była drugim wyzwaniem. Zamiast ręcznie pilnować spójności, skonsolidowałem duplikaty w kanoniczne komponenty i zbudowałem wtyczkę UI Relay, aby powstrzymać ponowny rozjazd systemu.
Adopcja była trzecim. Podłączając system do narzędzi, których zespoły i tak już chciały — oprogramowanych prototypów, Lovable i Claude Design — sprawiłem, że budowanie zgodnie z systemem stało się drogą najmniejszego oporu.
