Figma dla programisty, Dev Mode i zmienne

Figma dla programisty, czyli co naprawdę jest potrzebne

Programista nie musi umieć projektować w Figmie, ale musi umieć z niej czytać. Ten tekst pomija narzędzia rysowania i skupia się na tym, co przekłada się na kod: odczytywaniu miar, zmiennych, komponentów i na tym, dlaczego dobrze zbudowany plik projektowy oszczędza dni pracy przy wdrożeniu.

Najważniejsza zmiana ostatnich lat polega na tym, że Figma przestała być tylko obrazkiem do odwzorowania. Zmienne, tryb dla programistów i serwer w protokole MCP sprawiają, że plik projektowy jest źródłem danych, a nie tylko referencją wizualną.

Dev Mode, czyli tryb dla programisty

To osobny widok pliku, w którym zamiast narzędzi rysowania dostajesz to, co potrzebne do wdrożenia: wymiary, odstępy, kolory, typografię i wygenerowany fragment stylów.

Warto od razu ustalić jedną rzecz: wygenerowany kod jest podpowiedzią, a nie gotowym komponentem. Figma opisuje pojedynczy element w izolacji, nie zna Twojego systemu klas ani struktury komponentów, więc wklejenie wyniku wprost do projektu daje kod, który wygląda dobrze na jednym ekranie i rozjeżdża się przy zmianie rozmiaru.

Wartość tego trybu leży gdzie indziej. Po pierwsze, w porównywaniu wersji, bo widzisz, co zmieniło się od ostatniego przeglądu. Po drugie, w oznaczaniu ekranów jako gotowych do wdrożenia, co porządkuje pracę. Po trzecie, w dostępie do zmiennych, o których niżej.

W plikach zbudowanych porządnie każdy odstęp jest wielokrotnością wartości bazowej, a każdy kolor ma nazwę. Jeśli w Dev Mode widzisz odstępy w rodzaju siedemnastu i dwudziestu trzech pikseli, plik nie jest gotowy do wdrożenia i warto to zgłosić, zamiast odwzorowywać przypadkowe liczby.

Zmienne jako tokeny projektowe

To najważniejsza rzecz dla programisty i najczęściej niewykorzystana. Zmienne to nazwane wartości, których używa projekt: kolory, odstępy, promienie zaokrągleń, rozmiary tekstu.

Kluczowa właściwość to tryby. Jedna zmienna może mieć różne wartości w trybie jasnym i ciemnym, w wersji kompaktowej i luźnej, w różnych markach. Projektant przełącza tryb, a cały ekran się zmienia, dokładnie tak jak w kodzie z motywem.

Ten układ przekłada się wprost na zmienne CSS albo na konfigurację Tailwinda. Nazwa zmiennej w Figmie i nazwa w kodzie powinny być te same, bo wtedy rozmowa o zmianie sprowadza się do jednego słowa zamiast do opisywania koloru.

:root {
  --color-surface: #ffffff;
  --color-text-primary: #111827;
  --space-3: 12px;
  --radius-md: 8px;
}

[data-theme='dark'] {
  --color-surface: #111827;
  --color-text-primary: #f9fafb;
}

Zmienne da się wyeksportować przez API, więc synchronizacja z kodem może być procesem, a nie ręcznym przepisywaniem. To ma sens przy systemie projektowym używanym w kilku produktach, gdzie ręczna aktualizacja i tak by się rozjechała.

Jedno zastrzeżenie decyduje tu o wykonalności i warto je sprawdzić przed zaplanowaniem pracy: końcówki API dotyczące zmiennych są dostępne wyłącznie dla pełnoprawnych członków organizacji w planie korporacyjnym. Na planach niższych zmienne widzisz w interfejsie, ale nie pobierzesz ich programowo, więc zostaje eksport przez wtyczkę albo przepisywanie ręczne.

Samo pobranie jest jednym wywołaniem, uwierzytelnianym osobistym tokenem podawanym w nagłówku.

curl -H "X-Figma-Token: $FIGMA_TOKEN" \
  "https://api.figma.com/v1/files/$KLUCZ_PLIKU/variables/local"

Odpowiedź zawiera kolekcje zmiennych razem z trybami, więc jeden przebieg wystarcza, żeby zbudować z niej motyw jasny i ciemny naraz. Klucz pliku znajdziesz w jego adresie, między nazwą typu pliku a nazwą projektu.

Auto Layout i dlaczego to jest flexbox

Auto Layout to mechanizm układania elementów, który odpowiada temu, co robi flexbox w CSS. Kierunek, odstęp między elementami, wyrównanie i wypełnienie mają swoje bezpośrednie odpowiedniki.

Ta zgodność ma praktyczną konsekwencję. Ekran zbudowany na Auto Layout przekłada się na kod niemal jeden do jednego, a ekran zbudowany przez ustawianie elementów w dowolnych miejscach wymaga zgadywania, co ma się rozciągać, a co zostać.

Widać to najlepiej na przykładzie. Ramka pionowa z odstępem dwunastu pikseli, wypełnieniem szesnastu i jednym elementem ustawionym na wypełnianie kontenera zamienia się w kilka klas, bez ani jednej decyzji do podjęcia po drodze.

<div class="flex flex-col gap-3 p-4 items-stretch">
  <h2 class="text-lg font-semibold">Podsumowanie</h2>
  <p class="flex-1">Tresc rozciagajaca sie na dostepna wysokosc.</p>
  <button class="w-fit rounded-md px-3 py-2">Dalej</button>
</div>

Klasa na przycisku odpowiada ustawieniu dopasowania do treści, a klasa na akapicie ustawieniu wypełniania kontenera. To są te same dwie decyzje, które projektant podejmuje w panelu, więc przepisanie ich nie wymaga interpretacji.

Dlatego pytanie „czy ten ekran ma Auto Layout" jest sensownym pytaniem programisty do projektanta i wpływa na czas wdrożenia bardziej niż jakość grafiki.

Komponenty i warianty

Komponent w Figmie odpowiada komponentowi w kodzie, a warianty odpowiadają jego propsom. Przycisk z wariantami dla rozmiaru, stanu i typu to dokładnie ten sam model, co komponent przyjmujący trzy właściwości.

Ta zgodność jest wygodna, dopóki obie strony trzymają te same nazwy. Jeśli w projekcie wariant nazywa się „primary", a w kodzie „default", każda rozmowa o zmianie wymaga tłumaczenia. Ustalenie wspólnego słownika na początku kosztuje godzinę i oszczędza tygodnie nieporozumień.

Bywa też, że biblioteka komponentów w pliku nie powstała u Ciebie, tylko pochodzi z zewnętrznego zbioru w rodzaju Relume, który dostarcza gotowe sekcje strony jako komponenty z wariantami. Dla programisty to praktyczna informacja: struktura i nazwy powtarzają się wtedy między projektami, ale powtarza się też wygląd, więc przed wyceną warto zapytać, które sekcje są świadomą decyzją, a których nikt jeszcze nie przerobił po wstawieniu z katalogu.

Warto też zwrócić uwagę na to, czego w projekcie nie ma. Plik pokazuje zwykle stan docelowy, a kod musi obsłużyć stan ładowania, stan pusty, błąd i tekst dłuższy niż przewidziany. Te cztery przypadki warto wyprosić u projektanta przed rozpoczęciem pracy, bo dopisywanie ich później zawsze wychodzi gorzej.

Serwer MCP i praca z asystentem kodu

Figma udostępnia serwer w protokole MCP, dzięki czemu asystent kodu może odczytać zaznaczoną ramkę: jej strukturę, zmienne, odstępy i nazwy komponentów.

Zmienia to sposób pracy, bo zamiast opisywać w prompcie, jak ma wyglądać ekran, wskazujesz go w projekcie. Asystent w Cursorze albo w innym narzędziu dostaje dane, a nie opis, więc generuje kod bliższy zamierzeniu.

Granica jest jednak podobna jak przy generowanym kodzie w trybie dla programisty. Asystent zna wygląd, ale nie zna Twoich konwencji, dopóki mu ich nie podasz. Reguły projektu opisujące system klas, strukturę komponentów i zasady nazewnictwa robią tu większą różnicę niż sam dostęp do pliku.

Warianty serwera są dwa i różnią się dostępnością. Wariant zdalny, pod adresem dostawcy, działa na wszystkich rodzajach miejsc i wszystkich planach, także darmowym. Wariant uruchamiany przez aplikację na komputerze wymaga miejsca projektowego albo pełnego i planu płatnego. Przy wdrożeniu w zespole zacznij od zdalnego, bo nie wymaga niczego poza zalogowaniem.

Podłączenie wariantu zdalnego to jedno polecenie albo kilka wierszy w konfiguracji klienta.

claude mcp add --scope user --transport http figma https://mcp.figma.com/mcp

W narzędziach konfigurowanych plikiem ten sam serwer opisujesz wprost, podając adres i rodzaj połączenia.

{
  "servers": {
    "figma": {
      "url": "https://mcp.figma.com/mcp",
      "type": "http"
    }
  }
}

Po podłączeniu asystent czyta zaznaczoną ramkę, sięga po zmienne i układ, a przy skonfigurowanym powiązaniu komponentów potrafi wskazać, który komponent w kodzie odpowiada temu z projektu.

Ograniczenia i siatka odstępów

Ograniczenia decydują o tym, co dzieje się z elementem, gdy zmienia się rozmiar ramki nadrzędnej. Przypięcie do lewej krawędzi, rozciąganie na całą szerokość, wyśrodkowanie: to informacja, której na statycznym obrazku nie widać, a która wprost przekłada się na zachowanie w przeglądarce.

Sprawdzenie ich zajmuje chwilę i oszczędza rundę poprawek. Element bez ustawionych ograniczeń zachowa się przy zmianie rozmiaru inaczej, niż projektant zakładał, więc rozbieżność między projektem a wdrożeniem bierze się często stąd, a nie z błędu w kodzie.

Osobną sprawą jest siatka odstępów. Dobrze zbudowany projekt opiera się na jednej wartości bazowej, zwykle czterech albo ośmiu pikselach, i wszystkie odstępy są jej wielokrotnościami. To nie jest estetyczna fanaberia, tylko warunek, żeby dało się je zamienić na skalę w kodzie.

Jeśli w projekcie widzisz odstępy niepasujące do żadnej skali, masz dwie drogi. Pierwsza to zaokrąglenie do najbliższej wartości ze skali i poinformowanie o tym, druga to zapytanie, czy odstęp jest zamierzony. Wpisanie przypadkowej liczby do kodu jest najgorszym wyborem, bo utrwala pomyłkę.

Trzecia rzecz to punkty przełamania. Projekt zwykle pokazuje dwa albo trzy rozmiary ekranu, a przeglądarka ma ich nieskończenie wiele. Warto ustalić, co ma się dziać pomiędzy nimi, bo to obszar, w którym decyzje i tak podejmie programista, tyle że bez konsultacji.

Ceny i rodzaje miejsc

Plan darmowy pozwala poznać narzędzie, ale ogranicza liczbę plików. Stawki powyżej dotyczą rozliczenia miesięcznego; roczne jest tańsze, a plany Organization i Enterprise rozlicza się wyłącznie rocznie. Miejsce w trybie samego odczytu nie kosztuje nic na żadnym planie płatnym.

Dla zespołu programistycznego najważniejsza jest ta tabela, a nie sam plan. Osoba, która wyłącznie odczytuje projekty i wdraża je w kodzie, nie potrzebuje pełnego miejsca. Zamiana pięciu pełnych miejsc na miejsca dla programisty daje na planie Professional dwieście czterdzieści dolarów rocznie, ale na Organization już tysiąc osiemset, a na Enterprise trzy tysiące trzysta. Im większa organizacja, tym bardziej rozjeżdżają się stawki obu rodzajów miejsc, więc przegląd przydziału opłaca się dokładnie tam, gdzie najczęściej nikt go nie robi.

Przy planie Professional rozliczenie roczne obniża stawkę wobec miesięcznego, co przy stabilnym zespole jest oczywistym wyborem. Warto tylko wiedzieć, że miejsca dodane w trakcie roku rozlicza się wtedy osobno miesięcznie, dopóki nie dopiszesz ich do subskrypcji rocznej.

Warto raz na kwartał przejrzeć listę osób i ich rodzaje miejsc, bo w rosnącym zespole miejsca przydzielane są zwykle najhojniej i nikt do tego nie wraca. Osoba, która przez pół roku ani razu nie edytowała pliku, nie potrzebuje pełnego dostępu, a zmiana rodzaju miejsca jest odwracalna, więc ryzyko takiej korekty jest niewielkie.

Jeśli rachunek za miejsca okaże się trudny do obrony, sprawdź Penpot. To narzędzie o otwartym kodzie, które postawisz na własnym serwerze, a jego plan darmowy obejmuje do ośmiu projektujących bez limitu oglądających. Nie ma Dev Mode w tej postaci, ale format plików stoi na standardach sieciowych, więc eksport idzie wprost do kodu.

Czego w projekcie nie ma nigdy

Warto mieć listę rzeczy, które trzeba doprecyzować, zanim zaczniesz kodować. Powtarzają się w każdym projekcie i nikt ich nie rysuje.

Dostępność to pierwsza pozycja. Kolejność przechodzenia klawiszem tabulacji, widoczny wskaźnik ogniska, etykiety dla czytników ekranu i kontrast tekstu wobec tła. Kontrast da się sprawdzić w Figmie, reszta wymaga decyzji, którą podejmie programista.

Druga pozycja to zachowanie w czasie. Ile trwa przejście, czy lista pojawia się od razu, czy z opóźnieniem, co widzi użytkownik przez pierwsze trzysta milisekund. Projekt statyczny tego nie mówi, a różnica między dobrym a złym wrażeniem leży często właśnie tutaj.

Trzecia to walidacja formularzy. Kiedy pojawia się komunikat o błędzie, przy opuszczeniu pola czy przy wysłaniu, co dzieje się z polem poprawionym i jak zachowuje się formularz z pięcioma błędami naraz.

Czwarta to treść. Teksty w projekcie są zwykle krótsze niż prawdziwe, więc nazwa produktu na sześćdziesiąt znaków rozwali układ, jeśli nikt tego nie przewidział. Warto sprawdzić przypadki skrajne, zanim zrobi to użytkownik.

Piąta to uprawnienia. Ekran pokazuje widok osoby, która może wszystko, a w aplikacji część użytkowników nie zobaczy połowy przycisków. Trzeba ustalić, co się z nimi dzieje: znikają czy są nieaktywne.

Typowe błędy przy współpracy

Pierwszy to wklejanie kodu z trybu dla programisty wprost do projektu. Figma opisuje element w izolacji, więc taki kod ignoruje Twój system klas i rozpada się przy zmianie rozmiaru okna.

Drugi to odwzorowywanie przypadkowych liczb. Odstęp siedemnastu pikseli w projekcie to zwykle pomyłka, a nie decyzja, i lepiej zapytać, niż wpisać ją do kodu na stałe.

Trzeci to brak ustalonego słownika nazw. Ten sam kolor nazywany inaczej po obu stronach zamienia każdą rozmowę o zmianie w tłumaczenie.

Czwarty to pomijanie stanów brzegowych. Ładowanie, pusta lista, błąd i długi tekst to cztery przypadki, których w projekcie zwykle nie ma, a w kodzie muszą być.

Piąty to kupowanie pełnych miejsc dla całego zespołu. Programista odczytujący projekty potrzebuje miejsca tańszego, a różnica przy dziesięciu osobach jest odczuwalna w budżecie rocznym.

Szósty to praca na pliku bez Auto Layout. Taki ekran wymaga zgadywania, co ma się rozciągać, więc wdrożenie trwa dłużej i kończy się poprawkami po pierwszym teście responsywności.

FAQ

Czy programista potrzebuje płatnego konta Figmy?

Do odczytywania projektów i pracy w trybie dla programisty potrzebne jest miejsce typu Dev, tańsze od pełnego. Plan darmowy pozwala oglądać pliki udostępnione, ale bez pełnego dostępu do trybu dla programisty, więc w zespole produkcyjnym zwykle wykupuje się miejsca dedykowane.

Czy kod generowany przez Figmę nadaje się do użycia?

Jako podpowiedź wartości tak, jako gotowy komponent nie. Figma opisuje element w izolacji i nie zna Twojego systemu klas ani struktury komponentów, więc wynik traktuj jak źródło wymiarów i kolorów, a nie jak kod do wklejenia.

Do czego służą zmienne w Figmie?

Do tego samego, co tokeny projektowe w kodzie: przechowują nazwane wartości kolorów, odstępów i rozmiarów, z możliwością różnych wartości w różnych trybach. Odpowiadają zmiennym CSS, więc przy wspólnym nazewnictwie synchronizacja projektu z kodem staje się procesem, a nie ręcznym przepisywaniem.

Co daje serwer MCP?

Pozwala asystentowi kodu odczytać zaznaczoną ramkę razem ze strukturą, zmiennymi i nazwami komponentów, zamiast opierać się na opisie w prompcie. Efekt jest zauważalnie lepszy, pod warunkiem że asystent zna też konwencje Twojego projektu, bo sam wygląd nie wystarczy.

Jak sprawdzić, czy plik jest gotowy do wdrożenia?

Trzy pytania wystarczą. Czy ekrany mają Auto Layout, czy kolory i odstępy pochodzą ze zmiennych, czy istnieją stany brzegowe. Odpowiedź przecząca na którekolwiek z nich oznacza, że część pracy projektowej trafi na programistę, i lepiej ustalić to przed rozpoczęciem niż w trakcie.

Dokumentację trybu dla programisty znajdziesz w centrum pomocy Figmy, a aktualne stawki na stronie cennika.