Poniższy artykuł stanowi notatki z praktycznej prezentacji autorki pokazującej przepływ pracy przy tworzeniu interaktywnych komponentów systemu projektowego. Wszystkie opisane metody, obserwacje i przemyślenia pochodzą bezpośrednio z materiału źródłowego.

TL;DR

Cursor z Figmą MCP automatyzuje przejście od designu do kodu – komponenty z pełną interaktywnością powstają w kilka minut
Wybór modelu AI ma kluczowe znaczenie – Gemini 2.5 Pro lepiej wyciąga tokeny projektowe niż Claude Sonnet
Tokeny projektowe w Figmie muszą być prawidłowo zdefiniowane – bez tego AI nie wyciągnie poprawnych wartości kolorów i odstępów
Proces wymaga iteracji i cierpliwości – pierwszy prompt rzadko daje idealny rezultat
Praktyczne rozwiązywanie problemów to podstawa – czyszczenie plików Figma, zmiana modeli, kopiowanie właściwych linków
Lovable.dev to szybsza alternatywa – mniej precyzyjna, jednak komponenty gotowe w 2 minuty
20 minut vs tradycyjne metody – znacząca oszczędność czasu przy tworzeniu komponentów UI

Nowa era w designie: od prototypu do kodu w minuty

Tradycyjny proces przekazywania komponentów systemu projektowego od designerów do deweloperów to często tygodnie pracy. Autorka prezentacji demonstruje radykalnie inną metodę – wykorzystanie Cursor z Figmą MCP do automatycznego generowania funkcjonalnego kodu bezpośrednio z prototypów.

Dlatego też opisywany przepływ pracy pozwala stworzyć nie tylko statyczne komponenty, ale pełnoprawne, interaktywne elementy UI z efektami najechania kursorem, wyszukiwaniem i różnymi wariantami.

Pierwszy krok: konfiguracja i podstawowy komponent

Autorka zaczyna od stworzenia prostego komponentu tagów, pokazując cały proces od początku.

Przygotowanie obszaru roboczego

Po połączeniu Figma MCP z Cursor, proces zaczyna się od utworzenia nowego folderu projektu, wklejenia przygotowanego prompta i dodania linku do odpowiednich ramek w Figmie.

Autorka podkreśla przy tym: „Ważne jest, żeby eksperymentować z różnymi modelami”.

Pierwszy rezultat i jego problemy

Pierwsze generowanie dało komponenty z pięcioma wariantami kolorów, trzema rozmiarami i różnymi stylami. Jednak autorka zauważa znaczące różnice:

Nieprawidłowe kolory tagów
Błędny border radius
Niewłaściwe efekty najechania kursorem (shadow zamiast czystego stylu)
Problematyczna typografia

Kluczowa lekcja: modele AI działają różnie

Autorka napotkała pierwszy poważny problem – Cursor z modelem Claude Sonnet nie potrafił prawidłowo odczytać tokenów projektowych z Figmy.

Rozwiązanie przez zmianę modelu

Po przełączeniu na Gemini 2.5 Pro sytuacja zmieniła się dramatycznie. Autorka relacjonuje: „Gdy zmieniłam na Gemini, natychmiast otrzymałam powiadomienie o analizie przez siedem sekund i oczywiście teraz spróbuje wyciągnąć zmienne projektowe. Jak widać tutaj – doskonale. Udało mi się w pełni wyciągnąć”.

W rezultacie Gemini skutecznie wyciągnął wszystkie tokeny projektowe: kolory, odstępy, nazewnictwo komponentów.

Kluczowe wskaźniki sukcesu: Autorka podkreśla, że gdy model „myśli przez siedem sekund” i wyświetla komunikat o pełnym wyciągnięciu danych – to dobry znak prawidłowego pobrania wszystkich tokenów projektowych.

Dalsze iteracje i dopracowanie

Mimo poprawy komponenty nadal wymagały dopracowania. Dlatego autorka użyła screenshota do pokazania konkretnych problemów:

Nieprawidłowa typografia
Niechciane efekty cienia
Potrzeba zunifikowania tekstów

Po kolejnej iteracji otrzymała już prawidłowo działające komponenty z tokenami projektowymi i specyfikacjami.

Istotne odkrycia autorki podczas pracy

Interpretacja AI: Autorka zauważa nieprzewidywalność w interpretacji: „Nie wiem dlaczego mamy pill css, ale prawdopodobnie tak Cursor zrozumiał przepływ pracy” – co pokazuje, jak AI może niespodziewanie interpretować instrukcje.

Różnice w komunikacji modeli: Każdy model AI ma inny sposób wyjaśniania swoich działań. Claude Sonnet nie opisuje wszystkiego tak szczegółowo jak Gemini, który z kolei dostarcza więcej kontekstu o tym, co dzieje się w tle.

Reużywalność promptów: Autorka podkreśla, że „następnym razem wystarczy ponownie użyć tego samego prompta dla każdego innego komponentu” – jeden dobrze opracowany prompt można wykorzystać wielokrotnie.

⚠️ Krytyczne ostrzeżenia o tokenach projektowych

Problem z niezdefiniowanymi nazwami: Autorka ostrzega – „Bądź ostrożny, jeśli nie masz nazw dla tokenów projektowych tutaj, a faktycznie zdefiniowałeś zmienne Figma lub tokeny projektowe w Figmie, musisz wrócić i poinstruować Cursor, żeby sprawdził co się dzieje i być bardzo konkretnym z używaniem kolorów i tokenów projektowych. W przeciwnym razie prawdopodobnie ich w ogóle nie sprawdził”.

Kontrola nad CSS: Możesz instruować Cursor o nazwach klas CSS – autorka wyjaśnia, że można „poinstruować Cursor, jakie mają być nazwy klas, a wszystko wygeneruje się automatycznie”.

Nie wszystko musi być tokenami: Autorka celowo nie zdefiniowała wszystkiego jako tokeny projektowe, pokazując że można mieć mieszane podejście.

Zaawansowany przykład: menu rozwijane z wyszukiwaniem

Autorka przechodzi do znacznie bardziej złożonego komponentu – rozwijanej listy z funkcją wyszukiwania.

Warianty i ich różnice

Prezentowane są pięć różnych wersji menu rozwijanego:

Wersja 1: ikony po lewej stronie, kategoria na górze, zaznaczony element na niebiesko
Wersja 3: ikony po prawej stronie, zaznaczenie przez checkmark zamiast koloru
Wersja 5: najgęstsza wersja z mniejszą wysokością rzędów (32px zamiast 40px)

Techniczne szczegóły implementacji

Autorka używa vanilla JavaScript dla interakcji, Font Awesome dla ikon oraz konkretne instrukcje dla tokenów projektowych – 300px szerokości i różne wysokości dla poszczególnych wersji. Wymogi UX obejmują funkcję wyszukiwania, efekty najechania kursorem i responsywność.

Spójność ikon w systemie projektowym: Autorka dodaje specjalną instrukcję dla Cursor, ponieważ „dziwnie wygląda, gdy masz różne ikony, które w designie używamy interfont przez Google” – podkreślając wagę konsistencji.

Filozofia przepływu pracy według autorki

Kolejność ma znaczenie: Autorka podkreśla: „Ważne jest, żeby najpierw zacząć od Figmy, dodać tam szczegóły, a potem się z tym bawić” – najpierw design, potem kod.

Testowanie przez użytkowanie: Autorka podkreśla, że menu rozwijane „było już otwarte. Ale jeśli chcesz porównać funkcjonalność, najlepiej działa gdy klikasz jako użytkownik, przeszukujesz, masz efekt najechania kursorem, masz funkcję wyszukiwania, i dopiero wtedy możesz zdecydować co działa najlepiej”.

Przepływ pracy z zespołem: Zaleca „zrobić to na osobnym ekranie, żeby zobaczyć którą wersję preferujesz, a potem przekazać tę wersję deweloperom” – testowanie przed przekazaniem do implementacji.

Rezultaty i dalsze możliwości

Autorka podkreśla, że proces zajął około 20 minut dla dwóch pełnoprawnych komponentów z pełną interaktywnością i specyfikacjami.

Alternatywa: Lovable.dev

Jako bonus autorka testuje Lovable.dev – konkurencyjne narzędzie.

Porównanie szybkości vs precyzji

Lovable.dev oferuje znacznie szybsze rezultaty – komponenty gotowe w 2 minuty, jednak za cenę mniej precyzyjnego odwzorowania designu. Brakuje możliwości wyciągnięcia custom tokenów projektowych, choć narzędzie jest prostsze w użyciu dla szybkich prototypów.

Kiedy wybrać które narzędzie

Autorka preferuje Cursor ze względu na integrację z GitHub, większą kontrolę nad kodem, możliwość tworzenia bardziej złożonych komponentów i lepsze wsparcie dla systemów projektowych.

Realistyczne oczekiwania: W przypadku Lovable autorka przyznaje – „Nie przeszkadza mi używanie różnych ikon, ponieważ prawdopodobnie nie używają Font Awesome w tle dla dwuminutowej pracy. Myślę, że to świetne” – podkreślając, że dla szybkich prototypów można zaakceptować mniejszą precyzję.

Praktyczne wskazówki i rozwiązywanie problemów

Najważniejsze zasady według autorki

Przygotowanie plików Figma wymaga usuwania zbędnych elementów z pliku, prawidłowego definiowania zmiennych/tokenów projektowych i kopiowania linków do konkretnych selekcji, nie całych plików.

Praca z AI to przede wszystkim eksperymentowanie z różnymi modelami, używanie screenshotów do precyzyjnego komunikowania problemów oraz wytrwałość. Jak podkreśla autorka: „nie poddawaj się, gdy model nie działa”.

Iteracyjne podejście jest kluczowe, ponieważ pierwszy prompt rzadko daje idealny rezultat. Dlatego też potrzebna jest cierpliwość i systematyczne dopracowywanie, a w przypadku problemów pomocny może być reset chatu lub zmiana modelu.

Testowanie wielu wersji: Autorka sugeruje „dodać kilka ekranów, żeby przetestować co działa najlepiej” – tworzenie różnych wariantów do porównania przed finalną decyzją.

✅ Checklist: rozwiązywanie problemów gdy coś nie działa

Gdy AI nie generuje prawidłowych komponentów:

☐ Zmień model AI – spróbuj Gemini 2.5 Pro zamiast Claude Sonnet
☐ Sprawdź link do Figmy – czy wskazuje na właściwą selekcję?
☐ Wyczyść plik Figma – usuń zbędne elementy i komponenty
☐ Zrób screenshot – pokaż AI konkretnie co jest nie tak
☐ Zrestartuj chat – czasem pomaga rozpoczęcie od nowa
☐ Sprawdź tokeny projektowe – czy są prawidłowo zdefiniowane w Figmie?

✅ Wskaźniki sukcesu – jak rozpoznać że wszystko działa

Pozytywne sygnały: ☐ Model wyświetla „myśli przez siedem sekund” przy analizie
☐ Komunikat „udało mi się w pełni wyciągnąć” zmienne projektowe
☐ „otrzymanie kodu i obrazu było udane” przy połączeniu z Figmą
☐ AI wypisuje konkretne nazwy tokenów (text color, border color, spacing)

Sygnały problemów:
☐ „wiele znaków” zamiast właściwych danych z Figmy
☐ „zawartość zastępcza” w odpowiedzi AI
☐ Brak konkretnych nazw tokenów projektowych w generowanym kodzie

✅ Kompletny przepływ pracy: od Figmy do kodu

Przygotowanie:
☐ Połącz Figma MCP z Cursor
☐ Stwórz nowy folder projektu
☐ Przygotuj czysty plik Figma z tokenami projektowymi

Generowanie:
☐ Wklej przygotowany prompt
☐ Dodaj link do selekcji w Figmie
☐ Wybierz odpowiedni model AI (polecany: Gemini 2.5 Pro)

Iteracja:
☐ Sprawdź pierwszy rezultat
☐ Zrób screenshot problemów
☐ Doprecyzuj instrukcje dla AI
☐ Powtarzaj aż do uzyskania pożądanego efektu

Finalizacja:
☐ Przetestuj wszystkie interakcje
☐ Sprawdź zgodność z systemem projektowym
☐ Przygotuj dokumentację komponentu

Wnioski: nowa jakość w przepływie pracy designerskiego

Przedstawiony przepływ pracy pokazuje fundamentalną zmianę w procesie tworzenia komponentów UI. Zamiast tradycyjnych tygodni pracy nad implementacją, designerzy mogą teraz w ciągu minut otrzymać funkcjonalne, interaktywne komponenty.

Jednak kluczem do sukcesu jest zrozumienie ograniczeń i mocnych stron różnych narzędzi AI, oraz systematyczne podejście do iteracji i dopracowywania rezultatów.

Jak podsumowuje autorka: „Otrzymasz całkowicie klikalny i interaktywny komponent z specyfikacjami, różnymi wariantami rozmiarów, a nawet odwołaniami do tokenów projektowych, jeśli je zdefiniujesz”.

Kluczowy insight

Przełączanie modeli AI

Standardowo myślimy: Wybieramy jeden model AI i używamy go do wszystkiego, doprecyzowując prompty gdy coś nie działa.

W praktyce okazuje się, że: Różne modele AI mają różne mocne strony – Claude Sonnet słabo wyciąga tokeny projektowe z Figmy, jednak Gemini 2.5 Pro robi to doskonale w ciągu sekund.

Dlaczego to jest istotne: Zamiast tracić godziny na frustrujące doprecyzowywanie promptów, można w 30 sekund przełączyć model i uzyskać znacznie lepsze efekty. To jak przełączanie między młotkiem a śrubokrętem – różne narzędzia do różnych zadań.

Test na jutro: Następnym razem gdy AI nie daje oczekiwanych rezultatów, zamiast doprecyzowywać prompt po raz dziesiąty, spróbuj przełączyć na inny model i sprawdź czy problem zniknie natychmiast.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Oryginalny materiał pochodzi z praktycznej prezentacji przepływu pracy designerskiego dostępnej tutaj: https://www.youtube.com/watch?v=4nE_9g5zxeQ

Tag: Przeplyw Pracy Designerski

Cursor + Figma MCP: jak w ciągu 20 minut stworzyć interaktywne komponenty systemu projektowego #EN170