Twój zespół developmentu właśnie dostał makiety z Figmy.
Projektant mówi "to gotowe". Developer patrzy na design i zastanawia się, jak to przekuć na kod. AI assistant próbuje pomóc, ale generuje kod pełen <div> zamiast semantycznych komponentów. Rezultat? Trzy dni roboty, dwadzieścia rund poprawek i interfejs, który wygląda "prawie" jak w projekcie.
Brzmi znajomo?
Problem nie leży w AI. Ani w projektancie. Ani w programiście.
Problem to design system zbudowany dla ludzi, nie dla maszyn.
Przez ostatnią dekadę design systemy były bibliotekami wzorców dla zespołów. Dokumentacja pisana z myślą o tym, że developer "wie, o co chodzi". Kolor, odstęp, komponent - człowiek patrzy i rozumie kontekst.
AI nie ma tego kontekstu.
Kiedy agent AI czyta twój design system, widzi kolory hex, piksele, prostokąty. Nie widzi intencji. Nie rozumie, że czerwony przycisk to destrukcyjna akcja. Nie wie, że ten konkretny odstęp to część systemu 8px grid.
Efekt? Halucynacje w kodzie. Niespójności. Błędy, które kosztują.
Ten artykuł pokazuje dokładnie, jak zbudować design system gotowy na AI - taki, który skraca cykl design-to-code z dni do godzin. Z przykładami od Siemens i GitHub oraz konkretnym frameworkiem wdrożenia.
Dlaczego twój design system sabotuje AI
Tradycyjny design system zakłada jedną rzecz: że człowiek wypełni luki.
Dokumentacja mówi "użyj Primary Button dla głównej akcji". Developer wie z doświadczenia, że to znaczy: jeden na widok, wyrównany do prawej, z odpowiednim kontrastem. Wiedza ukryta.
Agent AI czyta tę samą dokumentację i widzi instrukcję. Nie widzi zasad. Może wygenerować pięć Primary Buttons na jednym ekranie. Bo nikt jawnie nie zakodował ograniczenia.
Artykuł Figmy "5 shifts redefining design systems in the AI era" opisuje tę przepaść między tym, co projektant i developer wiedzą intuicyjnie, a tym, co AI potrafi wywnioskować z danych.
Badania pokazują trzy typy wiedzy w design systemach:
Wiedza jawna - skodyfikowana, w dokumentacji. AI radzi sobie z tym świetnie.
Wiedza ukryta - w przepływach pracy, nawykach. "Zawsze używamy siatki 8px", ale nigdy tego nie zapisaliśmy. AI tu gubi wątek.
Wiedza cicha - głęboko osobista. "Czucie" marki, intuicja. Najtrudniejsza do transferu.
Problem w tym, że większość design systemów opiera się głównie na wiedzy ukrytej i cichej. Dla AI to czarna dziura.
Twoja agencja może mieć 200 komponentów w Figmie, ale jeśli AI nie potrafi ich zrozumieć - ich semantyki, kontekstu użycia, ograniczeń - każde generowanie kodu to loteria.
Trzy fundamenty design systemu dla AI
Żeby AI przestało halucynować i zaczęło komponować, twój design system potrzebuje trzech warstw: struktury semantycznej, języka intencji i protokołu kontekstu.
Każda warstwa eliminuje inny rodzaj błędów.
Fundament 1 - Struktura semantyczna przez Auto Layout
Pierwsza zasada: każdy element musi mieć jawną relację przestrzenną.
Kiedy projektant w Figmie ręcznie wyrównuje tekst wewnątrz prostokąta, dla człowieka to wygląda jak przycisk. Dla AI to dwa niepowiązane obiekty dzielące współrzędne.
Auto Layout zmienia to radykalnie.
Tworzy hierarchię rodzic-dziecko, którą AI może przeczytać deterministycznie. "Układ Poziomy" z "Space Between" w Figmie tłumaczy się 1:1 na display: flex; justify-content: space-between; w CSS.
Konkretnie:
Bez Auto Layout: AI analizuje pozycje X/Y wszystkich elementów, próbuje wywnioskować layout, generuje sztywne width: 345px. Interfejs pęka na innych rozdzielczościach.
Z Auto Layout: AI czyta layoutMode: HORIZONTAL, counterAxisSizingMode: AUTO i generuje flex flex-row w-fit. Responsywny z definicji.
To nie jest kosmetyczna różnica. To różnica między kodem, który działa na wszystkich urządzeniach, a kodem który wymaga ręcznej refaktoryzacji.
Nasz framework wymaga 100% pokrycia Auto Layoutem w komponentach systemowych. Żadnych wyjątków. Brzmi restrykcyjnie? Ostatni projekt: 89 ekranów, generowanie kodu z AI, zero problemów z layoutem. Oszczędność: około 12 godzin pracy developera.
Fundament 2 - Zmienne jako słownik intencji
Druga zasada: każda wartość musi mieć nazwę semantyczną.
Różnica między #0055FF a sys.color.action.primary to różnica między wartością a koncepcją.
Kiedy design używa surowego hex, AI widzi kolor. Kiedy używa zmiennej, AI widzi znaczenie. I może zmapować ten token do odpowiadającego mu tokena w kodzie - var(--sys-color-action-primary).
Rezultat: 100% spójności między designem a kodem. Zero halucynacji "wystarczająco podobnego koloru".
Zmienne robią jeszcze jedną krytyczną rzecz: ograniczają przestrzeń wyjściową AI.
Bez tokenów model może wygenerować dowolny kolor, dowolny odstęp. Z tokenami? Tylko zatwierdzone wartości. To jak kwantyzacja możliwości projektowych - redukujesz entropię, zwiększasz przewidywalność.
Fundament 3 - Model Context Protocol jako most
Trzecia zasada: AI musi mieć dostęp do pełnego kontekstu projektowego w czasie rzeczywistym.
Tu wchodzi Model Context Protocol (MCP) - otwarty standard od Anthropic, przyjęty przez Figmę.
Zamiast wysyłać AI screenshot, wysyłasz ustrukturyzowany JSON z pełną semantyką projektu.
Architektura wygląda tak:
- Serwer MCP Figmy (lokalny lub zdalny) eksponuje dane projektowe
- Klient MCP w IDE (VS Code, Cursor, Windsurf) odpytuje serwer
- AI agent otrzymuje nie piksele, ale schemat - hierarchię węzłów, reguły layoutu, odniesienia do zmiennych, właściwości komponentów
Przykładowy ładunek JSON dla przycisku:
{
"nodeId": "123:456",
"name": "Primary Button",
"layoutMode": "HORIZONTAL",
"primaryAxisSizingMode": "AUTO",
"fills": "var:sys.color.action.primary",
"componentInstance": "design-system/Button"
}
AI czyta to i wie dokładnie:
- Jaki komponent importować z systemu
- Jakie propsy ustawić
- Jak ułożyć elementy
- Które tokeny użyć
Dodaj do tego Code Connect - mapowanie komponentów Figmy do konkretnych plików w repozytorium - i dostajesz coś potężnego.
Kiedy AI napotyka zmapowany komponent, nie generuje nowego kodu. Importuje istniejący komponent z bazy kodu. Z poprawnymi propsami. Z pełną logiką. Z testami.
Jak to wygląda w praktyce
Teoria brzmi pięknie. Ale działają te rzeczy na produkcji?
Tak. Firmy takie jak Siemens i GitHub już wdrażają te rozwiązania.
Siemens - interfejsy przemysłowe z MCP
Siemens opisał swoje podejście do wykorzystania Figma MCP Server w kontekście interfejsów przemysłowych.
Wyzwanie, z którym się mierzyli: złożone, krytyczne dla bezpieczeństwa interfejsy. Ogromna biblioteka komponentów. Wymogi compliance, które mogą przytłoczyć.
Tradycyjny handoff wyglądał tak - projektant przekazuje pliki, developer interpretuje, narastający dług projektowy, wysokie wskaźniki błędów.
Ich rozwiązanie opiera się na:
- Wdrożeniu Figma MCP i Code Connect
- Zmapowaniu biblioteki komponentów przemysłowych do bazy kodu
- Dodaniu warstwy semantycznej do komponentów
Rezultat według Siemens: cykl design-to-code skrócony z dni do godzin. Przyspieszona walidacja konfiguracji w różnych przeglądarkach i znacząca redukcja manualnego wysiłku QA.
GitHub - automatyzacja synchronizacji tokenów
GitHub i Figma organizują webinar pokazujący, jak zespół Primer (design system GitHuba) wykorzystuje Figma MCP Server z GitHub Copilot.
Podejście GitHuba:
- AI agent skanuje zarówno pliki Figmy, jak i repozytorium kodu
- Automatycznie identyfikuje rozbieżności w tokenach (np. różne wartości hex dla tego samego koloru)
- Generuje Pull Requesty synchronizacyjne
To rozwiązanie problemu "dryfu" - powolnego rozjeżdżania się wartości między projektem a kodem, który w dużych systemach zjada godziny pracy tygodniowo.
Ważne zastrzeżenia - technologia w fazie rozwoju
Zanim wdrożysz MCP w swoim zespole, musisz znać realne ograniczenia obecnych rozwiązań:
Status beta: Oficjalny serwer Figma MCP jest wciąż w publicznej becie. Oznacza to potencjalne problemy ze stabilnością i zmiany w API.
Wymagania licencyjne: Pełna funkcjonalność (szczególnie Code Connect) wymaga planów Figma Professional lub Enterprise.
Złożoność setupu: Konfiguracja MCP wymaga solidnych kompetencji technicznych. Małe zespoły bez dedykowanych zasobów DevOps mogą mieć trudności z wdrożeniem.
Dojrzałość design systemu: Największe korzyści osiągają zespoły, które już mają dobrze zorganizowany design system z pełnym pokryciem Auto Layout i zmiennymi. Dla zespołów startujących od zera - najpierw trzeba zbudować fundamenty.
Jak to wdrożyć w swoim projekcie
Widzisz wartość. Pytanie brzmi - jak zacząć?
Framework, który stosujemy we WZÓR ma 5 faz. Nie kroków. Faz. Bo to nie liniowy checklist.
Na początek - audyt obecnego systemu
Tydzień pracy. Maksymalnie dwa.
Przejrzyj swój design system i odpowiedz na pytania, które bolą:
- Jaki procent komponentów używa Auto Layout? (Target: 100%)
- Czy wszystkie kolory, odstępy, czcionki to zmienne? (Target: 100%)
- Czy komponenty w Figmie mają takie same nazwy jak w kodzie?
- Czy jest dokumentacja kiedy używać komponentu, nie tylko jak?
Przeanalizuj bazę. Bez tego nie zobaczysz progresu.
Dalej - semantyczna refaktoryzacja
To inwestycja 2-3 tygodnie lub pół roku. Zależy wszystko od tego jak wygląda obecny stan pliku. Ale zwraca się przy pierwszym projekcie z AI.
Priorytet na komponenty najczęściej używane. Dodaj Auto Layout do wszystkich komponentów. Zamień surowe wartości na zmienne. Wyrównaj nazewnictwo Figma ↔ kod - dokładnie te same nazwy propsów. Dodaj opisy typu "Maksymalnie 1 Primary Button na widok".
Brzmi jak dużo pracy?
Tak. I jest warto.
Teraz - wdrożenie MCP
Setup techniczny zajmuje tydzień. Zainstaluj Figma MCP server - lokalny lub zdalny. Skonfiguruj połączenie w IDE zespołu. Przetestuj ekstrakcję kontekstu na prostym komponencie. Dokumentuj setup dla zespołu.
I w końcu - mapowanie Code Connect
Dwa tygodnie lub więcej na połączenie Figmy z repozytorium. Zmapuj kluczowe komponenty Figma → kod. Dodaj snippety importów i użycia. Wpisz custom instructions dla skomplikowanych komponentów. Podłącz GitHub dla live sync.
Pilot
Wybierz jeden mały feature. Projekt w Figmie z nowym systemem. Generowanie kodu przez AI z MCP. Zmierz czas implementacji, ilość poprawek, jakość kodu. Zbierz feedback od zespołu.
Porównaj z poprzednimi projektami.
Liczby mówią same.
Timeline? 6-8 tygodni od audytu do pilota w optymistycznych warunkach. Koszt zależy od rozmiaru systemu. Ale ROI pojawia się szybko - średnio po 2-3 projektach z nowym systemem jesteś na plus.
Trzy błędy, które zniszczą wszystko
Widziałem wiele wdrożeń. Udane i totalnie spartaczone.
Trzy błędy powtarzają się w tych drugich.
Połowiczne wdrożenie
"Zrobimy Auto Layout w 80% komponentów."
Nie.
80% to za mało. AI trafi na te 20% i będzie halucynować. To jak łańcuch - pęka w najsłabszym ogniwie.
Albo 100%, albo nie warto zaczynać. Punkt.
Brak pilnowania
System jest gotowy. Wygląda pięknie w prezentacji. I co z tego?
Developer tworzy komponent "na szybko" bez zmiennych. Projektant "tylko tym razem" omija Auto Layout. Nikt nie pilnuje. Nikt nie reaguje.
Konsekwencja?
System degeneruje się w kilka chwil. Wszystko na marne.
Rozwiązanie - agenci linterzy, którzy automatycznie flagują odstępstwa. Code review z checklistą zgodności. Zero wyjątków. Zero "tylko tym razem".
Ignorowanie ludzi
To zmiana przepływu pracy. Projektanci muszą myśleć bardziej strukturalnie. Developerzy muszą zaufać AI. To nie jest komfortowe.
Bez onboardingu i szkoleń zespół będzie się opierać. Bo ludzie nie lubią zmian, które nie rozumieją.
Inwestuj w edukację. Pokazuj metryki. Celebruj szybkie wygrane. I słuchaj obiekcji - czasem są zasadne.
Co to znaczy dla twojego następnego projektu
Design system gotowy na AI to nie "nice to have". To przewaga konkurencyjna.
Kiedy twój zespół może przejść od projektu do działającego kodu w godzinach zamiast dni, zmieniają się reguły gry:
- Szybsze MVP
- Więcej iteracji w tym samym czasie
- Niższy koszt eksperymentów
- Wyższy morale zespołu (mniej frustracji z poprawkami)
Dla Product Ownera: możesz testować więcej hipotez w tym samym sprincie.
Dla Menadżera Projektu: ryzyko opóźnień spada, estymacje stają się precyzyjniejsze.
A to wszystko dzięki temu, że przestałeś traktować design system jak bibliotekę wzorców, a zacząłeś traktować go jak silnik kontekstu dla AI.
Następne kroki
Jeśli zarządzasz produktem z aktywnym rozwojem interfejsu, przeprowadź ten prosty test:
- Weź ostatni projekt przekazany do developmentu
- Zmierz czas od "projekt gotowy" do "kod w review"
- Policz rundy poprawek związane z niezgodnością design ↔ kod
- Zsumuj czas poświęcony na "tłumaczenie" designu na kod
Jeśli to więcej niż 20% całkowitego czasu developmentu - masz problem, który design system dla AI rozwiązuje.
We Wzorze 9 lat projektujemy interfejsy gotowe na wdrożenie. Ostatnio doszło coś nowego: projektujemy design systemy, które przyspieszają wdrożenie z AI. Jeśli chcesz zobaczyć, jak to działa w praktyce - umów bezpłatną konsultację.
Pokażemy ci dokładnie:
- Jak audytować twój obecny system
- Gdzie są największe luki dla AI
- Jaki ROI możesz oczekiwać w twoim kontekście
- Konkretny plan wdrożenia
Nasze projekty to wzór na sukces twojej firmy w świecie AI.
