Notatki z webinaru przeprowadzonego przez Dominica Nguyen (współzałożyciela Chromatic, firmy stojącej za Storybook) oraz TJ Petrie (założyciela i CEO South Left, konsultingu design systemów). Wszystkie przedstawione przemyślenia, obserwacje i wnioski pochodzą od prelegentów.

Najważniejsze punkty z rozmowy

Problem rozwiązany: LLM bez kontekstu design system generują nieprzydatny, generyczny kod – Story UI to zmienia
Architektura: Storybook + MCP server + Claude AI = komponenty zgodne z firmowymi standardami
Szybkość: Generowanie wariantów komponentów i złożonych layoutów w 30-45 sekund
Użytkownicy: Project managerowie, designerzy, product ownerowie – bez znajomości kodu
Kompatybilność: Działa z popularnymi design systems (Mantine, Ant, Material, Canvas Kit)
Ograniczenia: Obecnie tylko React, plany rozszerzenia na Angular/Vue/Svelte
Visual Builder: Funkcjonalność drag&drop w rozwoju (65% gotowa)

Paradoks AI w generowaniu UI

Dominic Nguyen rozpoczął webinar od opisu typowego doświadczenia z promptowaniem AI. Według jego obserwacji większość prób kończy się rozczarowaniem – mimo perfekcyjnego promptu i dodania odpowiednich plików do kontekstu, rezultat nadal przypomina przysłowiowy „psi obiad”.

LLM potrafią generować kod szybko, jednak bez kontekstu design system organizacji rezultaty pozostają nieprzewidywalne. W najlepszym przypadku otrzymujemy generyczny output, który nie różni się od dostępnych szablonów.

Design system stanowi żywą kolekcję zatwierdzonych wzorców organizacji. Mimo że LLM zostały wytrenowane na miliardach linii kodu, nie posiadają wiedzy o kontekście operacyjnym konkretnej firmy. To właśnie kontekst operacyjny decyduje o tym, czy kod rzeczywiście trafi do produkcji.

Rozwiązanie Story UI – architektura połączonego systemu

TJ Petrie, prowadzący agencję South Left od 14 lat, opracował Story UI jako odpowiedź na opisane problemy. Narzędzie opiera się na trzech filarach:

Storybook – system of record dla komponentów, stories i dokumentacji
MCP (Model Context Protocol) – mechanizm dostarczający kontekst
LLM – generowanie kodu (Claude)

Ewolucja Story UI – od eksperymentów do gotowego narzędzia

South Left od lat eksperymentuje z AI w różnych workflow i produktach. Historia rozwoju Story UI przebiegała etapami:

YAML files + AI agents – pierwsze eksperymenty ze scaffoldingiem komponentów
Figma Bridge – rozszerzenie VS Code używające personal access token do pobierania JSON payload z Figmy
Community-driven Figma MCP (obecnie Framelink) – punkt zwrotny w jakości generowanego kodu
Story UI – finalne rozwiązanie łączące wszystkie doświadczenia

Kontekst biznesowy – problem z wyceną projektów

TJ Petrie wskazuje na kluczowy problem agencyjny związany z wyceną. Trudności pojawiają się szczególnie w obszarze „recipe” lub organizmów wyższego poziomu, gdzie klienci chcą zobaczyć szablony złożone z już stworzonych komponentów.

Przykład job board ilustruje problem – czy to jeden szablon, czy różne warianty? Z małą ilością danych czy gęsto wypełniony z paginacją i filtrami? Komponenty już istnieją, więc technicznie nie jest to skomplikowane, jednak zespoły nie chcą się „zagalopować” przy wycenie.

Enhanced Component Discovery

Story UI wykorzystuje funkcję Enhanced Component Discovery, która przeszukuje określone katalogi w poszukiwaniu komponentów. System przechowuje informacje w MCP server i działa w czasie rzeczywistym – dodanie nowych komponentów natychmiast je uwzględnia.

Proces instalacji Story UI

Kroki instalacji:

npm install story-ui
npx story-ui init – uruchomienie interaktywnej konfiguracji
Dodanie Claude API key do pliku środowiskowego
npm run storybook-with-ui – uruchomienie Storybook + MCP server

System automatycznie wykrywa popularne design systems (Chakra, Ant, Material, Mantine) lub analizuje strukturę katalogów dla niestandardowych systemów.

Demo w praktyce – od komponentów do złożonych layoutów

Generowanie wariantów komponentów

TJ Petrie zademonstrował generowanie wszystkich wariantów buttonów jednym promptem. W ciągu 30 sekund system wygenerował kompletną stronę z wszystkimi dostępnymi wariantami buttonów z Mantine design system.

Prelegent podkreślił złożoność komponentów typu button. Ludzie zawsze chcą zaczynać design systemy od buttonów, mimo że to jedna z najbardziej złożonych rzeczy – zawiera najwięcej wariantów, stanów i właściwości.

Złożone layouty w praktyce

System sprawdza się również przy bardziej skomplikowanych układach. Podczas demo wygenerowano:

Przykłady layoutów:

Trzy karty obok siebie z różnymi strukturami (obraz+tytuł+opis, tylko tekst, header+footer+przyciski)
Dashboard w stylu Kanban z kolumnami „backlog”, „ready”, „in progress”, „done”
Klona LinkedIn z nagłówkiem, nawigacją i układem treści
Interfejs z zakładkami z interakcją (tabs z underline, pills, default variants)

TJ Petrie zauważył, że im bardziej skomplikowane layouty, tym większe ryzyko błędów. Jednak wyniki Story UI znacząco przewyższają rezultaty uzyskiwane przez ChatGPT czy Claude bez odpowiedniego kontekstu.

Konfiguracja i kompatybilność z różnymi systemami

Systemy wspierane natychmiastowo:

Mantine – kompleksowy, uniwersalny design system
Ant Design
Material UI
Chakra UI

Systemy testowane z sukcesem:

Workday Canvas Kit – publicznie dostępny system korporacyjny
Polaris (Shopify)
Atlassian design system
Base (Uber)

Dla niestandardowych design systems Story UI oferuje pliki konfiguracyjne:

considerations.md – „ostatnia linia obrony” zawierająca zasady używania tokenów, best practices dla layoutu, komponenty do priorytetyzacji
Katalog docs – dokumentacja specyficzna dla organizacji

Considerations file służy rozwiązywaniu problemów z halucynacjami AI – gdy system niepoprawnie używa sub-komponenty lub emoji zamiast ikon.

Jakość design system w Figmie – struktura plus intencja

TJ Petrie podkreśla fundamentalną zasadę dotyczącą jakości systemów projektowych. Wszystko sprowadza się do kontekstu – im więcej czasu i wysiłku włożonego w źródło prawdy (Figma), tym lepsze rezultaty.

Kluczowe elementy jakości:

Struktura – poprawne wykorzystanie panelu właściwości
Intencja – opisy wyjaśniające przeznaczenie i sposób działania
Context dla AI – wykorzystanie pól opisów do przekazania informacji przez Figma MCP do kodu

Sub-agenci i optymalizacja tokenów

Zespół South Left opracował sub-agentów zwanych Figma MCP helpers. Gdy Figma MCP generuje kod, wzywa pomoc tych sub-agentów, które sprawdzają accessibility, interactivity, definicje props oraz strict typing.

System optymalizuje również koszty poprzez zmniejszenie „myślenia” AI – dostarczanie większej ilości kontekstu prowadzi do lepszych rezultatów przy niższym zużyciu tokenów.

Użytkownicy docelowi i sposoby wykorzystania

Profile użytkowników i zastosowania

Project Manager

Szybkie prototypowanie bez angażowania zespołu deweloperskiego
Testowanie koncepcji przed inwestycją w zasoby
A/B testing różnych wariantów interfejsów

Product Owner

Sprawdzanie pomysłów przed przejściem do fazy projektowania
Prezentacja stakeholderom opcji layoutu
Proof of concept dla nowych funkcji

Designer

Eksploracja możliwości przed pracą w Figmie
Testowanie kompatybilności komponentów
Szybka weryfikacja pomysłów układu

QA Engineer

Testowanie wszystkich wariantów komponentów
Sprawdzanie stanów walidacji formularzy
Stress testing układów z różną ilością treści

Context engineering vs prompt engineering

TJ Petrie wprowadza kluczową koncepcję zmieniającą podejście do AI. Zamiast skupiać się na doskonaleniu promptów, lepiej dostarczyć więcej kontekstu systemowego.

Analogia z Midjourney ilustruje problem – gdy prosimy o aktualizację elementu obrazu, prawdopodobnie pojawią się artefakty w innych miejscach. To samo dzieje się przy generowaniu kodu. Dlatego Visual Builder pozwala na precyzyjne modyfikacje bez regenerowania całego layoutu.

Bezpieczeństwo i architektura

Na pytania dotyczące bezpieczeństwa MCP, TJ Petrie odpowiedział, że nie ma obaw co do custom MCP stworzonego przez jego zespół. Zna wszystkie funkcje dostępne w systemie, a jedyne zewnętrzne połączenie to API Anthropic. System loguje wszystkie komunikaty między MCP a Claude, zapewniając transparentność procesów.

Wygenerowane story trafiają bezpośrednio do systemu plików projektu w katalogu określonym podczas konfiguracji. Story UI faktycznie aktualizuje kod źródłowy, tworząc rzeczywiste pliki story.

Visual Builder i przyszłość narzędzia

Visual Builder w fazie beta

Story UI rozwija funkcjonalność Visual Builder – edytor typu drag&drop obecnie gotowy w 65%. System umożliwia:

Podświetlanie i edycję poszczególnych komponentów w layoutcie
Modyfikację spacing bez dodatkowych promptów
Usuwanie elementów bezpośrednio z interfejsu
Zapisywanie zmian do plików story

Główne ograniczenia dotyczą stabilności – im więcej komponentów, tym trudniejsze przetwarzanie.

Plany rozwoju

Priorytet pierwszy: Rozszerzenie na Angular, Vue i Svelte

Funkcjonalności zespołowe: Remote MCP deployment umożliwiający współdzielenie instancji między członkami zespołu przez chronione hasłem, publicznie dostępne domeny.

Więcej design systems: Finalizacja wsparcia dla kolejnych korporacyjnych systemów projektowych.

Aspekt kreatywny narzędzia

TJ Petrie pokazał również bardziej eksperymentalną stronę narzędzia, generując interfejs Game Boy z działającymi przyciskami ikonowymi. To ilustruje uniwersalność Story UI – od profesjonalnych dashboardów po projekty eksperymentalne.

Konkurencja i rozwój ekosystemu

Dominic Nguyen wspomniał o planach zespołu Storybook dotyczących własnego MCP server. Jedną z kluczowych funkcjonalności będzie umożliwienie LLM konsystentnego raportowania działających URL story – obecnie sposób generowania URL przez Storybook pozostaje „czarną skrzynką”.

Biblioteka promptów Story UI – przykłady z webinaru

Generowanie inventory komponentów

„Generate all button variants on one page” Zastosowanie: QA, przegląd wszystkich dostępnych wariantów, dokumentacja dla stakeholderów

„Show tabs with underline pills and default variants” Zastosowanie: Testowanie interaktywnych komponentów z różnymi stylami

„Show me all buttons in dark mode versus light mode in a side by side two column grid” Zastosowanie: Porównywanie wariantów, testowanie consistency między trybami

Tworzenie layoutów kompozytowych

„Generate three cards side by side, one with an image title description, one with just text content, and another one with a header footer action button. Make the content Taylor Swift related„ Zastosowanie: Prototypowanie różnych wariantów komponentów, testowanie z konkretną tematyką

„Generate a Kanban style dashboard with backlog ready, in progress and done„ Zastosowanie: Złożone układy organizacyjne, dashboard prototyping

QA i stress testing

„Generate a card component with an image, a title, a deck, and then make that deck be 16 paragraphs„ Zastosowanie: Testowanie granic komponentów, sprawdzanie zachowania przy dużej ilości treści

„Show me all of the validation states of a form field. Show me all of the form fields with their validation states„ Zastosowanie: Kompleksowe testowanie formularzy, sprawdzanie pokrycia stanów błędów

Iteracje i modyfikacje

„Add two call to action buttons„ Zastosowanie: Po wygenerowaniu podstawowego layoutu, modyfikacje bez regenerowania całości

„Use Story UI to create a basic card component with a image title and call to action„ Zastosowanie: Podstawowy prompt startowy dla prostych komponentów

Kluczowy insight

System projektowy dla maszyn

Standardowo myślimy: Dokumentowanie komponentów w systemie projektowym służy głównie komunikacji w zespole – aby inni deweloperzy i projektanci wiedzieli, jak ich używać.

W praktyce okazuje się, że: Ta dokumentacja staje się najważniejszym źródłem kontekstu dla AI. System projektowy przestaje być tylko podręcznikiem dla ludzi, a staje się API dla maszyn, które uczą się z niego intencji, struktury i ograniczeń.

Dlaczego to jest istotne: To zmienia postrzeganie pracy nad systemem projektowym z kosztu (utrzymanie dokumentacji) na inwestycję (trenowanie automatycznego asystenta). Jakość metadanych w Figmie wprost przekłada się na jakość i szybkość pracy AI.

Test na jutro: Następnym razem gdy będziesz dokumentować nowy komponent lub jego wariant, zamiast pisać opisy tylko dla człowieka, napisz je jak instrukcję dla robota: precyzyjnie, jednoznacznie, definiując cel i ograniczenia. Sprawdź, czy taki opis pomógłby AI podjąć właściwą decyzję bez dodatkowych pytań.

Ten wpis stanowi część kolekcji notatek z wartościowych podcastów, webinarów i prezentacji. Oryginalne źródło: webinar „AI that knows (and uses) your design system” – Chromatic/Storybook.

Tag: Dominic Nguyen

AI które zna (i używa) Twój design system #EN267