Deweloper finalizuje interakcje i dostępność

Deweloper może wskazać najlepsze praktyki, designer dodaje je do kontekstu dla AI następnym razem. „Więc następnym razem gdy to się zdarzy, powiesz AI żeby po prostu odniosło się do tych innych komponentów, żeby wiedziało styl. Więc będzie wykładniczo lepsze za każdym razem gdy generujesz te rzeczy”.

Deweloper finalizuje interakcje i dostępność oraz pilnuje standardów kodu. W efekcie przekazanie 2.0 (handoff) przyspiesza wdrożenie i ogranicza nieporozumienia.

Petrie opisał progresję: „Może pierwszym razem, może jesteś 30% drogi. Może 60% drogi następnym razem, może 90% drogi następnym razem. I wtedy naprawdę zasypujesz tę lukę między designem a deweloperką”.

Inżynieria kontekstu vs kodowanie intuicyjne

Petrie wprowadził rozróżnienie kluczowe dla zrozumienia profesjonalnego wykorzystania AI.

Kodowanie intuicyjne to szybkie prototypowanie w narzędziach typu Lovable czy Bolt. Świetne do narzędzi osobistych – Petrie pokazał przykłady: wyszukiwarka najbliższych toalet z Google Maps API, tracker odżywiania „Eaton” gdzie dyktowanie posiłków automatycznie pobiera kalorie i makroskładniki, parsery faktur, sprawdzarki kontrastu kolorów.

To wszystko były „proste małe aplikacje”, ale „pomagały nam w naszych osobistych życiach”. Minimalna kontrola nad finalnym kodem, jednak świetne do eksploracji i życiowych sztuczek.

Petrie opisał fascynujące zjawisko: „Nie jest rzadkością dla mnie budowanie rzeczy, ale wtedy budowanie narzędzia, które pomaga mi budować tę rzecz lepiej. Więc wchodzi się w taką inception narzędzi AI, gdzie budujesz narzędzia, które budują narzędzia”. To meta-poziom pracy z AI, który otwiera nowe możliwości.

Inżynieria kontekstu to świadome zarządzanie kontekstem dla AI. Wykorzystanie istniejących komponentów jako wzorców. Przestrzeganie konwencji zespołu. „Człowiek w pętli” na każdym etapie. Jak mówi Petrie: „Inżynierujemy kontekst tego wszystkiego przez całą drogę. Nie bierzemy tego po prostu jak jest. Zawsze bierzemy to co przychodzi i wtedy robimy pełne sprawdzenie, żeby upewnić się, że koduje w sposób jaki South Left lubi kod”.

Wprowadził koncepcję inżyniera kontekstu: „Ukuliśmy de facto coined term to inżynier kontekstu. Ale inżynierujemy kontekst tego wszystkiego przez całą drogę, ponieważ nie bierzemy tego po prostu jak jest”.

Istotny element to arkusz kalkulacyjny konwencji nazewnictwa, który South Left utrzymuje z definitywną listą nazw komponentów i uzasadnieniami tych wyborów.

Pole Description w Figmie – sekretna broń

Jednym z najbardziej praktycznych odkryć Petrie’ego jest wykorzystanie pola Description w Figmie jako źródła kontekstu dla AI.

AI świetnie odczytuje wartości wizualne: kolory, zaokrąglenia, odstępy, rozmiary fontów, hierarchię elementów. Jednak nie rozumie intencji behawioralnych. Petrie dał konkretny przykład: „Czy zestaw paneli accordion powinien zwijać wszystkie czy pozwolić wszystkim być otwartym gdy jeden jest wybrany. To jest intencjonalne zachowanie”.

To nie wynika z wyglądu komponentu – to decyzja projektowa, która musi być gdzieś zapisana.

Petrie wyjaśnił rozwiązanie: „Więc tam wykorzystujemy to pole. Mamy własny MCP, który jest podobny do Figma MCP, którego używamy, który pomaga zbierać dane stąd i wtedy zapewniać dodatkowy kontekst do AI żeby upewnić się, że nie tylko przybija wygląd i wrażenia, ale też dostaje interakcje i zachowania, które są zamierzone dla tego komponentu”.

Pole Description w Figmie niesie intencje i pomaga AI odtworzyć zachowania w kodzie (np. logikę zwijania akordeonu czy priorytety fokusów). Dlatego AI łączy te informacje z danymi wizualnymi.

Ten kontekst przenosi się przez cały workflow, tworząc „kaskadę kontekstu” – koncepcję z Context Based Design Systems, innego warsztatu Petrie’ego. Kontekst przepływa: z Figmy (pola opisów, tokeny, właściwości) → przez MCP → do wygenerowanego kodu → do dokumentacji → do narzędzi typu Zeroheight czy Storybook.

Petrie podkreślił fundamentalną prawdę: „Kontekst jest tym, co AI kocha. Kontekst jest jak ja kocham pizzę. Kontekst jest tym, co AI naprawdę lubi. Więc im więcej kontekstu możesz podać, tym lepszy będzie output i tym lepsza będzie wiedza, którą będzie posiadać”.

Dokumentacja i intencje, które czyta AI

Tradycyjnie dokumentacja systemów projektowych to setki godzin pracy. Chris z uczestników wyraził frustrację: „Oczywiście wielu z nas designerów spędziło absurdalną ilość czasu na dokumentacji i użyciu tych komponentów”.

Petrie pokazał, jak odwrócić ten proces i wykorzystać tę wcześniejszą pracę.

Trzy poziomy automatyzacji

Poziom 1: Podstawa (zero wysiłku) – „Zamiast zaczynać od zera, komponent sam jest prawie samoobsługujący dla dokumentacji. Więc na bardzo podstawowym poziomie, możesz użyć Figma MCP żeby napisać dokumentację dla komponentu bazując na tym co MCP wie o tym komponencie”.

Zawiera: właściwości, warianty, tokeny, projekt wizualny. Wystarczy do szybkiego odniesienia.

Poziom 2: Wzbogacony kontekstem (minimalny wysiłek) – Description fields z Figmy, notatki behawioralne, wymagania dostępności, przypadki użycia i przykłady.

Poziom 3: Pełny system dokumentacji (skonfiguruj raz, używaj zawsze) – Dokumentację można następnie wygenerować z MCP do plików markdown i trzymać blisko kodu, co ułatwia wyszukiwanie oraz utrzymanie spójności.

Company Docs – własne narzędzie

Petrie opisał swoje rozwiązanie: „Stworzyliśmy narzędzie do tego zwane Company Docs. I Company Docs jest MCP gdzie możesz – możesz użyć twojego Figma MCP żeby generować twoje dokumenty jako pliki markdown i umieścić je w folderze docs. Możesz zainstalować przez NPM to Company Docs i zamieni twoje dokumenty w serwer MCP i wtedy możesz połączyć ten serwer MCP do Claude desktop do Slacka. Możesz użyć slash docs i wtedy zbierać informacje z twoich dokumentów”.

Rezultat: „To jest po prostu sposób żeby udostępnić twoją dokumentację do jakiejkolwiek usługi lub jakiejkolwiek platformy, którą chcesz zamiast mieć ją w jednym miejscu połączonej z jedną bazą kodu”.

AI zawsze wykorzysta Twoją pracę

Chris z uczestników martwił się o lata włożone w dokumentację. Petrie odpowiedział z przekonaniem, które Jenny z chatu podsumowała doskonale: „AI zawsze użyje i przeczyta dokumentację. To nie jest zmarnowane. To jest absolutnie kopalnia złota kontekstu”.

To zmienia perspektywę – cała ta praca staje się paliwem dla AI, które może teraz wykorzystać te lata wiedzy do generowania lepszego kodu, lepszej dokumentacji, lepszych wskazówek dla zespołu.

Atomic Design + AI = wykładniczy wzrost jakości

Petrie wyjaśnił kluczową strategię maksymalizującą efektywność AI w budowaniu systemów.

Zasada: zaczynaj od najmniejszego

„Zawsze staramy się pracować od komponentu najmniej zależnego do najbardziej zależnego. Oznacza to, że normalnie spróbujemy używać rzeczy i budować od bardzo małego – jeśli używamy metodologii atomic development, powiemy od najmniejszych, najbardziej atomowych elementów”.

Przykład z webinaru: avatar indicator – tylko 39 linii kodu, zero zagnieżdżonych komponentów, idealne do rozpoczęcia. Potem przyciski, ikony, odznaki, wskaźniki ładowania, separatory – wszystko bez zależności.

Graydon z uczestników zapytał o bardziej złożone komponenty: „Chcę lepiej zrozumieć z atomowej perspektywy jak byś obsłużył bardziej złożone komponenty? Więc może jest kilka zagnieżdżonych komponentów w większym komponencie. Czy zaczynasz od mniejszych zagnieżdżonych komponentów i wtedy w końcu budujesz do bardziej złożonych komponentów?”

Petrie potwierdził: „Tak. Trafiłeś w sedno. Tak. I nie skaczesz naprzód. Jesteś właściwie w prawym momencie”.

Kluczowa instrukcja w prompcie

Ta jedna instrukcja sprawia, że AI najpierw skanuje istniejące komponenty zamiast tworzyć wszystko od nowa. „Tworzysz po prostu komponent, który nie ma żadnych innych zagnieżdżonych komponentów w sobie. Zaczynasz na tym malutkim, malutkim, malutkim poziomie. I wtedy zaczynasz budować”.

Petrie używa metafory odwróconego trójkąta: „To jest jak wiesz, odwrócony trójkąt i wtedy gdy rzeczy stają się bardziej skomplikowane gdzie masz warstwy zagnieżdżonych komponentów, wtedy pomysł jest taki, że jeśli zachowam ten punkt tutaj, to będzie kontynuować skanowanie innych komponentów, które są dostępne i wtedy je uszereguje i zaimportuje te komponenty”.

Progresja jakości

Petrie opisał zjawisko wykładniczego wzrostu, które obserwuje w swojej agencji:

Iteracja 1: 30% gotowości do produkcji – „AI generuje bazę, dużo ręcznych poprawek, uczysz AI o swoich wzorcach. Więc następnym razem gdy to się dzieje, powiesz AI żeby po prostu odniosło się do tych innych komponentów, żeby znało styl”.

Iteracja 2: 60% gotowości do produkcji – „AI używa poprzednich komponentów, mniej błędów stylistycznych, lepsze dopasowanie do konwencji. Więc będzie wykładniczo lepsze za każdym razem gdy generujesz te rzeczy i za każdym razem gdy masz kolejną konwersację z zespołem deweloperskim”.

Iteracja 3: 90% gotowości do produkcji – „AI w pełni rozumie system, minimalne poprawki, prawie gotowy do zatwierdzenia kod. I wtedy z czasem zaczniesz wnosić aktualny kod, który możesz zatwierdzać i przesyłać do środowiska przed-produkcyjnego”.

„Zamiast zaczynać od zera, zaczynasz mając 30% drogi za sobą, może 60% drogi następnym razem, może 90% drogi następnym razem. I wtedy naprawdę zasypujesz tę lukę między designem a deweloperką”.

Kiedy potrzebujesz człowieka – zawsze, ale szczególnie przy złożoności

Petrie był szczery co do ograniczeń: „Gdy dostajesz się bardziej złożony na tym poziomie organizmu, to jest gdy interakcja człowieka musi być częścią tego od kroku pierwszego. Więc to naprawdę ważne żeby po prostu powtórzyć przez cały ten proces”.

Czasami AI „zaczyna działać chaotycznie” – „To jest identyczne do sposobu jakiego inni deweloperzy i wszystkie inne komendy AI, ponieważ czasami pójdzie na żywioł i zrobi coś zupełnie innego. Skąd SCSS się wzięło? Jak nie używaliśmy tego w tej bazie kodu a nagle pomyślał, że używamy. To bardzo rzadkie gdy się zdarza”.

Dlatego „zaangażowanie człowieka musi się dziać na każdym kroku, szczególnie gdy dochodzi do tych bardziej złożonych komponentów”.

Ograniczenia i oczekiwania

Petrie był transparentny co do granic technologii i rzeczywistych ograniczeń pracy z MCP:

Czego MCP nie może zrobić

Brak zapisu z powrotem do Figmy – Konektor jest tylko do odczytu, co oznacza jednokierunkowy przepływ danych. Petrie uznaje to za zaletę dla stabilności projektu.

Przy złożonych organizmach mogą wystąpić błędy wnioskowania – Dlatego warto rozbijać pracę na mniejsze elementy i stosować podejście atomic design.

Zużycie tokenów zależy od użytych narzędzi – W konsekwencji warto wyłączać niepotrzebne funkcje konektora (np. FigJam czy Code Connect jeśli ich nie używasz).

Holistyczne operacje są niemożliwe – Nie można dostarczyć raportu całego projektu naraz, nie zwróci całej tabeli zmiennych ze wszystkimi trybami, nie przetworzy wszystkich komponentów w bibliotece jednocześnie.

Zakres działania jest ograniczony – MCP może pracować tylko z konkretnym frame’em lub komponentem, zwraca zmienne związane z wybranym elementem.

Praktyczne uwagi techniczne

Lista funkcji konektora obejmuje także FigJam i Code Connect – Ale jeśli ich nie używasz, można je wyłączyć dla oszczędności tokenów.

Tryb Dev Mode w Figmie jest dostępny na planach płatnych – W Claude Desktop mogą obowiązywać dodatkowe limity tokenów w zależności od planu.

Model Claude Sonnet 4.5 bywa „nadgorliwy” – Petrie zauważył: „Czasami może trochę przesadzić. Używam Sonnet 4.5. Idzie bardzo mocno”. Pomaga precyzyjne polecenie i wskazanie katalogów wzorców.

Praktyczne zastosowania poza systemami

Banks i Petrie podzielili się obserwacją: nie wszystko musi być gotowe do produkcji, aby było wartościowe.

Narzędzia osobiste – uczenie przez budowanie

Petrie opisał swoje podejście do nauki: „Trzymam listę kontrolną w Apple Notes – co chcę zrobić, co próbuję z tym zrobić. Mam przeszły dziennik aplikacji i rzeczy nad którymi pracuję”.

Nazywa to „inception narzędzi AI” – budowanie narzędzi, które budują narzędzia. Jego przykłady z codziennej praktyki pokazują ewolucję myślenia od prostych aplikacji życiowych (wyszukiwarka toalet, tracker odżywiania) do narzędzi zawodowych (generatory dokumentacji, konwertery tokenów, narzędzia QA).

Petrie podsumował tę drogę: „Zaczęło się od tych typów małych małych sposobów żeby wymyślić życiowe sztuczki. I wtedy w końcu przemieściło się to do naszego świata pracy”.

Dostępność w sieci – niespodziewany bonus

Banks zauważył praktyczną zaletę lokalnego developmentu: „Gdy uruchamiamy rzeczy lokalnie, możemy uzyskać do nich dostęp na całej naszej sieci. Jeśli jesteś w domu i jesteś na swoim wifi, jeśli uruchomisz coś na swoim komputerze, absolutnie możesz uzyskać do tego dostęp na swoim telefonie”.

Praktyczny przypadek użycia: Storybook na localhost:6006, dostęp z telefonu przez wifi, testowanie komponentów na urządzeniach mobilnych w realnym środowisku, pokazywanie prototypów klientom bez wdrażania.

Dyscyplina i przytłoczenie – szczerze o kosztach

Codzienna rutyna – dwie godziny przed świtem

Petrie podzielił się swoją praktyką, która wymaga realnej dyscypliny: „Odkładam około dwie godziny każdego ranka zanim moje dzieci się obudzą gdzie jest bardzo cicho, jest ciemno na zewnątrz i nie ma przychodzących emaili. Mam wystarczająco czasu żeby skupić się i skoncentrować na tym co próbuję zrobić”.

System organizacji jest prosty, ale konsekwentny: lista kontrolna w Apple Notes, lista „co chcę zrobić” + „co próbuję osiągnąć”, dziennik przeszłych projektów i narzędzi, bieżące eksperymenty.

Dawki dopaminy vs porażki – realistyczne oczekiwania

Petrie był brutalnie szczery co do wskaźnika sukcesu: „Na 10 prób, które wypróbujesz, dostaniesz wielką wygraną. I to wystarczy dopaminy żeby cię utrzymać. Ponieważ te wygrane, które dostajesz z tych narzędzi, które używasz, szczególnie w branży w której jesteś i zestawie umiejętności, które posiadasz, gdy trafisz tę rzecz, to jest jackpot. Czujesz się jakbyś właśnie – czujesz się jakbyś odblokował kod do gry”.

Ale przed tym jackpotem jest dziewięć prób, które mogą nie działać. „Będzie dużo rzeczy, na które spędzisz dużo czasu i dużo tych rzeczy, na które spędzisz dużo czasu, poniesiesz porażkę. Będziesz sfrustrowany, ponieważ nie będzie robić rzeczy, którą chciałeś żeby robiła”.

Przyjęcie przytłoczenia jako stałego stanu

Petrie nie udawał, że ma wszystko pod kontrolą: „Jestem poza przytłoczony. Jak powiem ci to – bycie przytłoczonym nigdy się nie skończy. Nigdy nie jestem głęboko w tym. Ale to po prostu bycie okej z byciem przytłoczonym myślę i posiadanie możliwości bycia jak 'okej, to nie wyszło, przejdę dalej i wtedy zobaczę co jeszcze tam jest'”.

Jego rada brzmi paradoksalnie: „Trudno powiedzieć, ale rada to po prostu to zrobić i wskoczyć i nie bać się. I to jest trochę jak syndrom przedsiębiorczy. To jest jak podejmuj duże ryzyko, wiesz. Bez ryzyka, bez nagrody – typ sytuacji”.

Banks dodał perspektywę, która rezonowała z setkami uczestników: „Po prostu czuję się przytłoczony i trochę zestresowany. Myślę, że wszyscy to czujemy. To jest bardzo powszechne i uogólnione uczucie dzisiaj w branży”.

Tydzień przerwy = bycie w tyle

Banks i Petrie zgodnie przyznali realność sytuacji: „Bierzesz tydzień przerwy od tego i jesteś w tyle. Przegapisz narzędzie i jesteś w tyle”. Nowe narzędzia, modele i możliwości pojawiają się w tym tempie, że przerwa naprawdę oznacza konieczność nadrabiania.

Jednak Petrie pokazał, że to nie musi być przygnębiające – to może być ekscytujące, jeśli zaakceptujesz przytłoczenie jako część podróży.

Koszt i dostępność

Zestawienie kosztów według narzędzi

Claude Desktop + Figma MCP: Wymaga płatnej subskrypcji Claude dla pełnego dostępu. Uczestnicy zauważyli: „Używanie Figma wewnątrz Claude to funkcja płatna”. Jednak instalacja konektorów sama w sobie jest darmowa.

Cursor + Figma MCP: Darmowa wersja dostępna z limitami tokenów, płatna wersja znosi większość limitów, instalacja MCP darmowa. Banks podkreślił: „To może być lepsza ścieżka dla wielu ludzi dopiero zaczynających”.

Figma Dev Mode: Wymagany dla działania MCP. Uczestnik potwierdził w chacie: „Musisz mieć dev mode, ale wszystkie płatne pakiety”. Dostępny we wszystkich płatnych pakietach Figmy, nie działa na darmowym planie.

Storybook: Całkowicie darmowe i open-source, bez limitów użytkowania, bez kosztów.

Minimalna konfiguracja (najtańsza ścieżka): Płatny plan Figmy (Dev Mode) który większość już posiada + Cursor z darmowym kontem (limity tokenów wystarczające na start) + Storybook lokalnie (całkowicie za darmo). Koszt dodatkowy: zero, jeśli już masz płatną Figmę.

Figma Make i przyszłość round-tripping

Banks wprowadził temat, który nurtuje wielu designerów: „Jedna rzecz, która zawsze była moim punktem niepokoju to no wiesz, buduję to wszystko w Figmie i jeśli wyjdę poza Figmę, w pewnym momencie muszę dostać to z powrotem do narzędzia, ponieważ to jest nasz wspólny grunt”.

Figma Make jako częściowe rozwiązanie

Banks był entuzjastyczny o nową funkcję: „Z Figma Make, jedna fajna funkcja, która jest tam teraz to jeśli przesuniesz design naprzód, jest teraz przycisk kopiuj design, który pozwala skopiować cokolwiek zrobiłeś w Figma Make i przynieść to z powrotem”.

Figma Make pozwala skopiować efekt powstały „na zewnątrz” z powrotem do Figmy („Copy design”). Generujesz prototyp w Figma Make, kopiujesz design z powrotem do głównego pliku Figmy, możesz kontynuować iteracje w głównym pliku, nie tracisz pracy zrobionej poza Figmą.

Banks dodał z wyraźną nadzieją: „I myślę, że jak widzimy więcej i więcej wsparcia komponentów wewnątrz Figma Make tutaj w następnych kilku tygodniach lub miesiącach, to będzie niesamowite mieć to”.

Moment przełomowy – od ciekawostki do rewolucji

Petrie podzielił się osobistą historią, która pokazuje jak stopniowo docierało do niego, że to nie jest tylko zabawka.

Nieoficjalny Figma MCP – pierwszy prawdziwy test

Impuls do pracy z MCP dało ogłoszenie tej koncepcji; przed oficjalnym konektorem Figmy testowano nieoficjalny „Framelink”.

Przed oficjalnym Figma MCP istniał projekt stworzony przez społeczność, który teraz nazywa się Framelink: „I wtedy był pierwszy nieoficjalny Figma MCP, który wyszedł i to był pierwszy, który zacząłem testować myśląc okej to jest świetne. Jak mogę przenieść design, który był – lub komponent, który jest w Figmie do mojej bazy kodu i wtedy po prostu sprawić żeby działał”.

Petrie z wyraźnym entuzjazmem wspomniał przełomowy moment: „I to był moment eureka – i to jeden z momentów, który faktycznie zacząłem, ponieważ zawsze nagrywałem dużo tylko testowania z rzeczami kodowania intuicyjnego”.

Demo, które zmieniło wszystko

„Myślę, że jedno z pierwszych demo, które rezonowało z dużą liczbą ludzi i które sprawiło, że poczułem okej to jest ważne było jednym z nich, które opublikowałem na tym oryginalnym pre-Figma MCP. Teraz nazywa się Framelink i ukłony dla dewelopera tego”.

Co było tak przełomowe? „Bardzo mało informacji dostarczonych do AI i wygenerowało baner oparty na web component z naszego Altitude, naszego wewnętrznego systemu projektowego. I wtedy było po prostu jak po tym było po prostu jak wkopywanie się w każdą możliwą rzecz, którą mogliśmy”.

Minimalna konfiguracja, maksymalny output, realne komponenty nie makiety, praktyczna użyteczność od razu. To pokazało, że technologia jest gotowa do czasu produkcyjnego.

Refleksje na koniec – nowa rzeczywistość dla systemów projektowych

Banks – perspektywa designera na rewolucję

„Pamiętam gdy zaczynałem w designie i inżynierowie byli w Storybook i nie miałem pojęcia jak to ustawić, nie miałem pojęcia jak dostać coś z Figmy, nie miałem pojęcia jak to przetłumaczyć. I teraz, gdy łapiesz to, zajęłoby to maksymalnie 10 minut żeby ruszyć. To jest absolutnie niewiarygodne.„

Co się zmieniło w ciągu zaledwie kilku miesięcy:

Setup z dni do minut
Bariera wejścia dramatycznie niższa
Designer może wchodzić w terytorium kodu
Luka we współpracy się zwęża
Wspólny język przez kod i narzędzia

Petrie – perspektywa inżyniera na zmianę

„Ten nieoficjalny Figma MCP był prawdopodobnie katalizatorem, który był 'okej powinniśmy zacząć skupiać te proste małe aplikacje na znaczących rzeczach, które mogą pomóc naszej organizacji tak samo jak innym organizacjom, z którymi pracujemy'”.

Co się zmieniło w sposobie pracy South Left:

Narzędzia AI przestały być zabawkami
Inżynieria kontekstu jako dyscyplina
Możliwe są outputy gotowe do produkcji
Wykładniczy wzrost z każdą iteracją
Nadzór człowieka jako zaleta, nie wada

Wspólne wnioski – siedem kluczowych lekcji

1. Bariera jest niższa niż myślisz

Instalacja: 2-3 kliknięcia
Pierwszy komponent: około 10 minut
Nie potrzebujesz stopnia z informatyki
Tryb agenta dla mniej technicznych

2. Nadzór człowieka jest niezbędny

AI to narzędzie, nie zamiennik
Inżynieria kontekstu lepsza od kodowania intuicyjnego
Kontrola jakości na każdym etapie
„Nie bierzemy tego po prostu jak jest”

3. Zacznij małe, rośnij wykładniczo

Podejście atomic design działa
Każda iteracja jest lepsza (30% → 60% → 90%)
Bloki konstrukcyjne prowadzą do złożoności
Cierpliwość się opłaca

4. Kontekst jest królem

Pola opisów w Figmie = tajna broń
Istniejące komponenty jako wzorce
Dokumentacja jako kopalnia złota
„Kontekst jest tym co AI kocha”

5. Przytłoczenie jest normalne

Wszyscy to czują, Banks i Petrie też
Tydzień przerwy = bycie w tyle
Akceptacja przytłoczenia jako stanu
Dawki dopaminy z małych zwycięstw (1 na 10 prób)

6. Luka między designerem a deweloperem się zmniejsza

Wspólny język przez kod
Wspólne zrozumienie przez narzędzia
Przekazanie staje się iteracją
„Naprawdę zasypywanie tej luki”

7. Nie wszystko musi być gotowe do produkcji

Narzędzia osobiste uczą
Proste aplikacje prowadzą do znaczącej pracy
Inception narzędzi AI = budowanie narzędzi, które budują narzędzia
Eksperymentowanie ma wartość samo w sobie

Ostatnie słowa – odblokowywanie kodów do gry

Banks podsumował uczucie wielu: „Po prostu czuję się przytłoczony i trochę zestresowany. Myślę, że wszyscy to czujemy. To jest bardzo powszechne i uogólnione uczucie dzisiaj w branży”.

Jednak Petrie pokazał, że przytłoczenie można przekuć w postęp: „Te wygrane, które dostajesz z tych narzędzi, szczególnie w branży w której jesteś i zestawie umiejętności, które posiadasz – gdy trafisz tę rzecz, to jest jackpot. Czujesz się jakbyś odblokował kod do gry.„

To nie jest zamiana ludzi na maszyny. To nie jest eliminacja pracy designera czy dewelopera. To jest odblokowywanie kodów do gry – nadal grasz w tę samą grę, nadal robisz tę samą pracę, ale nagle masz narzędzia, które pozwalają ci iść dalej, szybciej, głębiej niż kiedykolwiek wcześniej.

Banks na zakończenie przypomniał o wspólnym celu: „Naszym celem dla tej sesji dzisiaj jest bardzo byśmy chcieli mieć pytania od was wszystkich, bardzo byśmy chcieli mieć was z włączonym mikrofonem, powiedzieć hej”. I dostał to – niemal 300 osób przyszło nie po to, żeby siedzieć cicho i słuchać o teorii. Przyszli zobaczyć prawdziwe demo, zadawać pytania, zacząć swoją własną podróż.

Jak powiedział Petrie na początku: „Rada to po prostu to zrobić i wskoczyć i nie bać się”.

Kluczowy insight

Tylko do odczytu przyspiesza dostarczenie

Standardowo myślimy: Dwukierunkowa synchronizacja Figma ↔ kod jest konieczna, aby działać szybciej. Potrzebujemy narzędzi, które pozwolą nam edytować zarówno po stronie designu jak i kodu, a zmiany będą się synchronizować w obie strony.

W praktyce okazuje się, że: Konektor tylko do odczytu z jednym punktem prawdy w Figmie skraca pętlę i ogranicza wycofania zmian. Generacja i poprawki odbywają się po stronie kodu i Storybooka, plik projektowy pozostaje nienaruszony. To jednokierunkowe podejście eliminuje konflikty edycyjne, które powstają przy dwukierunkowej synchronizacji.

Dlaczego to jest istotne: Stabilne źródło zmniejsza konflikty edycyjne i rozbieżności. Gdy Figma jest punktem odniesienia tylko do odczytu, zespoły nie muszą zarządzać konfliktami scalania między designem a kodem. W rezultacie zespoły szybciej osiągają zgodność wizualną oraz interakcyjną. Petrie podkreślił: „Wolałbym, żeby inżynierowie nie mieli żadnej kontroli nad moimi rzeczami w Figmie” – ta separacja odpowiedzialności faktycznie przyspiesza proces.

Test na jutro: Przy następnym komponencie przyjmij zasadę „tylko do odczytu”:

Użyj trybu Desktop MCP dla szybszego działania
Opisz intencje w polu Description w Figmie
Przepuść komponent przez Figmalint przed generacją
Wygeneruj TSX/CSS Modules/.stories
Popraw wyłącznie w kodzie (nie wracaj do Figmy, chyba że to błąd projektowy)
Gdy to konieczne, na końcu użyj w Figma Make funkcji „Copy design”

Zmierz czas do pierwszego renderu w Storybooku na localhost:6006, liczbę poprawek i wycofań względem dotychczasowego trybu pracy z dwukierunkową synchronizacją. Większość zespołów odkrywa, że osiągają pierwszy działający komponent o 40-60% szybciej przy jednokierunkowym przepływie.

Uzupełnienia z rozmowy – dodatkowe perełki

LinkedIn jako platforma uczenia się

Banks w swoim wstępie podkreślił wartość podejścia Petrie’ego: „Co najbardziej kocham w TJ to że on trochę po prostu udostępnia prawdziwą rzecz, nieedytowaną, co działa dla niego w świecie MCP i AI”. To nie są wypolerowane prezentacje czy teoretyczne pogadanki – to prawdziwe próby, pokazywanie zarówno sukcesów jak i porażek.

Banks wyraził frustrację, którą czuje cała branża: „Tam gdy mówimy o AI w branży myślę, że jest dużo wysokopoziomowych rozmów i jest dużo założeń, że już znasz to wszystko i jesteś w tym”. To podejście – zaczynanie od zera – jest tym, czego brakuje w większości treści o narzędziach AI.

Lovable i niestandardowe biblioteki komponentów

Keaton zadał pytanie o Lovable. Petrie wyjaśnił workflow: „Możesz użyć MCP żeby stworzyć twoją bibliotekę komponentów, ale wtedy użyć tej biblioteki komponentów w Lovable żeby być w stanie faktycznie generować logikę biznesową dla tej aplikacji”.

Jednak dodał: „Twoje kanoniczne źródło skończyłoby jako twoja baza kodu i wtedy musiałbyś przepakować to jako nową wersję i wtedy ponownie przesłać to do Lovable. Ta część Lovable jest trochę szara strefa dla mnie. Nie miałem dużo sukcesu z tą częścią tego. Ale wiem, że bardzo ciężko nad tym pracowali”.

Co Lovable potrafi out-of-the-box: ShadCN, Mantine, Chakra, Material UI. To pokazuje, że nie wszystko jest jeszcze rozwiązane – niestandardowe systemy projektowe w narzędziach do kodowania intuicyjnego to dalej rozwijający się obszar.

Tailwind i AI

W kontekście frameworków Petrie rzucił ciekawą obserwację: „AI seems to really love Tailwind because it’s very popular”. To prosty fakt – większa popularność oznacza więcej danych treningowych, co przekłada się na lepsze wyniki z AI. Teams myślące o adoption nowych narzędzi mogą chcieć wziąć to pod uwagę.

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ć. To zapis webinaru Joey’a Banksa i TJ Petrie Doing More With Your Design System in Figma

TL;DR

Wprowadzenie

Czym jest Model Context Protocol?

Ewolucja narzędzi – od Copilot do MCP

Konfiguracja środowiska – setup w trzech krokach

Krok 1: Figma (Dev Mode)

Krok 2: Claude Desktop

Krok 3: Cursor lub VS Code

Od Figmy do kodu – praktyczny workflow Figma → Storybook

Analiza komponentu

Przygotowanie środowiska Storybook

Anatomia skutecznego prompta

Generacja plików

Rezultat w Storybook – moment Boba Rossa

Zasady, które robią różnicę

1. Jednoznaczne nazewnictwo i przewidywalna struktura

2. Od najmniejszego do złożonego

3. Reużycie ponad duplikację

4. Tokeny i zmienne zamiast wartości stałych

✅ Checklisty operacyjne

A) Pre-flight komponentu w Figmie

B) Generacja i kontrola jakości

Kontrola jakości: trzy kroki bez skrótów

Krok 1: Pre-flight w Figmie

Krok 2: Ocena wyniku AI

Krok 3: Ręczne poprawki i dostępność

Lista poleceń do AI i kiedy ich używać

1. „Tell me about this component: <link>”

2. „Can you use the Figma MCP to tell me about this component?”

3. „Follow the coding methods and patterns used in this directory: /src/components (TypeScript components, CSS Modules, Storybook story)”

4. „Use the same naming convention for the folder and files as sibling components”

5. „If this component contains subcomponents or nested components, check for existing ones and reuse them before creating anything new”

6. „Place the generated files in the same components directory”

7. „Why is this padding off?”

8. „Wygeneruj dokumentację komponentu na podstawie kontekstu MCP (markdown)”

Role i współpraca

Co projektant musi wiedzieć?

Projektant jako inicjator procesu

Tag: Storybook Komponenty

Figma MCP to Storybook in Minutes: Webinar Notes with Banks & Petrie #EN348