Design do kodu
Figma zaprojektowana pod kod 1:1
Claude potrafi odtworzyć widok z Figmy co do piksela, ale tylko z pliku, który mówi językiem kodu: zmiennymi zamiast ręcznych wartości, auto layoutem zamiast pozycji absolutnych i wariantami zamiast kopii. Ta strona pokazuje, jak projektować, żeby tokeny pokrywały się co do nazwy, a implementacja była mapowaniem, nie interpretacją.
Jedna nazwa w trzech światach
Zmienne Figmy grupuje się ukośnikami, tokeny CSS łącznikami, a klasy Tailwinda prefiksami. To ten sam token w trzech zapisach, więc Claude tłumaczy go mechanicznie, bez zgadywania.
- Figma
- kolor/ink/950
- Token CSS
- --color-ink-950
- Kod
- bg-ink-950
- Figma
- kolor/glow/400
- Token CSS
- --color-glow-400
- Kod
- text-glow-400
- Figma
- kolor/danger/400
- Token CSS
- --color-danger-400
- Kod
- border-danger-400
- Figma
- tekst/fluid/base
- Token CSS
- --text-fluid-base
- Kod
- text-fluid-base
- Figma
- tekst/fluid/3xl
- Token CSS
- --text-fluid-3xl
- Kod
- text-fluid-3xl
- Figma
- przestrzen/4
- Token CSS
- --spacing * 4
- Kod
- p-4, gap-4
- Figma
- promien/xl
- Token CSS
- --radius-xl
- Kod
- rounded-xl
Auto layout to flexbox narysowany myszką
Każde ustawienie auto layoutu ma dokładny odpowiednik w CSS. Ramka zaprojektowana tym słownikiem przenosi się na kod bez tłumaczenia, a razem z nim przenosi się zachowanie responsywne.
Auto layout, kierunek
display: flex, flex-direction
Gap między elementami
gap
Padding ramki
padding
Hug contents
width: fit-content
Fill container
flex: 1 lub width: 100%
Min width i max width ramki
min-width, max-width
Wrap w auto layoucie
flex-wrap: wrap
Warianty komponentu
propsy komponentu
Zmienne
design tokens w @theme
Reguły pliku gotowego na Claude
- Zmienna w Figmie i token w kodzie to jedna nazwa, różni się najwyżej separator.
- Żaden kolor, rozmiar ani odstęp nie jest wpisany ręcznie, wszystko wskazuje na zmienną.
- Auto layout jest obowiązkowy, pozycja absolutna to wyjątek z uzasadnieniem w opisie ramki.
- Warianty i property komponentu w Figmie odpowiadają propsom komponentu w kodzie jeden do jednego.
- Plik zawiera wszystkie stany widoku: ładowanie, treść, pustkę i błąd, nie tylko szczęśliwą ścieżkę.
- Ramki projektuje się w szerokościach referencyjnych 390 px i 1440 px, a zachowanie pomiędzy nimi opisuje auto layout i płynna skala.
- Komunikaty błędów mają w projekcie zarezerwowane sloty, dokładnie jak w implementacji.
Od ramki do komponentu
Figma kolor/glow/400
CSS --color-glow-400
Tailwind bg-glow-400
Figma tekst/fluid/base
CSS --text-fluid-base
Tailwind text-fluid-base
Figma Button
variant=danger, loading=true
React <Button variant="danger" loading>
Usuń projekt
</Button>Zaimplementuj widok z tej ramki Figmy
jako komponent React:
https://www.figma.com/design/...?node-id=...
Zasady:
1. Zmienne Figmy mapuj wprost na tokeny
z @theme: kolor/glow/400 to bg-glow-400,
tekst/fluid/base to text-fluid-base.
2. Auto layout przenieś na flexbox
z tymi samymi gap i paddingami.
3. Warianty komponentów mapuj na propsy
komponentów z src/components/ui,
nie buduj nowych.
4. Zaimplementuj wszystkie stany widoku,
razem ze slotami na błędy.Struktura pliku, którą zrozumie każdy
Plik projektowy to repozytorium designu, więc ma stały układ stron. Nowa osoba w zesfield i Claude czytają go tak samo: od tokenów, przez komponenty, po widoki.
01
Okładka
Status projektu, wersja biblioteki i kontakt do właścicieli.
02
Tokeny
Zmienne kolorów, typografii, przestrzeni i promieni, nic poza nimi.
03
Komponenty
Biblioteka z wariantami pokrywającymi propsy z kodu.
04
Widoki
Ramki 390 i 1440 dla każdego widoku, wszystkie cztery stany.
05
Archiwum
Odrzucone kierunki z datą i powodem, nigdy w widokach.
Mobile first, kontekst klienta zawsze
Od 390 w górę, nigdy odwrotnie
Widok projektuje się najpierw w ramce 390 px, bo ciasnota wymusza decyzje: co jest treścią, a co ozdobą. Ramka 1440 px jest rozszerzeniem tej hierarchii o przestrzeń, nie osobnym projektem. Jeżeli desktop wymaga innej struktury niż mobile, to znak, że hierarchia treści jest nierozstrzygnięta.
Referencje wspólne, gęstość klienta
Ekrany 390 i 1440 to punkty kalibracji, nie definicja projektu. SaaS dostanie ciaśniejszą skalę i gęstsze tabele, witryna korporacyjna więcej powietrza i większy kontrast rozmiarów, sklep priorytet dla obrazów i cen. Kontekst klienta wybiera wartości tokenów, ale nazwy i struktura systemu zostają te same.
Przewodnik krok po kroku
- 01Załóż kolekcje zmiennych: kolor, tekst, przestrzeń, promień. Nazwy bierz z tokenów w kodzie albo ustal je razem z zespołem, zanim powstanie pierwsza ramka.
- 02Zbuduj style tekstowe z par rozmiar plus interlinia, po jednej dla każdego kroku płynnej skali.
- 03Złóż komponenty bazowe: przycisk, pole, badge, karta. Każdy stan, także ładowanie i błąd, jest wariantem.
- 04Dodaj property odpowiadające propsom z kodu jeden do jednego, na przykład wariant i loading dla przycisku.
- 05Zaprojektuj każdy widok w ramce 390 px z autolayoutem od korzenia do liścia, z czterema stanami widoku.
- 06Rozciągnij widoki do ramki 1440 px, zmieniając wyłącznie parametry layoutu, nie strukturę warstw.
- 07Podłącz prototyp przejść między stanami, żeby review odbywało się na zachowaniu, nie na statycznych obrazkach.
- 08Opublikuj bibliotekę i przekaż programiście linki do konkretnych ramek razem z regułami mapowania dla Claude.
Przepływ pracy zespołu
01
Designer publikuje bibliotekę
Zmienne i komponenty nazwane tak jak tokeny i komponenty w repozytorium, warianty pokrywają propsy.
02
Programista podaje ramkę
Do Claude trafia link do konkretnej ramki, nie do całego pliku, razem z regułami mapowania.
03
Claude mapuje, nie interpretuje
Przez Figma MCP czyta auto layout, zmienne i warianty, po czym przekłada nazwy wprost na tokeny i propsy.
04
Zespół robi review
Implementacja staje obok ramki, a odbiór przechodzi przez checklistę, łącznie ze stanami i slotami na błędy.
Punkty odbioru dla tego przepływu znajdziesz w grupie Figma i handoff w checkliście review.