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