Projektowanie w Figmie jest proste. Zbudowanie szybkiej, skalowalnej i SEO-ready strony w Webflow — już nie. Większość procesów migracji kończy się w tym samym miejscu: na stronie, która wygląda świetnie na screenshocie, ale jest koszmarem w edycji i obciążeniem dla deweloperów.

Ten przewodnik pokazuje, jak poprawnie przejść z Figmy do Webflow, bez:

• psucia responsywności na nietypowych rozdzielczościach,
• chaosu w klasach, który blokuje rozwój strony,
• śmieci w strukturze spowalniających ładowanie,
• strony, która po 3 miesiącach wymaga refaktoru, bo stała się niezarządzalna.

Dla kogo jest ten przewodnik?

Stworzyłem ten proces z myślą o trzech grupach, które najczęściej zderzają się ze ścianą podczas wdrożeń Webflow:

• Marketing Managerowie i Brand Ownerzy, którzy chcą mieć pełną kontrolę nad stroną bez pisania do dewelopera o każdą zmianę przecinka.
• UX/UI Designerzy, którzy chcą, aby ich pixel-perfect designy działały równie idealnie w przeglądarce, co w Figmie.
• Zespoły produktowe, dla których strona WWW ma być dynamicznym narzędziem sprzedaży, a nie długiem technicznym.

TL;DR

• Migracja Figma → Webflow nie polega na kopiowaniu wyglądu, tylko na budowie poprawnej struktury HTML/CSS.
• Większość migracji kończy się refaktorem, bo zespoły ignorują DOM, breakpointy, system klas i performance.
• Poprawny proces zaczyna się od przygotowania Figmy, potem systemu w Webflow (np. Client-First), a dopiero na końcu layoutu.
• Pluginy „Figma to Webflow” dają szybki efekt wizualny, ale generują dług techniczny i problemy ze skalowaniem.
• Dobrze wykonana migracja to system, który jest szybki, czytelny i łatwy w rozwoju — nie jednorazowy projekt.

Dlaczego większość migracji Figma → Webflow kończy się refaktorem

Problemy zaczynają się w momencie, gdy traktujesz migrację jak przeklejanie pixeli. Figma to narzędzie do projektowania, Webflow to platforma developmentu. Między nimi stoi przepaść, którą większość zespołów ignoruje.

Typowe błędy:

Brak grida i systemu breakpointów

‍Designer projektuje w jednym widoku desktop. Developer dostaje plik, w którym elementy są ustawione piksel po pikselu, bez logiki breakpointów. Efekt? Responsywność budowana od zera, ręcznie, w Webflow.

Chaotyczna hierarchia warstw

‍Warstwy w Figmie to przyszłe div-y w Webflow. Jeśli struktura w projekcie jest płaska lub nielogiczna, migracja zamienia się w odgadywankę. Developer musi rekonstruować zamysł designera, tracąc czas i popełniając błędy.

Brak systemu nazewnictwa

‍Komponenty nazywane Frame 427 lub Rectangle Copy 12 to pewna droga do chaosu w klasach Webflow. Bez konsekwentnego nazewnictwa nie zbudujesz skalowalnej struktury kodu.

Ignorowanie ograniczeń Webflow

‍Figma pozwala na wszystko. Webflow ma ograniczenia techniczne — nie każdy efekt wizualny da się odwzorować bez custom code lub kompromisów w performance. Projektowanie bez świadomości tych granic kończy się frustracją w fazie developmentu.

Czym różni się projektowanie pod Webflow od „zwykłego" UI designu

Projektowanie pod Webflow to projektowanie pod web development. Różnica jest fundamentalna.

Myślenie w strukturze DOM

‍W Figmie grupujesz elementy wizualnie. W Webflow każda grupa to element HTML z własnymi regułami układu, wypełniania przestrzeni i responsywności. Designer musi rozumieć, jak flexbox i grid działają w praktyce — nie tylko teoretycznie.

Breakpointy jako fundament, nie dodatek

‍Figma oferuje funkcję auto-layout, ale to nie to samo co system breakpointów w Webflow. Projekty muszą być budowane z myślą o co najmniej trzech widokach: desktop, tablet, mobile. Auto-layout w Figmie to punkt startowy, nie rozwiązanie.

Style jako system, nie dekoracja

‍Webflow bazuje na klasach CSS. Jeśli w Figmie tworzysz teksty bez stylów tekstowych, kolory bez color variables i komponenty bez wariantów — dostajesz bałagan w kodzie. System projektowy w Figmie przekłada się bezpośrednio na czytelność struktury w Webflow.

Performance i SEO od pierwszego pixela

‍Obrazy w pełnej rozdzielczości, nieoptymalizowane ikony, brak hierarchii heading-ów — to problemy, które designer musi rozwiązać na etapie projektu. Webflow University wprost wskazuje, że optymalizacja zaczyna się w fazie designu, nie developmentu.

Krok 1: Przygotowanie projektu Figma pod migrację

To etap, który większość zespołów pomija. I dlatego migracja trwa dwa razy dłużej, niż powinna.

Audit struktury przed rozpoczęciem

Zanim zaczniesz budować w Webflow, przeprowadź techniczny przegląd projektu:

Hierarchia warstw

‍Każdy frame w Figmie to potencjalny div w Webflow. Sprawdź, czy struktura jest logiczna i czy odpowiada rzeczywistemu flow strony. Usuń zbędne grupy — każdy nadmiarowy poziom to dodatkowy element w DOM.

Nazewnictwo komponentów i wariantów

‍Komponenty w Figmie powinny mieć nazwy zgodne z logiką, którą zastosujesz w Webflow. Przykład: zamiast Button/Primary/Large użyj btn-primary-large. To bezpośrednie przełożenie na naming w klasach.

System breakpointów

‍Upewnij się, że projekt ma co najmniej trzy widoki: 1440px (desktop), 768px (tablet), 375px (mobile). Jeśli czegoś brakuje, uzupełnij to teraz — nie w trakcie developmentu.

Czyszczenie projektu: co usunąć, co poprawić

Usuń nieużywane warstwy i komponenty

‍Każdy ukryty element, każda niezlinkowana instancja komponenta to potencjalne źródło błędów. Figma ma funkcję "Remove unused components" — użyj jej.

Spłaszcz niepotrzebne grupy

‍Jeśli grupa zawiera tylko jeden element, jest zbędna. Upraszczaj strukturę wszędzie, gdzie się da.

Sprawdź consistent użycie auto-layout

‍Elementy bez auto-layout będą wymagały ręcznego pozycjonowania w Webflow. Jeśli sekcja ma być responsywna, musi mieć zdefiniowany auto-layout z odpowiednimi właściwościami.

Sprawdzenie auto-layout i constraints

Auto-layout w Figmie to odpowiednik flexboxa w Webflow. Każdy komponent, który ma się skalować lub układać responsywnie, musi mieć poprawnie skonfigurowany auto-layout.

Kierunek osi (horizontal/vertical)

‍Upewnij się, że kierunek odpowiada zamierzonemu flow elementów. Pomyłka tutaj to godziny debugowania w Webflow.

Padding i spacing

‍Wartości paddingu i gap powinny być stałe i logiczne. Używaj wartości z systemu (8px, 16px, 24px), nie losowych liczb.

Resizing behavior

‍Ustaw, czy element ma się rozciągać (fill), czy trzymać stałego rozmiaru (fixed). To bezpośrednie przełożenie na flex-grow i flex-shrink w CSS.

Krok 2: Zbudowanie systemu projektowego w Webflow przed migracją

Migracja Figma do Webflow nie zaczyna się od kopiowania layoutów. Zaczyna się od zbudowania fundamentów — systemu, który utrzyma strukturę w ryzach.

Klasy globalne i naming convention (Client-First recommended)

Client-First to naming convention stworzony przez Finsweet — jedno z najbardziej uznanych rozwiązań w ekosystemie Webflow. Nie musisz go stosować w 100%, ale potrzebujesz jakiegoś systemu. Bez niego każda zmiana to przeszukiwanie setek klas.

Struktura nazewnictwa w Client-First:

• section — kontener sekcji
• container — wrapper treści z max-width
• grid — układ grid
• [element]_component — komponenty wielokrotnego użytku
• [element]_item — elementy wewnątrz komponentu

Przykład:

hero_component
hero_heading
hero_text
hero_button-wrapper

Dlaczego to działa?

‍Struktura klas odpowiada strukturze HTML. Developer patrząc na klasę wie, gdzie jest element w hierarchii i jaką pełni funkcję. Nie gubi się w div.box-1, div.container-new i innych śmieciach.

Style guide: typografia, kolory, spacing

Każdy element wizualny z Figmy musi mieć odpowiednik w Webflow — jako klasa, zmienna lub global style.

Typografia

‍Zdefiniuj klasy dla wszystkich stylów tekstowych z Figmy. Jeśli masz Heading 1, Body Regular, Caption Bold — stwórz dokładnie takie klasy w Webflow. Użyj kombinacji klas: text-style-h1 + text-color-primary zamiast jednej klasy hero-heading-blue.

Kolory

‍Webflow pozwala na tworzenie zmiennych kolorów (swatches). Przenieś paletę z Figmy 1:1 — każda zmienna w Figmie to zmienna w Webflow. To podstawa skalowalności.

Spacing system

‍Ustal zestaw wartości spacing (margines, padding) i trzymaj się go konsekwentnie. Oficjalna dokumentacja Webflow zaleca używanie rem-ów zamiast pixeli dla lepszej dostępności, ale w praktyce większość projektów używa px dla prostoty. Ważniejsze jest bycie konsekwentnym niż idealnym.

Komponenty wielokrotnego użytku i symbole

Każdy powtarzalny element — button, card, navbar — powinien być komponentem w Webflow. Nie kopiuj kodu. Zbuduj raz, użyj wszędzie.

Buttons

‍Zamiast stylować każdy button osobno, stwórz klasę bazową btn i warianty: btn-primary, btn-secondary, btn-ghost. Dodaj states (hover, pressed) dla wszystkich wariantów.

Cards

‍Jeśli projekt ma karty (testimonial, blog post, case study), zbuduj je jako komponenty Webflow. Upewnij się, że są responsywne i działają w różnych kontekstach.

Navigation i footer

‍To sekcje, które pojawiają się na każdej stronie. Zbuduj je raz, a potem używaj jako symboli. Zmiana w jednym miejscu = zmiana wszędzie.

Krok 3: Strategia layoutu — jak budować strukturę w Webflow

Layout w Webflow to nie odwzorowanie pozycji z Figmy. To zbudowanie systemu, który działa na każdym urządzeniu.

Kiedy używać flexbox, kiedy grid

Flexbox to default dla większości layoutów

‍Responsywne sekcje, nawigacje, karty obok siebie — to wszystko flexbox. Jest prosty, przewidywalny i świetnie skaluje się na breakpointach.

Przykład: sekcja hero z tekstem i obrazem obok siebie:

• Desktop: display: flex, flex-direction: row
• Mobile: flex-direction: column

Grid dla bardziej złożonych układów

‍Gdy masz layout typu magazine, portfolio z kafelkami o różnych rozmiarach, lub dashboard — grid jest lepszy. Pozwala kontrolować rozmieszczenie elementów w dwóch osiach jednocześnie.

Zasada: jeśli układ ma wyraźne kolumny i wiersze, użyj grida. Jeśli elementy mają się "układać" jeden za drugim — flexbox.

Sections, Containers, Wrappers — hierarchia, która działa

To najbardziej niedoceniana część procesu. Chaotyczna hierarchia to przyczyna 80% problemów z responsywnością.

Section

‍Pełna szerokość ekranu. Zawiera padding pionowy (góra/dół). Może mieć tło, kolor lub obraz.

Container

‍Wrapper z max-width (zazwyczaj 1200-1440px) i margin: auto. Centruje treść i zapobiega rozciąganiu tekstu na ultrawides.

Content wrapper

‍Opcjonalny dodatkowy poziom, jeśli potrzebujesz dodatkowej kontroli nad układem wewnątrz containera.

Przykład struktury:

section.hero
 container.hero-container
   div.hero-content (flexbox row)
     div.hero-text
     div.hero-image

Responsywność: breakpointy i cascading changes

Webflow działa na zasadzie kaskady: zmiany na Desktop dziedziczą się w dół (Tablet → Mobile). Zmiany na Mobile NIE wpływają na Desktop.

Workflow:

1. Zbuduj desktop first
2. Przejdź na Tablet — popraw tylko to, co się psuje
3. Przejdź na Mobile — znów popraw tylko problemy

Najczęstsze zmiany:

• Desktop: flex-direction row → Mobile: column
• Desktop: 3-column grid → Mobile: 1-column
• Ukrywanie elementów na mobile (hamburger menu)
• Zmniejszanie paddingów i font-size

Google Search Central wskazuje, że responsywność to jeden z czynników rankingowych. Strona, która nie działa na mobile, nie będzie dobrze rankować — niezależnie od contentu.

Krok 4: Proces techniczny migracji (krok po kroku)

Tu zaczyna się faktyczna migracja. Jeśli wykonałeś poprzednie kroki poprawnie, ten etap będzie szybki i przewidywalny.

Przenoszenie layoutu sekcja po sekcji

Nie buduj całej strony naraz. Zacznij od góry, idź sekcja po sekcji.

Navbar

‍Pierwsza sekcja, która powinna być gotowa. Zbuduj ją jako symbol — będziesz jej używał na każdej podstronie.

Hero

‍Zazwyczaj najprostsza sekcja wizualnie, ale wymaga dopracowania responsywności. Upewnij się, że tekst i CTA są czytelne na wszystkich breakpointach.

Content sections

‍Buduj je w kolejności pojawiania się na stronie. Każda sekcja powinna być ukończona (desktop + responsywność) zanim przejdziesz do następnej.

Footer

‍Ostatnia sekcja. Podobnie jak navbar — zbuduj jako symbol.

Kopiowanie tekstu, obrazów i ikon

Tekst

‍Kopiuj z Figmy bezpośrednio. Sprawdź, czy zachowuje formatowanie (boldy, linki). W Webflow ustaw odpowiednią klasę typograficzną.

Obrazy

‍Nie wrzucaj pełnych rozdzielczości z Figmy. Zoptymalizuj przed uploadem:

• JPEG dla zdjęć (quality 80-90%)
• PNG dla grafik z przezroczystością
• WebP dla lepszej kompresji (Webflow konwertuje automatycznie, jeśli włączysz)

Rozmiar max: 1920px szerokości dla obrazów hero, mniejsze dla thumbnails.

Ikony

‍SVG wstawiane inline-em (nie jako obrazy). Dzięki temu możesz kontrolować kolor przez CSS. Jeśli masz ich dużo, rozważ użycie biblioteki ikon (Feather, Heroicons).

Dopasowanie stanów interaktywnych (hover, active, focus)

Figma pokazuje tylko stany statyczne. W Webflow musisz je zbudować ręcznie.

Buttons:

• Normal state: bazowy wygląd
• Hover: zmiana koloru, lekka transformacja (scale 1.05)
• Pressed: zmiana koloru, scale 0.98
• Focus: outline dla dostępności (nigdy nie outline: none bez alternatywy)

Linki:

• Hover: zmiana koloru, underline
• Visited: opcjonalnie inny kolor (dla blogów i artykułów)

Cards:

• Hover: box-shadow, lekkie podniesienie (transform: translateY)

Dodaj transitions (0.2-0.3s ease) dla płynności. Bez transitionów interakcje wyglądają tanio.

Krok 5: Optymalizacja po migracji

Strona zbudowana ≠ strona gotowa do produkcji. Ten krok oddziela amatorów od profesjonalistów.

Audyt struktury klas i czyszczenie kodu

Webflow generuje combo classes automatycznie, gdy nakładasz style na istniejące klasy. Po kilku iteracjach masz spaghetti.

Co zrobić:

• Przejrzyj wszystkie sekcje i usuń niepotrzebne combo classes
• Wyciągnij powtarzalne style do osobnych klas
• Upewnij się, że nazewnictwo jest konsekwentne

Narzędzie: Webflow Style Guide (wbudowane). Pokazuje wszystkie klasy w projekcie — łatwo wyłapać duplikaty i chaos.

Optymalizacja obrazów i assetów

Lazy loading

‍Włącz dla wszystkich obrazów poniżej fold. Webflow robi to domyślnie, ale sprawdź ustawienia.

Responsive images

‍Webflow generuje różne rozmiary automatycznie. Upewnij się, że obrazy mają ustawiony srcset.

Kompresja

‍Przed uploadem: TinyPNG lub Squoosh. Po uploading: Webflow kompresuje dodatkowo, ale to nie usprawiedliwia wrzucania 5MB obrazów.

Page speed i Core Web Vitals

Google mierzy performance przez Core Web Vitals: LCP, FID, CLS. Webflow daje dobre wyniki out of the box, ale można je popsuć złym kodem.

LCP (Largest Contentful Paint)

‍Największy element na stronie powinien załadować się poniżej 2.5s. Zazwyczaj to hero image. Jeśli jest za duży — zoptymalizuj.

CLS (Cumulative Layout Shift)

‍Elementy nie mogą "skakać" podczas ładowania. Ustaw width i height dla obrazów. Unikaj wstawiania contentu nad już załadowaną treścią.

FID (First Input Delay)

‍Ile czasu mija od kliknięcia do reakcji strony. Minimalizuj custom code i heavy interactions.

SEO: meta title, description, heading hierarchy

Heading hierarchyH1 — jeden na stronę, główny temat. H2 — sekcje główne. H3 — podsekcje. Nie przeskakuj poziomów (H1 → H3 to błąd).

Meta title50-60 znaków. Zawiera primary keyword. Unikalny dla każdej strony.

Meta description150-160 znaków. Zachęca do kliknięcia. Google nie używa tego do rankingu, ale wpływa na CTR.

Alt text dla obrazówOpisowy, konkretny. Nie "obraz", tylko "wykres wzrostu konwersji w e-commerce 2024".

Webflow University ma dedykowany kurs SEO — jeśli budujesz strony na poważnie, przejdź go w całości.

Krok 6: Testowanie przed publikacją

Publikacja bez testów to gwarancja problemów. Każda strona Webflow powinna przejść przez ten checklist.

Cross-browser testing

Desktop:

• Chrome (80% użytkowników)
• Safari (15% użytkowników, inne rendering engine)
• Firefox (edge cases)

Mobile:

• Safari iOS (inne zachowanie scrollu i gestów)
• Chrome Android

Narzędzie: BrowserStack lub LambdaTest. Sprawdź przynajmniej najnowsze wersje + jedna wersja wstecz.

Responsywność na realnych urządzeniach

DevTools to nie to samo co prawdziwe urządzenie. Touch targets, scroll behavior, font rendering — wszystko wygląda inaczej.

Testuj minimum na:

• iPhone (Safari iOS)
• Android (Chrome)
• Tablet (iPad lub Android)

Na co zwrócić uwagę:

• Touch targets min 44x44px (Apple HIG)
• Tekst czytelny bez zoomowania
• Formularze łatwe do wypełnienia
• Brak horizontal scroll

Formularze, CTA i interakcje

Formularze:

• Wszystkie pola mają label
• Błędy walidacji są zrozumiałe
• Success state działa
• Integracja z CRM/mailingiem jest aktywna

CTA:

• Wszystkie buttony prowadzą gdzie powinny
• Linki zewnętrzne otwierają się w nowej karcie
• Stan hover/pressed jest widoczny

Interactions:

• Płynne animacje (bez lagów)
• Nie przeszkadzają w czytaniu contentu
• Można je wyłączyć (prefers-reduced-motion dla dostępności)

Najczęstsze błędy w migracjach Figma → Webflow

To lista rzeczy, które widzę w 90% źle przeprowadzonych migracji.

Przeszacowanie pluginów "Figma to Webflow"

Pluginy typu Figma to Code, Anima, czy inne konwertery obiecują automatyczną migrację. W praktyce generują nieużywalny kod.

Co dostaniesz:

• Setki div-ów z inline styles
• Absolute positioning zamiast flexboxa
• Brak logiki responsywności
• Chaos w strukturze bez możliwości edycji

Kiedy pluginy mają sens:Prototypowanie szybkie, throwaway landing pages, które nie będą rozwijane. Nigdy dla projektów produkcyjnych.

Brak planu responsywności przed rozpoczęciem

Responsywność to nie "dodanie breakpointów na końcu". To fundament architektury.

Jeśli budujesz desktop first bez planu na mobile:

• Będziesz przeciążać elementy
• Układ się rozsypie
• Spędzisz godziny na "naprawianiu" tego, co powinno działać od początku

Plan responsywności to:

• Zdefiniowane breakpointy przed budową
• Projekt w Figmie dla mobile i tablet (nie tylko desktop)
• Świadomość, które elementy znikają/pojawiają się na mniejszych ekranach

Chaos w klasach i brak nazewnictwa

Klasy typu div-block-27, container-2, text-block-copy-3 to bomba zegarowa.

Po 3 miesiącach:

• Nie wiesz, gdzie jest co
• Każda zmiana to przeszukiwanie inspectora
• Nowy developer musi zgadywać, co robi każda klasa

Rozwiązanie:Client-First, BEM, albo własny system — ale jakiś. Konsekwentnie stosowany od pierwszego diva.

Ignorowanie performance (za duże obrazy, za dużo kodu)

Strona, która ładuje się 8 sekund, nie będzie konwertować. Nie będzie też dobrze rankować.

Typowe problemy:

• Obrazy 5MB prosto z Figmy
• Custom code, który blokuje rendering
• Tuzin custom fontów
• Interactions na scroll z heavy calculations

Rozwiązanie problemów:

• Kompresja obrazów przed uploadem
• Lazy loading dla wszystkiego poniżej fold
• Minimalizacja custom JS
• Tylko 2-3 fonty max (każdy dodatkowy to dodatkowe requesty)

Spicy Conclusion: dlaczego 90% migracji jest źle robiona

Większość migracji Figma → Webflow kończy się stronami, które wyglądają OK na screenshocie, ale rozpadają się pod presją realnego użytkowania.

Dlaczego?

Bo zespoły traktują migrację jak przeklejanie pixeli. Designer rzuca link do Figmy, developer włącza plugin lub buduje "pixel perfect" bez myślenia o strukturze, a marketing publikuje, bo deadline.

Efekt: strona, która po 3 miesiącach jest niemożliwa do edycji. Dodanie sekcji to refaktor całego layoutu. Zmiana koloru buttona to przeszukiwanie 30 combo classes. Responsywność wymaga custom code, bo zbudowana została na absolutach.

Co to zmienia?

‍Koszt utrzymania rośnie. Czas wprowadzania zmian się wydłuża. Strona przestaje być assetem, a staje się problemem.

Plugin-only migration to iluzja łatwości.

Dostajesz kod szybko, ale kod, który nie da się utrzymać. To dług techniczny spłacany przez kolejne miesiące.

Proces opisany w tym artykule jest wolniejszy na starcie, ale szybszy w długim terminie.

Bo nie budujesz strony — budujesz system. System, który działa na każdym urządzeniu, skaluje się z biznesem i nie wymaga refaktoru co kwartał.

Jeśli szukasz szybkiej migracji — użyj pluginu. Jeśli szukasz strony, która faktycznie pracuje dla Twojego biznesu — postaw na proces.

O autorze

Nazywam się Jakub Jagoda i w mind&matter zajmuję się budowaniem mostów między designem a technologią.

Jako Webflow Developer zrealizowałem ponad 15+ wdrożeń, od prostych landing page'y po rozbudowane serwisy korporacyjne z setkami podstron w CMS.

Moje podejście opiera się na standardach Client-First, co oznacza, że nie tylko „dowożę projekt”, ale buduję skalowalne systemy, które moi klienci potrafią obsługiwać samodzielnie.

Nie uznaję dróg na skróty — ten proces to suma błędów, które widziałem u innych i standardów, które wypracowałem, by ich unikać.

‍

‍