Poniższe notatki pochodzą z webinaru DS Live prowadzonego przez TJ Pitre. Wszystkie przedstawione przemyślenia, obserwacje i wnioski to efekt pracy zespołu Pitre’a oraz jego doświadczeń w implementacji context-based design systems.

TL;DR

Context-based design systems wykorzystują AI i strukturalne metadane do eliminacji problemów komunikacyjnych między projektowaniem a kodowaniem
Cztery kluczowe narzędzia: FigmaLint (walidacja), FIGMA MCP (generowanie kodu), Story UI (układy), DS Audit (analiza jakości)
Koszty AI są zaskakująco niskie – miesięczne wydatki wynoszą zaledwie kilka dolarów, nawet przy intensywnym użytkowaniu
Ręczne przygotowanie jest kluczowe – Pitre zdecydowanie odradza rozpoczynanie projektów od zera z AI jako punktem wyjścia
Kontekst decyduje o jakości – im więcej metadanych, dokumentacji i opisów komponentów, tym lepsze rezultaty AI
Narzędzia działają z React, Vue, Angular i Web Components
Przepływ pracy eliminuje ponad 80% pracy manualnej w typowych procesach projektowanie-kod

Dlaczego tradycyjne systemy projektowania wymagają zmiany podejścia

Współczesne systemy projektowania, według obserwacji Pitre’a, borykają się z kilkoma fundamentalnymi problemami. Pierwszy z nich to niejednoznaczne wykorzystanie komponentów – często wynikające z braku specyfikacji lub niepełnych metadanych w Figmie.

Kolejnym wyzwaniem są przerwane przekazania między zespołami. Projekty często trafiają do programistów przed pełnym dopracowaniem, co zmusza ich do samodzielnego łatania luk lub powracania do projektantów z pytaniami.

Trzeci problem stanowi dryf komponentów między projektem a kodem końcowym. Komponenty ewoluują podczas przechodzenia przez różne zespoły, jednak rezultat często znacznie odbiega od pierwotnej wizji. W konsekwencji powstaje konieczność wykonywania dużych ilości manualnego, powtarzalnego kontrolowania jakości zarówno po stronie projektowania, jak i programowania.

Czym charakteryzują się context-based design systems

Pitre wyjaśnia, że context-based design systems opierają się na założeniu, iż komponenty powinny mieć jasno określony cel i zachowanie. Kluczowym elementem jest maksymalne wykorzystanie właściwości komponentów oraz sekcji metadanych w Figmie.

Zamiast skupiać się wyłącznie na estetyce, system przekazuje kontekst – dane o celu, logice i relacjach komponentu. Obejmuje to:

Opisy wariantów – nie tylko nazwa, ale wyjaśnienie co dany wariant robi i kiedy go używać
Metadane funkcjonalne – dane niewidoczne w Figmie, ale kluczowe dla programistów i AI (np. role ARIA)
Jasny cel i zachowanie – precyzyjne zdefiniowanie przeznaczenia komponentu

Szczególne znaczenie mają metadane, które kodują logikę i relacje między komponentami. Te informacje można następnie przekazać przez API lub FIGMA MCP do baz kodu, dzięki czemu AI rozumie nie tylko estetykę, ale również funkcjonalność komponentu.

System wprowadza również walidację od projektowania przez implementację. Podczas gdy programowanie zawsze posiadało systemy kontroli i równowagi, podejście context-based rozszerza to na całą organizację, tworząc spójny ekosystem kontroli jakości.

Ekosystem narzędzi – systematyczne podejście do automatyzacji

TJ Pitre prezentuje zestaw narzędzi wypracowanych przez jego zespół. Proces rozpoczyna się od kreatywnej fazy tworzenia komponentów – etapu, w który zespół Pitre’a celowo angażuje się w ograniczonym stopniu, ponieważ kreatywność wymaga swobody działania.

FigmaLint – „linter” dla Figmy

FigmaLint powstał przede wszystkim z potrzeb edukacyjnych, gdy zespół zauważył, że błędy w kodzie generowanym przez AI mają swoje źródło w niepoprawnie przygotowanych projektach. Wielu projektantów produktowych przechodzi do projektowania systemów bez doświadczenia w aspektach inżynierii projektowania – kluczowym elemencie tej dziedziny.

Narzędzie wykonuje szczegółową analizę wszystkich właściwości komponentów, sprawdza ocenę tokenów i przypisuje standardowy wynik kompletności. Najważniejszym elementem jest wynik gotowości MCP, który pozwala programistom pewnie korzystać z narzędzi downstream do konwersji komponentów na kod gotowy do produkcji.

Zespół Pitre’a dokonał istotnego odkrycia podczas pracy z tym narzędziem. Początkowo, gdy zauważali wartości zakodowane na stałe w CSS, podejrzewali ograniczenia technologii MCP. Okazało się jednak, że źródłem problemu były odłączone komponenty lub wartości zakodowane na stałe w projektach, które nie wykorzystywały właściwych tokenów.

FIGMA MCP – centrum przepływu pracy

FIGMA MCP działa najefektywniej przy przestrzeganiu określonej metodologii. Kluczem jest rozpoczynanie od najbardziej podstawowych komponentów – tych z najmniejszą liczbą zależności. Zespół Pitre’a systematycznie przechodzi przez przygotowany arkusz kalkulacyjny.

W miarę przechodzenia do bardziej złożonych struktur, agent rozpoznaje już utworzone komponenty i poprawnie ich używa. Pitre ostrzega jednak przed niewłaściwym wykorzystaniem – próbami odtwarzania całych interfejsów jak dashboardy czy gęste tabele. Takie podejście prowadzi do rozczarowujących rezultatów.

Iteracja ma kluczowe znaczenie – zespół musi nabrać wprawy w pracy z narzędziami MCP. Początkowo Pitre’a zespół po prostu wklejał kanoniczny link i sprawdzał rezultaty. Były one zaskakująco dobre, jednak brakowało w nich interakcji.

Z czasem odkryli, że poświęcenie większej ilości czasu na stronę Figmy przez dodawanie lepszych właściwości, opisów i opisów wariantów znacząco poprawiało wyniki AI, mimo że nie dostarczało dodatkowych informacji bezpośrednio do klienta w chmurze.

Story UI – tworzenie układów bez programisty

Story UI powstało z bardzo konkretnego problemu biznesowego w agencji. Klienci pytali o kompozyty wyższego poziomu – większe struktury komponentów, jednak wycena takich elementów stanowiła szarą strefę. Zespół nie wiedział, jak podejść do tego zagadnienia.

Pitre opisuje typowe scenariusze: gdy klient prosi o tablicę ogłoszeń, zespół może ją złożyć z dostępnych komponentów. Pojawiają się jednak dodatkowe pytania – czy można otrzymać tablicę z widocznymi filtrami, bez wyników lub z rozbudowaną paginacją.

Programiści z pewnością mogli to wykonać, jednak lepszym rozwiązaniem było wykorzystanie dostępnych komponentów do inteligentnego składania. Narzędzie posiada kontekstową świadomość wszystkich kodów i dokumentacji systemu projektowania, dzięki czemu potrafi inteligentnie łączyć interfejsy.

Pitre wspomina również o zabawnych odkryciach – ktoś poprosił o wygenerowanie strony w stylu Geocities, co zajęło około minuty, ale rezultat był trafny. To pokazuje potencjał tej technologii.

Dodatkową zaletą jest możliwość generowania inwentarza dla systemów z licznymi wariantami przycisków, alertów i banerów. Zamiast ręcznego tworzenia historii dla wszystkich kombinacji, można użyć prompta opisującego żądane warianty.

DS Audit – końcowa kontrola

DS Audit stanowi odpowiednik FigmaLint dla bazy kodu. Zanim inżynierowie produktowi przejmą komponenty, narzędzie sprawdza tokeny, zarządzanie, dokumentację, wydajność, dostępność i inne kategorie systemów projektowania.

Pitre przyznaje, że rezultaty mogą być niepokojące – narzędzie nie oszczędza w ocenie jakości systemu. Dostarcza jednak bardzo praktycznych wyników.

Plan działania dzieli odkrycia na poziomy – elementy wyższego rzędu, które prawdopodobnie powinny trafić na mapę drogową do rozłożenia na mniejsze części. Drobniejsze zadania są gotowe jako bilety z konkretnymi instrukcjami.

Analiza AI wykorzystuje asystenta systemu projektowania – narzędzie napędzające większość ich rozwiązań. Można z nim prowadzić dialog, pytając o najważniejsze problemy do rozwiązania.

System oferuje też opcje eksportu dla różnych ról: dokumentację, widok menedżera produktu ze śledzeniem postępów i metrykami prędkości, oraz eksport danych do potencjalnego wykorzystania przez inne AI w celu usprawnienia systemu projektowania.

Przepływ implementacji – praktyczny przewodnik z nowymi rolami

Pitre przedstawia proces adopcji w organizacji jako konkretne etapy do realizacji, zwracając jednocześnie uwagę na ewolucję ról w zespole:

Faza projektowania i walidacji

Stworzenie komponentów z pełnymi metadanymi, wariantami, stanami, tokenami
Uruchomienie FigmaLint i sprawdzenie wyniku gotowości MCP
Audyt systemu projektowania pod kątem kompletności przez Design Engineera – osobę łączącą wiedzę projektową z techniczną

Faza konwersji i nadzoru

Konfiguracja FIGMA MCP z niestandardowymi agentami i specyficznymi promptami
Cel: osiągnięcie ponad 80% dokładności w pierwszej iteracji
Walidacja przez Context Engineera – jego zadaniem nie jest pisanie kodu od zera, lecz zapewnienie poprawności generowanego kodu

Faza testowania i publikacji

Standardowe testowanie plus końcowa kontrola DS Audit
Podpisanie i aktualizacja wersji po walidacji

Faza układów i integracji

Wykorzystanie Story UI dla osób niebędących programistami
Import do inżynierii produktowej z logiką API

Praktyczne aspekty wdrożenia

Koszty AI – niższe niż oczekiwano

Pitre waha się przed określeniem miesięcznych kosztów jako „dziesiątki dolarów”. Zużycie tokenów okazuje się nieznaczne, mimo że FIGMA MCP generuje największe zużycie w całym przepływie pracy.

Kluczem są dobrze ustrukturyzowane prompty – pozwalają one maksymalizować efektywność pojedynczej iteracji zamiast ciągłego powracania do poprawek. FigmaLint, Story UI i Design Systems Assistant kosztują praktycznie nic.

Kompatybilność z frameworkami i modelami językowymi

Web Components stanowią wyzwanie – Story UI obecnie z nimi nie współpracuje, choć znajduje się to na pierwszym miejscu w mapie drogowej funkcji. Mimo to FIGMA MCP zaskakująco dobrze radzi sobie z Web Components. Pitre zauważa, że praca z nimi wymaga więcej zarządzania i dobrych przykładów pracy z Shadow DOM oraz właściwościami CSS.

React i Angular radzą sobie lepiej ze względu na popularność tych frameworków. AI prawdopodobnie lepiej sprawdza się z bardziej złożonymi i interaktywnymi strukturami niż z prostymi komponentami jak awatary czy banery.

Zespół używa głównie Claude, jednak testował też GPT-4 i obecnie eksperymentuje z GPT-5. Nawet z GPT-5 odkrywają, że Claude, szczególnie Opus 4.1, nadal sprawdza się lepiej.

Zaskakująco dobrze funkcjonuje też Gemini. Pitre podkreśla, że odchylenie od założenia „to nie działa, chyba że używasz modeli Claude” nie jest prawdziwe. Organizacje korzystające z Enterprise Gemini mogą śmiało go używać.

Dostępność i open source

Pitre podkreśla, że większość narzędzi jest dostępna jako open source. Zespół nie ogranicza dostępu do swoich rozwiązań:

FigmaLint dostępny w sklepie z wtyczkami
Story UI dostępny do pobrania i współtworzenia
Pozostałe narzędzia znajdują się w repozytoriach GitHub zespołu

Pitre zachęca do bezpośredniego kontaktu w przypadku zainteresowania indywidualną demonstracją lub skupienia się na konkretnym narzędziu.

Projekty od zera versus dojrzałe systemy

Na pytanie o rekomendację dla nowych systemów, Pitre jednoznacznie odpowiada, że nie rozpoczynałby od zera z wykorzystaniem AI w tej strukturze. Standardowe przygotowanie podstawy stanowi właściwe podejście.

Ręczne fundamenty pozostają kluczowe:

50-70 podstawowych komponentów jako podstawa z instalacją Storybook
Typowa konfiguracja tokenów z właściwymi wartościami
Połączenie systemu z marką firmy i typografią

Optymalizacja Figmy dla MCP wymaga:

Właściwości komponentów zgodnych z logiką programistyczną
Opisów dla każdego komponentu i wariantu (kluczowych dla zrozumienia AI)
Metadanych jak role ARIA (niewidocznych w interfejsie, ale potrzebnych dla AI)
Sprawdzenia, że wszystkie wartości używają właściwych tokenów

Konfiguracja dokumentacji obejmuje:

Katalog dokumentów w głównym katalogu z plikami markdown o najlepszych praktykach
Plik z preferencjami systemowymi
Ścieżki do tokenów, gdzie AI może znaleźć komponenty siostrzane
Wytyczne CSS i TypeScript

Jak podkreśla Pitre, nie należy pozwalać, aby AI stanowiło źródło systemu projektowania. Fundament przygotowany przez człowieka umożliwia późniejsze wprowadzenie celu i intencji do AI.

Kluczowe wnioski i wpływ na biznes

Context-based design systems, według Pitre’a, nie zastępują ludzi, ale pozwalają im efektywniej wykonywać swoje obowiązki. Celem automatyzacji jest zwiększenie efektywności specjalistów, a nie ich zastąpienie. Wszyscy będą nadal pracować nad tym, co robią najlepiej, jednak przepływy pracy ulegną zmianie ze względu na mniejsze zaangażowanie w czynności manualne.

Automatyzacja przejmuje powtarzalne, manualne zadania, dzięki czemu projektanci i programiści mogą skupić się na bardziej kreatywnych i złożonych problemach. Ich role ewoluują, ale nie znikają – powstają nowe specjalizacje jak Design Engineer czy Context Engineer.

Inżynieria projektowania jako kluczowa dyscyplina

Pitre wielokrotnie podkreśla znaczenie inżynierii projektowania w kontekście systemów projektowania. Stanowi ona most między światem projektowania a programowania, co ma kluczowe znaczenie dla sukcesu podejścia context-based.

Mierzalne usprawnienia

FIGMA MCP osiąga ponad 80% dokładności w pierwszej iteracji. Choć nie jest to stuprocentowa precyzja, znacznie redukuje pracę manualną. W kontekście agencyjnym rozwiązuje konkretne problemy biznesowe związane z wyceną niejasnego zakresu.

Proces uczenia i iteracja

Sukces wymaga nabierania wprawy w pracy z narzędziami MCP. Początkowo zespół Pitre’a po prostu wklejał kanoniczny link i sprawdzał rezultaty. Kluczowym odkryciem było to, że iteracja ma znaczenie, ale jeszcze ważniejsze okazało się poświęcanie czasu na stronę Figmy przez dodawanie lepszych właściwości i opisów.

Kontekst odgrywa najważniejszą rolę – im więcej dokumentacji, metadanych i opisów, tym lepsze rezultaty. Jak zauważa Pitre, te pozornie drobne elementy po stronie Figmy, bez dostarczania dodatkowych informacji AI, same w sobie pomagały AI zrozumieć sposób programowania komponentu.

Ostatecznym celem jest stworzenie jednorodnej grupy, w której wszyscy komunikują się ze sobą i są świadomi działań pozostałych członków – narzędzia AI pomagają zsynchronizować te małe luki w komunikacji między zespołami.

Praktyczne prompty z webinaru TJ Pitre

Podczas prezentacji Pitre pokazał konkretne prompty używane w różnych fazach pracy. Oto przykłady z uzasadnieniem zastosowania:

Story UI – tworzenie układów

Sekcje e-commerce:

Wygeneruj sekcję rekomendacji redakcji dla strony e-commerce specjalizującej się w sprzedaży okularów przeciwsłonecznych meta. Sekcja powinna zawierać tytuł sekcji, opis oraz kilka kart produktów z wezwaniem do działania.

Zastosowanie: Pozwala złożyć gotową, biznesową sekcję strony na podstawie istniejących komponentów, takich jak nagłówki czy karty produktów

Inwentarz komponentów:

Wygeneruj różne przyciski z ikonami i dodaj też kilka komponentów przełączników.

Zastosowanie: Szybkie sprawdzenie dostępnych wariantów komponentów w systemie

Pokaż mi wszystkie iteracje przycisków podstawowych, drugorzędnych i trzeciorzędnych z różną ikonografią w slotach przed i po tekście.

Zastosowanie: Zamiast ręcznego tworzenia dziesiątek przykładów w Storybook, AI generuje stronę ze wszystkimi możliwymi wariantami

Złożone układy:

Sklonuj stronę główną LinkedIn

Zastosowanie: Testowanie możliwości narzędzia z complex, dobrze znanymi interfejsami

Stwórz komentarz w stylu Reddit

Zastosowanie: Szybkie zbudowanie prototypu znanego wzorca interfejsu (komentarze wielopoziomowe, funkcje społecznościowe)

Obsługa zapytań biznesowych:

Can I get a job board with filters exposed? Could I get a job board with no results?

Zastosowanie: Zamiast angażować programistę, project manager może sam wygenerować potrzebne wersje layoutu

DS Audit – analiza systemu

Priorytetyzacja problemów:

Jakie są trzy najważniejsze problemy, które powinniśmy rozwiązać?

Zastosowanie: Po uruchomieniu DS Audit, określenie priorytetów w mapie drogowej

Ocena ważności:

Co oznaczają te dane i jak są ważne? Czy to krytyczny problem wymagający natychmiastowego rozwiązania, czy drobna kwestia, z którą można poczekać?

Zastosowanie: Zrozumienie wyników audytu, rozdzielenie krytycznych problemów od nice-to-have

FIGMA MCP – konfiguracja kontekstu

Pitre wspomina o specyficznych promptach dla FIGMA MCP, podając wytyczne dotyczące przekazywania kontekstu:

Ścieżka do katalogu tokenów
Katalog, gdzie AI znajdzie komponenty siostrzane
Wytyczne dotyczące konwencji CSS i TypeScript
Odniesienia do istniejących wzorców komponentów

Kluczowy insight

AI nie jest problemem

Standardowo myślimy: Gdy AI generuje słaby kod lub nie rozpoznaje komponentów, problem leży w technologii – „AI jest jeszcze zbyt niedojrzałe” lub „te narzędzia po prostu nie działają jak trzeba”.

W praktyce okazuje się, że: AI najczęściej jest tylko lustrem, które wiernie odbija jakość i spójność pliku w Figmie. Problemy w kodzie są symptomem, a ich prawdziwa przyczyna leży w nieuporządkowanym projekcie. Jak odkrył zespół TJ Pitre’a – wartości zakodowane na stałe w CSS, odłączone komponenty w Figmie i brakujące metadane to prawdziwe źródło problemów, nie ograniczenia technologii MCP.

Dlaczego to jest istotne: To przesuwa odpowiedzialność i fokus z „naprawiania AI” na „naprawianie procesu projektowego”. Zapewnienie jakości zaczyna się na etapie projektowania, a nie programowania. Zamiast czekać na lepsze AI, możemy dramatycznie poprawić rezultaty już dziś przez uporządkowanie Figmy.

Test na jutro: Następnym razem gdy programista zgłosi problem z komponentem wygenerowanym przez AI, zamiast od razu poprawiać kod, zacznij od uruchomienia Figmalint na tym komponencie w Figmie. Sprawdź, czy naprawienie błędów w projekcie rozwiązuje problem w generowanym kodzie.

Ten wpis stanowi część kolekcji notatek z cennych podcastów, webinarów i innych treści. Źródłem była prezentacja DS Live z TJ Pitre na temat context-based design systems.

Tag: Design Engineering

Context-based design systems – jak AI rewolucjonizuje przepływ pracy od Figmy do kodu #EN254