Jak AI przejrzy projekt w Figmie, zbierze uwagi klienta i przygotuje listę zmian dla programisty?

Tak, Figma ma otwarte REST API i przez nie można wyciągnąć komentarze, treści wszystkich ramek oraz historię zmian w pliku. AI zbiera z tych danych nieodebrane uwagi klienta, sprawdza teksty na ekranach pod kątem literówek i niespójności, a na koniec generuje opis zmian dla programisty powiązany z konkretnymi stronami i komponentami. Firma dostaje mniej ręcznego przepisywania między designem a wdrożeniem.

Co mieści projekt w Figmie i które dane wyciągamy?

Figma organizuje pracę w kilku warstwach. Na górze jest Team i Project. W projekcie siedzą Files, czyli pliki projektowe. Każdy plik ma Pages (strony) i na każdej stronie są Frames (ramki), które najczęściej odpowiadają pojedynczym ekranom aplikacji lub serwisu. W ramkach siedzą Components, czyli wielokrotnie używane elementy, i Text nodes: nagłówki, etykiety przycisków, podpowiedzi w polach formularza, komunikaty błędów.

Do tego dochodzą Comments. Klient wchodzi do Figmy w trybie View, klika w konkretne miejsce na ekranie i zostawia komentarz. Może odpowiedzieć w wątku albo oznaczyć go jako Resolved. Niezrozwiązane wiszą dalej. W projektach po kilku tygodniach iteracji takich pinezek bywa kilkadziesiąt.

Przez API mamy dostęp do:

• pełnej struktury pliku z węzłami przez endpoint GET /v1/files/{file_key}
• wszystkich komentarzy, z informacją o tym, czy są rozwiązane i do którego węzła są przypięte: GET /v1/files/{file_key}/comments
• historii wersji pliku: GET /v1/files/{file_key}/versions
• listy plików w projekcie: GET /v1/projects/{project_id}/files
• webhooków na zdarzenia FILE_COMMENT i FILE_VERSION_UPDATE, żeby reagować na bieżąco zamiast odpytywać co godzinę

Czego API nie daje? Nie eksportuje grafik i prototypów w paczce. Dev Mode w interfejsie Figmy to nakładka widoku dla programisty: właściwości CSS i odległości odczytuje się bezpośrednio w przeglądarce lub pluginie, nie przez osobny endpoint. Variables API, wypuszczone w 2023, wymaga planu Professional lub wyższego.

Figma REST API: co trzeba mieć i do czego nie ma dostępu?

Figma udostępnia REST API na adresie https://api.figma.com/v1/. Każde zapytanie wymaga uwierzytelnienia przez nagłówek X-Figma-Token. Token generujecie w Ustawieniach konta, zakładka Security, przycisk "Create new token". Token należy do konkretnego użytkownika i ma dokładnie tyle uprawnień, ile ten użytkownik ma w zespole.

File key znajdziecie w URL-u otwartego pliku: figma.com/design/AbCd1234XyZ/Nazwa-pliku. Ten string wklejacie do każdego zapytania jako identyfikator.

Jakie uprawnienia są potrzebne? Do odczytu komentarzy i treści pliku wystarczy rola Viewer w zespole. Do zapisu, na przykład gdy AI ma oznaczyć komentarz jako rozwiązany po wdrożeniu, potrzeba roli Editor. Uprawnienia dla konta integracyjnego ustawia Owner lub Admin zespołu Figmy.

Webhooks działają w ten sposób: rejestrujecie webhook na zdarzenie FILE_COMMENT i od tej pory, gdy klient doda uwagę do pliku, Figma wysyła powiadomienie na Wasz endpoint. Zamiast odpytywać co godzinę, system reaguje od razu.

Typowo u klienta wygląda to tak: agencja tworzy w Figmie dedykowane konto integracyjne z rolą Viewer, generuje token, zapisuje go w zmiennej środowiskowej na serwerze i od tej pory AI może odpytywać pliki bez angażowania żadnego z projektantów. Poza API producent nie udostępnia dostępu do bazy danych ani eksportu pliku przez CLI. Wszystko przez zapytania HTTP, z limitem zapytań po stronie Figmy.

Komentarze bez odpowiedzi: jak AI zamienia chaos w listę poprawek?

Odpowiedź z endpointu comments to tablica obiektów. Każdy ma pola: id, message (treść komentarza), resolved_at (null, jeśli wisi nierozwiązany), parent_id (jeśli to odpowiedź w istniejącym wątku), user.name oraz client_meta.node_id, czyli identyfikator węzła w pliku, do którego komentarz jest przypięty.

Filtrowanie nierozwiązanych: bierzemy tylko rekordy, gdzie resolved_at jest null i parent_id jest null, bo pomijamy odpowiedzi w wątkach. Potem mapujemy node_id na nazwy ramek z drzewa pliku. W ten sposób wiemy, że dany komentarz dotyczy ramki "Krok 3 formularza" na stronie "Onboarding", a nie tylko że jest na współrzędnych (1240, 890) na canvasie.

Co robi AI z tymi danymi? Dostaje listę komentarzy z lokalizacją i grupuje je według tematu. Trzy uwagi o różnych problemach w jednym formularzu idą do grupy "Poprawki formularza rejestracji". Komentarze klienta dotyczące kolorów idą do grupy "Poprawki wizualne". AI może nadać każdemu priorytet na podstawie słów kluczowych: "błąd", "musi", "na pewno zmienić" to wyższy priorytet niż "może warto" albo "do rozważenia".

Efekt wygląda na przykład tak:

• Poprawki formularza rejestracji (strona: Onboarding, ramka: Krok 3): pole "Imię" powinno być wymagane. Klient: "użytkownik może pominąć imię i przejść dalej". Walidacja e-mail nie reaguje przy domenach .com.pl.
• Poprawki wizualne (strona: Strona główna): kolor przycisku CTA nie pasuje do palety z brand booka.

Coś, co ręcznie zajęłoby kilkanaście minut klikania po pliku, sprowadza się do jednego uruchomienia.

Teksty na ekranach: jak AI wyłapuje literówki i niespójności?

Węzeł tekstowy w Figmie ma typ TEXT i pole characters z dokładną treścią napisu. Przeczesując całe drzewo pliku, da się wyciągnąć każdy tekst w projekcie: nagłówki, etykiety przycisków, opisy pól, komunikaty błędów, placeholder teksty w polach input.

Po co to robić? Bo w projektach, które przeszły przez kilku projektantów i kilka miesięcy poprawek, terminologia się rozjeżdża. Jeden ekran mówi "Zaloguj się", inny "Zaloguj", jeszcze inny "Sign in", bo ktoś zapomniał podmienić angielski tekst po zmianie zakresu projektu. Przycisk akcji raz woła "Zapisz", raz "Zatwierdź", raz "Wyślij" w pozornie identycznych formularzach.

AI dostaje listę wszystkich tekstów z nazwami ramek i sprawdza:

• literówki i błędy gramatyczne, szczególnie w krótkich napisach, gdzie łatwo je przeoczyć
• spójność terminologii: czy "Użytkownik", "Klient" i "Account" nie opisują tej samej roli na różnych ekranach
• teksty angielskie w projekcie, który ma być w całości po polsku
• puste węzły TEXT (pole characters puste), które mogą oznaczać niezakończony ekran

U jednego klienta wyszło, że przycisk CTA na stronie cenowej mówił "Zamów teraz" na trzech ekranach i "Kup teraz" na dwóch. Sam w sobie nie byłby to błąd, gdyby nie fakt, że content designer założył pełną spójność pod planowane testy A/B. Bez wyciągnięcia wszystkich tekstów przez API nikt by tego nie złapał przed wdrożeniem.

Opis zmian dla programisty: co trafia do trybu przekazania?

Dev Mode w Figmie (dostępny od planu Professional) to widok, w którym programista widzi właściwości CSS, tokeny, odległości i wyeksportowane zasoby. Ale Dev Mode pokazuje stan aktualny. Nie mówi, co zmieniło się od ostatniego sprintu.

Tu wchodzi historia wersji. Endpoint versions zwraca listę zapisanych wersji pliku z opisami i datami. Porównując dwa wywołania GET /v1/files/{file_key} w różnych punktach w czasie, można wyłowić węzły, które zmieniły właściwości, nowe ramki i usunięte komponenty. AI na podstawie tej różnicy przygotowuje opis zmian w formacie, który programista wklei do ticket'u w Jirze albo do opisu pull requesta.

Przykładowy fragment takiego dokumentu:

• Ramka "Podsumowanie zamówienia": zaktualizowany tekst przycisku z "Złóż zamówienie" na "Zamów i zapłać". Node ID: 142:88
• Komponent "ProductCard": dodane pole "Dostępność" (node ID: 98:12). Wyświetlane jako tag pod ceną.
• Strona "Checkout" usunięta (była: krok pośredni potwierdzenia). Przepływ skrócony o jeden ekran.

Każda zmiana ma node_id, bo Dev Mode i pluginy Figmy linkują bezpośrednio po tym identyfikatorze. Programista klika i ląduje w dokładnie tym miejscu pliku, zamiast szukać przez kilkanaście stron projektu. Mniej niedoprecyzowanych konwersacji między projektantem a developerem, bo opis zmian powstaje automatycznie z danych pliku, nie z pamięci człowieka.

Od czego zaczynamy i co jest potrzebne?

Żeby integracja działała, potrzeba kilku rzeczy jednocześnie. Po stronie Figmy: konto z dostępem do pliku projektu, wygenerowany Personal Access Token i znany file_key. Jeśli chcecie reagować na komentarze na bieżąco, potrzeba miejsca na webhook: serwer albo usługa serverless z publicznym URL.

Po stronie AI: prompt, który wie, jak interpretować strukturę węzłów Figmy, jak grupować komentarze i w jakim formacie ma oddać listę poprawek albo opis zmian dla programisty. Plik JSON z odpowiedzią Figmy potrafi być duży przy rozbudowanych projektach. Warto przycinać go przed wysłaniem do modelu: bierzemy tylko interesujące typy węzłów (TEXT, FRAME, COMPONENT) i odcinamy dane renderowania, które są potrzebne przeglądarce, a nie AI.

Kto to uruchamia? W większości przypadków projektant albo lead developer konfiguruje token i skrypt raz, a potem system chodzi sam po każdym nowym komentarzu albo po zamknięciu iteracji. Firma nie musi mieć własnego programisty na etacie. Wystarczy ktoś, kto rozumie Figmę i może sprawdzić, że API zwraca dane. Resztę konfiguracji można przeprowadzić razem z nami.

Jeśli chcecie zobaczyć, jak taka integracja wygląda na realnym projekcie, zerknijcie na realne wdrożenia albo umówcie się na 15 minut rozmowy i pokażemy, jak to spina się z Waszym procesem designu.