Figma MCP to serwer (Figma MCP server), który łączy Claude Code z Twoimi plikami w Figmie. Podłączasz go jedną komendą, a Claude czyta prototypy, wyciąga z nich kolory, fonty i odstępy i buduje widoki według nich, zamiast zgadywać. To pierwszy z czterech kroków, które sprawiają, że apka budowana z AI wygląda jak jedna całość, a nie jak zlepek ekranów.
Ostatnio miałem kilka rozmów z osobami, które budują w Claude Code i miały dokładnie ten sam problem. Promptowały o jeden spójny design, a i tak każdy nowy widok wyglądał trochę inaczej. Z doświadczenia powiem tak: zachowanie jednolitego wyglądu, który nie jest typowym slopem, nie jest łatwe. Ale nie jest niemożliwe. Poniżej masz cztery kroki, które u mnie robią robotę.
01. Dlaczego apka budowana z AI rozjeżdża się wizualnie
Bo Claude nie ma gdzie sprawdzić, jak ma wyglądać Twoja apka. Prompt „zrób spójny design" to za mało: model dostaje ogólne polecenie i za każdym razem sam wymyśla, co znaczy „spójny". Raz zaokrągli rogi na 8 px, raz na 12. Raz weźmie szary z Tailwinda, raz z własnej głowy. Po pięciu widokach masz pięć wersji tego samego przycisku.
Drugi powód jest jeszcze prostszy: większość osób buduje logikę i widoki jednocześnie. Claude pisze funkcję, dokleja do niej ekran, potem następną funkcję i następny ekran. Nikt nie zatrzymał się na początku i nie ustalił, jak całość ma wyglądać. Wygląd powstaje przy okazji, a przy okazji rzadko wychodzi dobrze.
Cztery kroki poniżej odwracają tę kolejność.
02. Co to jest Figma MCP server i do czego służy
Figma MCP server to oficjalny serwer MCP od Figmy, który daje agentom AI dostęp do Twoich plików projektowych (Figma design files). MCP (Model Context Protocol) to otwarty standard, przez który narzędzia takie jak Claude Code, Cursor, Codex czy VS Code z Copilotem podłączają zewnętrzne źródła danych. Pełną listę obsługiwanych klientów Figma trzyma w swoim MCP catalog. Figma MCP server jest jednym z takich źródeł: MCP client (u nas Claude Code) pyta go o wybrany frame w pliku Figmy, a w odpowiedzi dostaje design context: kolory, komponenty, warstwy, odstępy i zrzut ekranu.
Serwer działa w dwóch wersjach. Zdalny (remote MCP server, mcp.figma.com/mcp) nie wymaga instalacji, działa na każdym planie i potrafi też tworzyć oraz modyfikować zawartość bezpośrednio w pliku Figmy. Lokalny (desktop MCP server) siedzi w aplikacji desktopowej Figmy (Figma desktop app) i wymaga płatnego miejsca Dev lub Full. Do tego dochodzi Code Connect, czyli mapowanie komponentów z Figmy na komponenty w Twoim kodzie, dzięki któremu Claude używa gotowego przycisku z repo zamiast rysować nowy.
W praktyce Figma MCP server wpina Figmę w Twój workflow z Claude Code i zamienia prototyp w źródło prawdy: zamiast opisywać Claude'owi, jak ma wyglądać ekran, pokazujesz mu Figma design i mówisz „zrób to".
03. Krok 1: Zacznij od wyglądu: Mobbin i Figma MCP w Claude Code
Najpierw wygląd, potem kod. Inspirację bierzesz z Mobbin, prototypy robisz w Figmie, a Claude Code dostaje do nich dostęp przez MCP. Jeżeli dotychczas budowałeś tak, że jednocześnie tworzyłeś logikę i dokładałeś widoki, to nie jest najlepsza droga. Zacznij od inspiracji.
Inspiracja: Mobbin MCP
Jest fajna stronka, która nazywa się Mobbin. To agregator ponad 600 tysięcy zrzutów ekranu z prawdziwych aplikacji, poukładanych według branż i wzorców (onboarding, koszyk, ustawienia, strona 404). Ma oficjalny MCP, który podpinasz pod Claude'a jedną komendą:
claude mcp add mobbin --scope user --transport http https://api.mobbin.com/mcpPotem Claude sam wyszukuje po słowach kluczowych, przegląda, jak wyglądają różne apki i podpowiada, jaki wygląd pasuje pod Twój pomysł. Możesz też sam poprzeglądać i wybrać coś dla siebie. Jedna uwaga: dostęp do MCP jest w płatnych planach Mobbin (Pro i Team), darmowe konto pozwala tylko przeglądać stronę.
Prototyp: jak podłączyć Figma MCP server do Claude Code
Jak masz inspirację, wchodzi Figma. I spokojnie, nie musisz uczyć się ręcznie budować mockupów. Instalujesz Figmę jako apkę na komputerze (Figma desktop app), dodajesz połączenie z Figma MCP server do Claude Code i w Figmie trzymasz wszystkie prototypy. Cały design Twojej apki żyje w jednym pliku Figmy.
Podłączenie zajmuje minutę:
claude mcp add --scope user --transport http figma https://mcp.figma.com/mcpPotem w Claude Code wpisujesz /mcp, wybierasz Figmę i klikasz Authenticate. Otwiera się przeglądarka, klikasz Allow Access i widzisz komunikat „Authentication successful. Connected to figma". Od tej chwili Claude może:
- czytać kontekst wybranego frame'a (kolory, komponenty, układ, odstępy) i pisać pod niego kod,
- robić zrzuty ekranu prototypu i porównywać je z tym, co zbudował,
- generować nowe widoki bezpośrednio w Figmie na podstawie Twojego opisu albo działającej strony (wersja zdalna serwera).
Figma udostępnia dwa serwery: remote MCP server (mcp.figma.com/mcp, działa na każdym planie i ma więcej funkcji) oraz desktop MCP server w aplikacji desktopowej (tylko płatne plany z miejscem Dev lub Full). Polecam zdalny. Limity są zależne od miejsca: na darmowym Starterze z miejscem View masz do 20 wywołań miesięcznie, z miejscem Dev lub Full do 200 dziennie. Na Starterze z 20 wywołaniami zrobisz jeden mały projekt, do regularnej pracy potrzebujesz miejsca Dev.
Wiem, że jest v0, które robi podobną rzecz, ale z mojego doświadczenia Figma po prostu działa lepiej. Claude świetnie się z nią dogaduje: tworzy wstępne prototypy szybko i dokładnie, a poprawki wprowadza od ręki.
Po co Ci prototypy? Jak zobaczysz wcześniej, jak będzie wyglądała apka, zaoszczędzisz masę tokenów na późniejszych poprawkach. Stwórz prototypy, obejrzyj je, powiedz Claude'owi, co jest okej, a co nie, i dojdźcie do konsensusu, zanim powstanie linijka kodu.
04. Krok 2: Spisz design.md, jedno źródło prawdy o stylu
Masz prototypy poszczególnych widoków? Teraz stwórz plik design.md. To koncepcja od Google Labs: jeden plik, który trzyma wszystkie najważniejsze informacje o Twoim stylu w jednym miejscu, a Claude traktuje go jako źródło prawdy przy każdej poprawce, zmianie czy nowym widoku.
W środku design.md ma dwie warstwy. Na górze YAML z tokenami (kolory, fonty, rozmiary, zaokrąglenia, cienie), pod spodem zwykły tekst w ośmiu sekcjach: Overview, Colors, Typography, Layout, Elevation, Shapes, Components i Do's and Don'ts. Tokeny dają Claude'owi dokładne wartości, a opisy tłumaczą, dlaczego te wartości istnieją i kiedy ich używać.
Nie musisz tego pisać ręcznie. Wystarczy, że napiszesz w Claude Code: „na podstawie tych prototypów w Figmie stwórz plik design.md według specyfikacji z repo google-labs-code/design.md". Możesz podać mu to repo bezpośrednio jako wzór.
Najlepiej zrób z tego skilla, żeby za każdym razem była to powtarzalna operacja. I dopisz w CLAUDE.md jedno zdanie: przy każdej modyfikacji widoków Claude ma wracać do design.md. Bez tego zdania plik będzie leżał w repo i nikt go nie przeczyta.
05. Krok 3: Zbuduj Claude'owi harness: dokumentacja przed kodem
Jeżeli wydaje Ci się, że powyższe załatwi wszystko, to się mylisz. Teraz fundament: sposób, w jaki Claude Code pracuje. Wszystko rozchodzi się o kontekst i o zbudowanie środowiska, które trzyma go w ryzach przy wykonywaniu zadań.
Mój szablon pracy z Claude Code jest publiczny: claude-code-starter na GitHubie. U mnie większość roboty to przygotowanie dokumentacji dla Claude'a, a potem sprawdzanie jego pracy. Oczywiście wcześniej wykonują się testy, w tym end-to-end, ale sam też weryfikuję, żeby mieć 100% pewności.
Jak to wygląda w praktyce? Zanim Claude napisze kod czy widok, przechodzi przez fazy: doprecyzowanie wymagań, plan techniczny podzielony na etapy, dopiero potem implementacja i automatyczne review (cały proces w sześciu krokach opisałem osobno). Każde zdanie w zadaniu odwołuje się do konkretnej instrukcji. Claude dostaje krok po kroku, co ma wykonać w poszczególnych fazach. Ma odwołanie do Figmy, widzi prototyp, ma zrzuty ekranu i może je obejrzeć.
Dzięki temu każdy wdrażany widok ma odwołanie do konkretnych materiałów. Zawężamy pole do losowych czynności, które Claude wykonuje, gdy brakuje mu informacji. A losowe czynności to właśnie te momenty, w których pojawia się trzeci odcień szarego.
06. Krok 4: Testuj end-to-end po każdej zmianie
Po każdej skończonej pracy Claude powinien sam odpalić aplikację, obejrzeć, co zrobił, przeklikać wszystko i od razu nanieść poprawki. Niezależnie czy to testy w przeglądarce, czy na aplikacji mobilnej w symulatorze.
W moim szablonie robi to osobny agent: uruchamia apkę w prawdziwej przeglądarce, przechodzi scenariusz oznaczony jako E2E i porównuje wynik z prototypem z Figmy (visual diff kodu vs Figma design). Jeśli przycisk ma inny kolor niż w projekcie, wychodzi to tutaj, a nie tydzień później u użytkownika.
To nie wyklucza Twojej pracy: potem i tak zweryfikuj ręcznie. Ale ten poziom sprawdzenia mocno wpływa na wynik, który dostaniesz.
07. Jak to wygląda u mnie
Ten proces sprawdzałem na własnej aplikacji mobilnej (Nawykometr), którą buduję w Claude Code na potrzeby kursu. Zanim wprowadziłem prototypy w Figmie i design.md, poprawki wyglądu zjadały mi więcej tokenów niż sama logika: każdy nowy ekran wymagał dwóch, trzech rund „a teraz zrób to tak jak na poprzednim". Po zmianie kolejności pracy nowy widok wchodzi zwykle za pierwszym razem, a Claude sam wraca do design.md, zanim cokolwiek narysuje.
Jeden błąd, który popełniłem po drodze: prototyp w Figmie miał tło w czystej bieli, a apka w kodzie dostała lekko ciepły odcień z Tailwinda. Claude uznał obie wersje za „białe". Od tego czasu kolory w design.md podaję jako konkretne wartości hex, nie jako nazwy.
08. Dwa bonusowe tipy
Zamiast streszczać cztery kroki, dwie rzeczy, które dokładam na końcu:
- Wklejaj zrzuty ekranu, nie opisuj. Jeśli widok się rozjechał, zrób screenshot rozjazdu i wrzuć go do Claude Code obok zrzutu z Figmy. Model widzi różnicę szybciej, niż Ty ją opiszesz słowami.
- Jeden zestaw komponentów bazowych. Przycisk, karta, pole formularza i nagłówek niech żyją w jednym miejscu w kodzie, a w CLAUDE.md dopisz, że nowe widoki mają z nich korzystać, a nie tworzyć własne. Spójny design to w połowie kwestia tego, żeby Claude nie miał powodu wymyślać przycisku na nowo.
Najczęstsze pytania o Figma MCP w Claude Code