Siatki i układy w Figma: jak ustawić grid pod web, mobile i dashboard bez „pływania” elementów

1. Podstawy siatek w Figma: layout grids (kolumny, marginesy, gutter) i kiedy ich używać

Siatki w Figma (Layout Grid) to wizualny „szablon” pomagający układać elementy równo, przewidywalnie i w spójnych odstępach. Najczęściej służą do porządkowania układu na frame’ach ekranów (web, mobile, dashboard), tak aby elementy trafiały w te same linie odniesienia, a wyrównania nie były robione „na oko”.

W Figma Layout Grid jest właściwością konkretnego frame’a. Możesz mieć różne siatki dla różnych ekranów, a nawet kilka siatek na jednym frame’ie (np. osobną do kolumn i osobną do rytmu poziomego), ale w praktyce warto zaczynać od jednej, czytelnej siatki dopasowanej do typu projektu.

Czym jest layout grid i co daje w praktyce

• Ujednolica wyrównania — elementy (np. karty, formularze, wykresy) łatwiej układać względem tych samych pionowych linii.
• Kontroluje „oddech” układu — dzięki marginesom i gutterom widzisz, gdzie kończy się bezpieczny obszar treści oraz ile miejsca zostaje między kolumnami.
• Ułatwia spójność między ekranami — jeśli kolejne widoki korzystają z tej samej logiki siatki, różnice między nimi są celowe, a nie przypadkowe.
• Pomaga w komunikacji — grid jest wspólnym punktem odniesienia dla projektanta i osoby wdrażającej (łatwiej ustalić szerokości, wyrównania i zasady układu).

Główne typy layout grids w Figma

W praktyce najczęściej spotkasz trzy rodzaje siatek, z których każda ma inny cel:

• Columns (kolumny) — pionowy podział obszaru treści na równe (lub kontrolowane) kolumny. To podstawowa siatka do większości układów web i dashboard, a czasem także mobile (zwłaszcza gdy projektujesz moduły, które muszą się ładnie skalować).
• Rows (wiersze) — poziome pasy, przydatne do pilnowania rytmu pionowego (np. sekcji, bloków treści, list). Dobrze wspiera konsekwencję w układach, gdzie ważne są powtarzalne wysokości i odstępy.
• Grid (kwadratowa) — równomierna siatka w obu osiach, częściej używana jako pomoc do ogólnego „snapowania” i pilnowania regularności, rzadziej jako główny system układu stron z kolumnami.

Kolumny, marginesy i gutter — co oznaczają

Jeśli myślisz o gridzie jak o obszarze, w którym ma „siedzieć” treść, te trzy parametry są kluczowe:

• Kolumny — liczba pionowych pól, w które dzielisz obszar treści. Więcej kolumn daje większą elastyczność w komponowaniu różnych szerokości modułów (np. 4/12, 6/12, 8/12), ale też wymaga większej dyscypliny w składaniu elementów.
• Marginesy (margins) — odstęp od krawędzi frame’a do pierwszej/ostatniej kolumny. Wyznacza „bezpieczny” obszar, w którym zwykle umieszczasz główną treść, aby nie przyklejała się do brzegu i dobrze wyglądała na różnych rozmiarach.
• Gutter — odstęp między kolumnami. To wbudowany „kanał” separujący moduły, który pomaga zachować spójne przerwy bez ręcznego mierzenia za każdym razem.

Ważne: marginesy i gutter to nie tylko estetyka. To także prosty sposób na ograniczenie przypadkowych odstępów, które później sprawiają wrażenie, że elementy „pływają”.

„Stretch” vs „Center” — jak grid zachowuje się przy różnych szerokościach

Siatka kolumn może być ustawiona tak, aby:

• Rozciągała się wraz z frame’em (kolumny i/lub gutter adaptują się do szerokości) — podejście dobre, gdy projektujesz na różne szerokości i chcesz zachować ten sam podział na kolumny w szerokim zakresie.
• Była wyśrodkowana i trzymała stałą szerokość obszaru treści — podejście dobre, gdy chcesz pilnować maksymalnej czytelnej szerokości treści (częste w web), a nadmiar miejsca po bokach traktujesz jako „tło” lub obszar drugorzędny.

Dobór zależy od tego, czy priorytetem jest stała szerokość treści (czytelność i kontrola), czy pełniejsze wykorzystanie dostępnego miejsca (np. duże ekrany, dashboardy).

Kiedy używać layout grids, a kiedy wystarczy wyrównanie „na oko”

Layout grids warto włączać zawsze, gdy układ ma być powtarzalny i skalowalny. W szczególności:

• Strony i widoki z wieloma modułami (sekcje, karty, listy, panele) — grid pomaga utrzymać wspólne linie i równe przerwy.
• Dashboardy — tam, gdzie obok siebie istnieje wiele bloków o różnych szerokościach, a wyrównania są kluczowe dla czytelności danych.
• Projekty przekazywane do wdrożenia — siatka jest jasnym sygnałem, jaka jest logika układu i jakie są punkty odniesienia.

Z kolei w prostych, jednorazowych widokach (np. pojedynczy ekran marketingowy o nietypowej kompozycji) grid nadal może pomagać, ale nie zawsze musi być „władcą” kompozycji. Jeśli layout jest celowo asymetryczny, siatka może być bardziej delikatnym przewodnikiem niż sztywną regułą.

Jak myśleć o siatce, żeby nie przeszkadzała

• Traktuj siatkę jako system odniesienia, nie jako konieczność wypełniania każdej kolumny.
• Projektuj modułami — elementy (karty, sekcje, panele) łatwiej „wkładać” w kolumny niż pojedyncze, drobne obiekty.
• Ustal, co jest treścią główną i pilnuj, aby trzymała się obszaru wyznaczonego marginesami; elementy dekoracyjne mogą żyć poza nim, jeśli to świadoma decyzja.

Dobrze ustawiony layout grid nie ogranicza kreatywności — ogranicza przypadkowość. Dzięki temu układ wygląda stabilnie, a elementy sprawiają wrażenie osadzonych w jednym, spójnym systemie.

System 8pt: spacing, odstępy, skala i spójność w projektach web/mobile/dashboard

System 8pt to prosta zasada porządkowania odstępów: większość wartości spacingu (marginesy, paddingi, przerwy między elementami) opiera się o wielokrotności 8. Dzięki temu interfejs jest przewidywalny, łatwiejszy do utrzymania i mniej podatny na „rozjeżdżanie się” wizualne podczas rozbudowy projektu.

W praktyce nie chodzi o to, by wszystko było równe 8, 16, 24 itd., tylko by mieć spójną skalę odstępów i konsekwentnie jej używać. Najczęściej skala obejmuje zarówno małe przerwy (np. między ikoną a etykietą), jak i duże oddechy (np. między sekcjami).

Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj, w kontekście siatek i układów w Figma.

Dlaczego akurat 8?

• Spójność wizualna: elementy „układają się” w rytm, który łatwo utrzymać w całym projekcie.
• Skalowalność: gdy projekt rośnie, szybciej dobierasz poprawne odstępy bez każdorazowego „mierzenia na oko”.
• Zbieżność z typowymi platformami: wiele systemów projektowych i bibliotek UI naturalnie pracuje w krokach 8 lub ich pochodnych.

Jak rozumieć spacing w kontekście 8pt

W systemie 8pt warto myśleć o odstępach jako o zestawie poziomów, które przypisujesz do typowych sytuacji. Przykładowo:

• Odstępy wewnętrzne (padding): ile „powietrza” ma komponent w środku.
• Odstępy zewnętrzne (margins): jak daleko komponent stoi od innych elementów.
• Odstępy między elementami (gap/spacing): przerwy w układach typu lista, toolbar, formularz.
• Odstępy sekcyjne: większe przerwy rozdzielające bloki treści (np. nagłówek strony vs. zawartość).

Najważniejsze jest, by te kategorie miały logiczne, powtarzalne wartości. Wtedy podobne elementy zachowują podobny rytm w różnych miejscach produktu.

Kiedy dopuszczać wyjątki (np. 4pt)?

W wielu zespołach standardem jest podejście „8 jako baza, 4 jako półkrok”. Ma to sens, gdy potrzebujesz delikatniejszego dopasowania, np. w gęstych interfejsach lub w mikro-odstępach (ikonka–tekst, separacja w chipach, drobne wyrównania optyczne). Kluczowe jest, aby wyjątki były świadome i ograniczone, a nie wynikały z przypadkowego przesuwania elementów.

Web, mobile i dashboard: różnice w odczuciu „gęstości”

Ten sam system 8pt możesz stosować w różnych produktach, ale inaczej rozkładają się priorytety:

• Web (marketing, content): zwykle korzysta z większych oddechów (większe odstępy sekcyjne), bo liczy się czytelność, hierarchia i „lekkość” layoutu.
• Mobile: spacing musi wspierać ergonomię i czytelność na małej powierzchni; częściej operuje się średnimi wartościami, a konsekwencja pomaga uniknąć wrażenia ciasnoty lub przypadkowości.
• Dashboardy (data-heavy): często wymagają większej gęstości informacji, więc częściej pojawiają się mniejsze kroki (np. półkrok), ale nadal w ramach tej samej skali, żeby interfejs nie wyglądał na „poskładany z różnych części”.

Spójność: najważniejsza korzyść systemu 8pt

System 8pt działa najlepiej, gdy traktujesz go jak wspólny język całego zespołu. Spójne wartości spacingu ułatwiają:

• utrzymanie jednolitego wyglądu między ekranami i modułami,
• projektowanie komponentów, które „pasują” do siebie bez ręcznych korekt,
• szybkie podejmowanie decyzji (wybierasz z ustalonej skali, zamiast wymyślać nowe wartości),
• redukcję drobnych różnic, które później kumulują się jako wrażenie „pływania” i braku wyrównania.

Jeśli w projekcie często pojawiają się wartości typu 13, 19 czy 27 bez wyraźnego powodu, to zwykle sygnał, że brakuje jednej skali spacingu albo nie jest ona konsekwentnie używana.

3. Constraints i zachowanie elementów przy zmianie rozmiaru: zasady, typowe konfiguracje i pułapki

Constraints w Figma definiują, jak warstwa zachowuje się względem swojego rodzica (frame’a), gdy ten zmienia rozmiar. To podstawowe narzędzie do kontrolowania „przyklejenia” elementów do krawędzi, utrzymania proporcji lub rozciągania w osi — tak, aby układ nie wyglądał na przypadkowo rozjechany po zmianie szerokości/wysokości.

Na czym polegają constraints (w skrócie)

• Oś pozioma (Horizontal): element może trzymać się lewej/prawej, być wyśrodkowany, rozciągać się lub skalować.
• Oś pionowa (Vertical): analogicznie — góra/dół, środek, rozciąganie, skala.
• Punkt odniesienia to zawsze frame nadrzędny (nie grid i nie „ekran” jako taki).
• Constraints nie „wiedzą”, co jest obok — nie dbają o relacje między rodzeństwem. Pilnują tylko relacji dziecko–rodzic.

Najczęściej używane tryby i kiedy je wybierać

W praktyce chodzi o dopasowanie zachowania do roli elementu: czy ma zostać w rogu, trzymać margines, rozciągać się jak tło, czy utrzymać środek kompozycji.

Typowe konfiguracje (szybkie wzorce)

• Header na pełną szerokość: element tła/sekcji → Left & Right, zawartość po lewej (np. tytuł) → Left, akcje po prawej → Right.
• Sidebar + content: sidebar → Left + (opcjonalnie) Top & Bottom jeśli ma się ciągnąć po wysokości; content → Left & Right.
• Przycisk w rogu: Right + Bottom (gdy ma trzymać dystans od krawędzi niezależnie od rozmiaru).
• Modal/okno dialogowe: kontener modala → Center w obu osiach; overlay → Left & Right oraz Top & Bottom.
• Obraz jako tło sekcji: jeśli ma wypełniać obszar → constraints na Stretch; jeśli ma zachować kompozycję → rozważ Center i kontrolę dopasowania w samym obrazie (bez agresywnego skalowania całej warstwy).

Najczęstsze pułapki powodujące „pływanie”

• Nie ten rodzic: element jest zagnieżdżony w dodatkowym frame’ie/grupie i „trzyma się” jej krawędzi, a nie layoutu, który faktycznie się skaluje. Efekt: przesunięcia mimo poprawnych pozornie ustawień.
• Grupy zamiast frame’ów: grupy nie dają tak przewidywalnej kontroli jak frame’y; łatwo o sytuację, w której constraints nie działają tak, jak oczekujesz.
• Stretch na elementach, które nie powinny się rozciągać: np. przycisk ustawiony na Left & Right w kontenerze — zaczyna „puchnąć”, psując rytm i hierarchię.
• Scale użyte jako „responsywność”: skaluje wszystko (w tym typografię i odstępy), co często daje nienaturalne proporcje i wrażenie pływania przy zmianie rozmiaru.
• Brak spójnych offsetów: dwa elementy wizualnie wyrównane, ale z innymi wartościami X/Y względem rodzica — przy resize różnice zaczynają być widoczne.
• Tekst bez kontroli zachowania: gdy ramka tekstowa ma złe ustawienia (np. nie trzyma odpowiedniej krawędzi), przy zmianie szerokości rodzica może zmieniać łamanie linii w nieprzewidywalny sposób.

Krótka checklista przed resize frame’a

• Czy każdy element ma świadomie ustawione constraints w obu osiach (a nie „domyślne, bo działało”)?
• Czy element jest we właściwym frame’ie nadrzędnym, który faktycznie zmienia rozmiar?
• Czy elementy, które mają trzymać margines, są na Left/Right/Top/Bottom, a nie na Scale?
• Czy rozciągasz tylko te warstwy, które mogą rosnąć (tła, kontenery), a nie te, które powinny zachować rozmiar (ikony, przyciski)?

Constraints są najszybszym sposobem, by ustabilizować pozycjonowanie przy zmianie rozmiaru frame’a, ale mają ograniczenie: nie zarządzają relacjami pomiędzy elementami. Jeśli układ ma się „układać” dynamicznie (np. dopasowywać paddingi, odstępy i szerokości treści), same constraints zwykle nie wystarczą.

4. Auto Layout w praktyce: budowanie elastycznych komponentów, padding, spacing, wrap i alignment

Auto Layout w Figma służy do budowania elastycznych komponentów i sekcji UI, które same „układają się” na podstawie reguł: kierunku, odstępów, wypełnień i wyrównania. To narzędzie szczególnie przydatne tam, gdzie elementy mają zmienną treść (np. różne długości tekstów, stany przycisków, listy, karty), a układ ma pozostać stabilny bez ręcznego przesuwania warstw.

Doświadczenie Cognity pokazuje, że rozwiązanie tego problemu przynosi szybkie i zauważalne efekty w codziennej pracy — szczególnie wtedy, gdy projektant przestaje „łatać” layout ręcznymi przesunięciami, a zaczyna opierać go na spójnych regułach Auto Layout.

Kiedy Auto Layout daje największą wartość

• Komponenty z treścią o zmiennej długości: przyciski, chipy, tagi, badge, pola z etykietą i komunikatem błędu.
• Powtarzalne struktury: listy, tabele (na poziomie wierszy/komórek), sekcje kart, sidebar z pozycjami menu.
• Układy z jasnymi regułami spacingu: pionowe „stacki” treści, nagłówek + opis + akcje, siatki kart (z wrappingiem).
• Warianty stanów: gdy w jednym komponencie mogą pojawić się/znikać elementy (np. ikona, licznik, loader), a reszta ma się dopasować.

Auto Layout vs. ręczne pozycjonowanie (szybkie porównanie)

Kluczowe pojęcia: kierunek, padding i spacing

Auto Layout działa na kontenerze (frame) i układa jego dzieci zgodnie z ustawieniami:

• Direction (kierunek): poziomy (horizontal) lub pionowy (vertical). To fundament budowy „stacków”.
• Padding: wewnętrzne marginesy kontenera (top/right/bottom/left), które trzymają treść „od ścianek”.
• Spacing between items: odstęp pomiędzy elementami wewnątrz kontenera; zapewnia powtarzalność i eliminuje ręczne „rozpychanie”.

Praktyczna zasada: padding definiuje relację treści do kontenera, a spacing definiuje relację elementów względem siebie. Mieszanie tych ról (np. dopinanie odstępów pustymi prostokątami) zwykle kończy się „pływaniem” przy zmianach.

Resize: Hug, Fill, Fixed — jak myśleć o rozmiarach

W Auto Layout kluczowe jest ustawienie zachowania rozmiaru kontenera i jego dzieci. W praktyce najczęściej operujesz trzema trybami:

• Hug contents: element „obejmuje” zawartość (np. przycisk dopasowuje szerokość do tekstu).
• Fill container: element wypełnia dostępne miejsce w kontenerze (np. input w wierszu formularza).
• Fixed: stały rozmiar, niezależny od treści (np. ikona 24×24, avatar 40×40).

Dobrą praktyką jest: tekst i małe „opakowania” często ustawiaj jako Hug, główne pola/sekcje jako Fill, a elementy o stałym wymiarze jako Fixed. Dzięki temu komponent zachowuje proporcje bez ręcznych poprawek.

Alignment: wyrównanie i dystrybucja

Wyrównanie w Auto Layout dotyczy osi głównej (kierunku układania) i osi poprzecznej:

• Align (oś poprzeczna): np. w poziomym layoucie wyrównujesz elementy do góry/środka/dołu.
• Justify / distribution (oś główna): steruje tym, czy elementy idą „jeden po drugim” ze spacingiem, czy są rozciągane/rozsuwane (np. space-between).

Najczęstszy, stabilny wzorzec: stały spacing + wyrównanie do środka (dla wierszy) oraz stały spacing + wyrównanie do lewej (dla kolumn). Ustawienia „rozsuwające” (space-between) stosuj świadomie, bo zmiana szerokości kontenera może mocno zmieniać odległości.

Wrap: kiedy treść ma się zawijać

Wrap (zawijanie) pozwala układać elementy w wielu wierszach/kolumnach w ramach jednego Auto Layoutu. To przydatne dla:

• Chipów i tagów (lista filtrów, etykiety, kategorie), które przechodzą do kolejnej linii.
• Siatek kart o stałej szerokości kafla, które „łamią” się zależnie od dostępnej przestrzeni.
• Zestawów akcji (przyciski), gdy nie mieści się wszystko w jednym rzędzie.

Wrap działa najlepiej, gdy elementy mają przewidywalną szerokość (np. Fixed lub ograniczony Hug) i gdy spacing jest ustalony. W przeciwnym razie możesz uzyskać losowe przejścia do kolejnej linii.

Przykłady komponentów, które warto budować na Auto Layout

• Button: ikona (Fixed) + label (Hug) w kontenerze z paddingiem i stałym spacingiem.
• Input: label nad polem (vertical), komunikat walidacji pod spodem; pole jako Fill w dostępnej szerokości.
• Card: nagłówek, treść, stopka z akcjami; stopka może mieć układ poziomy i wyrównanie do prawej.
• List item: lewa część (ikona/avatar + teksty) jako Fill, prawa (np. chevron, akcja) jako Fixed.

Minimalny „przepis” na stabilny komponent

// logika ustawień (bez zależności od konkretnego projektu)
Kontener (Auto Layout):
- Direction: Horizontal lub Vertical
- Padding: stały (np. 12/16)
- Spacing between items: stały (np. 8)
- Alignment: konsekwentny (center dla wierszy / left dla kolumn)

Dzieci:
- Ikony/avatary: Fixed
- Teksty: Hug (z sensownymi ograniczeniami szerokości, jeśli potrzeba)
- Główne pola: Fill container
- Elementy opcjonalne: ukrywanie/pokazywanie bez zmiany „ręcznych” pozycji

Typowe błędy, które psują elastyczność (i jak ich unikać)

• Ręczne „spacery” (puste prostokąty) zamiast spacingu/paddingu — trudno to utrzymać przy zmianach.
• Zbyt wiele zagnieżdżeń bez potrzeby — rośnie złożoność i łatwiej o sprzeczne reguły.
• Wszystko na Fixed — komponent wygląda dobrze w jednym rozmiarze, ale nie skaluje się wraz z treścią.
• Space-between jako domyślne — odstępy zmieniają się przy każdym resize, co bywa niepożądane w UI.

Jeśli trzymasz się prostych reguł (stały padding, stały spacing, świadome Hug/Fill/Fixed), Auto Layout staje się podstawą stabilnych, reużywalnych komponentów, które nie wymagają ciągłych ręcznych poprawek.

5. Responsywność i breakpointy w Figma: jak projektować warianty i testować skalowanie układu

Responsywność w Figma sprowadza się do świadomego projektowania kilku stanów tego samego interfejsu (dla różnych szerokości) oraz weryfikacji, czy układ zachowuje logikę podczas rozciągania i zwężania. Breakpointy nie są „magicznym” ustawieniem w jednym miejscu — to zestaw decyzji: jakie szerokości projektujesz, co dzieje się z siatką, oraz jak elementy mają się przeorganizować.

Breakpointy: po co są i jak je dobierać

Breakpoint to próg szerokości, przy którym zmienia się układ (np. liczba kolumn, układ nawigacji, widoczność paneli). W praktyce projektowej w Figma breakpointy pomagają:

• utrzymać spójność decyzji layoutowych między ekranami,
• uniknąć „pływania” (przypadkowych przesunięć i skoków),
• planować, które elementy są priorytetowe na mniejszych szerokościach.

Dobieraj breakpointy na podstawie zachowania treści (kiedy layout zaczyna się łamać), a nie wyłącznie na podstawie listy urządzeń. Jeśli układ nie wymaga zmiany przy danym progu, nie twórz sztucznego wariantu.

Strategie projektowania wariantów responsywnych

Najczęściej spotkasz trzy podejścia. Różnią się nakładem pracy i tym, jak dobrze „symulują” implementację.

Jak projektować warianty: co zmienia się najczęściej

Warianty breakpointów zwykle obejmują kilka typowych decyzji układowych (bez wchodzenia w szczegóły mechanik):

• Siatka i szerokość contentu: zmiana liczby kolumn, szerokości kontenera, marginesów.
• Nawigacja: pełne menu → zwinięte / off-canvas; pasek boczny → ikony / ukrycie.
• Hierarchia treści: przesunięcie elementów o wysokim priorytecie wyżej, redukcja elementów drugorzędnych.
• Układ kart/sekcji: 3 kolumny → 2 → 1; przejście z układu poziomego na pionowy.
• Tabele i dashboardy: „gęste” widoki wymagają planu na zwężanie (np. priorytety kolumn, przewijanie, sekcje).

Kluczowe jest, aby przy każdym breakpointcie odpowiedzieć na pytanie: co ma pozostać stabilne (np. szerokość kontenera, rytm odstępów), a co ma się przeorganizować (np. liczba kolumn, kolejność bloków).

Testowanie skalowania układu w Figma (praktyczny workflow)

Żeby ocenić responsywność, nie wystarczy narysować dwóch ekranów. Potrzebujesz krótkiego testu „pośrednich” szerokości, bo tam najczęściej ujawniają się problemy.

• Ustal zestaw szerokości testowych: dla każdego breakpointu dodaj 1–2 wartości pomiędzy (np. „tuż przed przełamaniem”).
• Rozciągaj ramkę i obserwuj zachowanie kluczowych bloków: nagłówków, nawigacji, gridów z kartami, sekcji z CTA.
• Sprawdzaj długości treści: podmień tekst na dłuższy/krótszy, aby zobaczyć, czy układ jest odporny na realne dane.
• Weryfikuj interakcje w prototypie (jeśli używasz): czy przejścia między wariantami nie powodują skoków i utraty kontekstu.

Warianty i organizacja pliku: czytelność dla zespołu

Responsywne projekty szybko rosną, więc liczy się porządek. Dobra praktyka to utrzymywanie pary (lub zestawu) ekranów dla tego samego widoku w układzie obok siebie oraz konsekwentne nazewnictwo.

• Nazwy ramek: dodawaj sufiks z breakpointem (np. „Home / md”, „Home / lg”).
• Stałe punkty odniesienia: trzymaj powtarzalne elementy (np. header) w tej samej osi, aby łatwo porównać różnice.
• Komunikacja zmian: jeśli coś „zmienia tryb” (np. sidebar przechodzi w drawer), pokaż to jako osobny wariant layoutu, a nie drobną korektę przypadkowych przesunięć.

Mini-checklista: czy Twój breakpoint ma sens?

• Czy istnieje powód treściowy (a nie tylko „bo jest taki rozmiar urządzenia”)?
• Czy po zmianie szerokości wiadomo, co jest priorytetem i co może zniknąć/zmienić pozycję?
• Czy pośrednie szerokości nie powodują nagłych skoków i utraty wyrównania?
• Czy różnice między wariantami są intencjonalne i opisane (np. w notatce lub nazwie wariantu)?

6. Przykładowe konfiguracje siatek i parametrów: web (desktop), mobile (iOS/Android), dashboardy (data-heavy)

Poniższe ustawienia traktuj jako sprawdzone punkty startowe do pracy w Figma. Najważniejsza różnica między web/mobile/dashboard to: liczba kolumn, szerokość marginesów, gutter (odstęp między kolumnami) oraz to, czy projektujesz pod stały kontener czy pod płynną szerokość. Warto też od początku dopasować siatkę do realnych ograniczeń: treści, tabel, kart, formularzy i nawigacji.

Konfiguracje startowe (tabela)

Web (desktop): 12 kolumn i decyzja „stretch vs center”

• 12 kolumn to najczęstszy wybór, bo daje elastyczność (2/3/4/6/12) i łatwe dzielenie sekcji.
• Stretch (kolumny rozciągają się wraz z frame) jest wygodny, gdy projekt ma być płynny, ale wymaga dyscypliny w marginesach i kontenerach.
• Center (stała szerokość siatki wyśrodkowana) bywa lepszy, gdy chcesz trzymać się jednego kontenera treści (np. 1140–1200 px) i ograniczyć „pływanie” na szerokich ekranach.

Praktyczny starter (desktop 1440): 12 kolumn, gutter 24, marginesy 80. Jeśli projektujesz pod kontener: ustaw grid na Center z fixed width np. 1200 i dopasuj marginesy frame do wygodnego podglądu.

Mobile (iOS/Android): 4 kolumny i mniejsze marginesy

• 4 kolumny to popularny standard, który dobrze wspiera typowe układy: pełna szerokość, pół na pół (2+2), lub 3+1 pod akcje.
• Marginesy 16–20 pomagają utrzymać czytelność i zgodność z większością wzorców mobilnych.
• Gutter 16 jest bezpiecznym wyborem dla kart, list i prostych siatek; przy gęstszym UI rozważ 12.

Uwaga projektowa: na mobile częściej „siatką” staje się przewidywalna szerokość treści i konsekwentne marginesy niż rozbudowany podział na wiele kolumn.

Dashboardy (data-heavy): więcej modułów, większa tolerancja na gęstość

• Najczęściej sprawdzają się 12 lub 16 kolumn — 16 daje drobniejszą modularyzację (np. 3/5/8/11) przy wielu panelach.
• Mniejsze marginesy niż w marketingu (np. 24–48) pozwalają efektywniej wykorzystać przestrzeń pod dane.
• Gutter 16–24: 16 dla gęstych siatek i wielu paneli, 24 gdy dashboard ma „oddychać” i ma mniej modułów, ale większe.

Dodatkowa praktyka: dla dashboardów często wygodniej jest zestawić dwie siatki w jednym frame: kolumnową (pod moduły) oraz subtelny grid wierszy (pod rytm pionowy). Jeśli używasz row grid, trzymaj go na niskiej widoczności, żeby nie „dominował” projektu.

Przykładowe ustawienia do przepisania w Figma

Poniżej zapis „parametrów”, które możesz szybko odwzorować w panelu Layout grid dla frame:

WEB (Desktop 1440)
- Columns: 12
- Type: Stretch
- Margin: 80
- Gutter: 24

MOBILE (iOS 390)
- Columns: 4
- Type: Stretch
- Margin: 16
- Gutter: 16

DASHBOARD (Desktop 1440–1920)
- Columns: 16 (lub 12)
- Type: Stretch
- Margin: 32
- Gutter: 16–24

Jak dobrać konfigurację (szybkie kryteria)

• Jeśli dominują sekcje i hero (marketing) — większe marginesy i 12 kolumn.
• Jeśli dominują listy i formularze (aplikacja web) — 12 kolumn, ale rozważ kontener Center dla przewidywalności.
• Jeśli dominują tabele, filtry, panele (dashboard) — 12/16 kolumn, mniejsze marginesy i przemyślany gutter pod gęstość.
• Jeśli projekt ma częste układy 2-up na mobile — 4 kolumny zwykle wystarczą; 6 kolumn wybieraj, gdy realnie potrzebujesz bardziej drobnego podziału.

7. Najczęstsze przyczyny „pływania” elementów i jak je naprawić (checklista diagnostyczna)

„Pływanie” elementów w Figma najczęściej wynika z niespójnych reguł pozycjonowania: część obiektów jest ustawiona ręcznie „na oko”, część opiera się o siatkę, a część zachowuje się inaczej przy zmianie rozmiaru ramki. Poniższa checklista pomaga szybko namierzyć źródło problemu i ujednolicić zachowanie układu.

• Brak jednej „prawdy” dla układu (siatka vs ręczne wyrównania)

  Objawy: elementy nie trzymają osi, odstępy „prawie” się zgadzają, ale przy porównaniu ekranów widać drobne przesunięcia.

  Naprawa: wybierz wiodący sposób prowadzenia układu dla danej ramki (np. layout grid i stałe marginesy) i dociągnij kluczowe elementy do tych samych linii odniesienia (krawędzie, kolumny, osie).

• Niespójne marginesy i gutter w obrębie projektu

  Objawy: sekcje wyglądają poprawnie osobno, ale „nie składają się” w całość; pojawiają się różne odległości od krawędzi w podobnych modułach.

  Naprawa: ujednolić marginesy zewnętrzne i przerwy między kolumnami dla ekranów tego samego typu; sprawdzać powtarzalne bloki (hero, listy, karty) pod kątem identycznych wartości.

• Elementy umieszczone poza strukturą (dzieci nie w tym kontenerze)

  Objawy: przy przesuwaniu sekcji część elementów „zostaje w tyle” lub nie skaluje się razem z modułem.

  Naprawa: zweryfikuj hierarchię warstw; elementy wizualnie należące do modułu powinny być zagnieżdżone w jego ramce/grupie, a nie „luzem” na poziomie ekranu.

• Grupy zamiast ramek tam, gdzie liczy się layout

  Objawy: trudne utrzymanie paddingu, brak przewidywalnego zachowania przy zmianie rozmiaru, kłopotliwe wyrównania.

  Naprawa: zamieniaj grupy na ramki w miejscach, gdzie potrzebujesz stabilnych granic kontenera (padding, tło, wyrównania do krawędzi). Grupy traktuj jako narzędzie pomocnicze, nie fundament układu.

• Nieprawidłowe Constraints w ramkach responsywnych

  Objawy: po zmianie szerokości/wysokości ramki elementy odklejają się od krawędzi, zmieniają pozycję niezgodnie z oczekiwaniem albo „uciekają” poza ekran.

  Naprawa: sprawdź, czy każdy element ma sensownie ustawione przywiązanie (do lewej/prawej/środka, góry/dołu) oraz czy elementy, które powinny się rozciągać, faktycznie mają włączone rozciąganie w odpowiednim kierunku.

• Mieszanie trybów: część elementów w Auto Layout, część pozycjonowana absolutnie

  Objawy: w obrębie jednego komponentu odstępy „rozjeżdżają się” po zmianie treści; ikony lub badge nie trzymają miejsca; układ wygląda inaczej w wariantach.

  Naprawa: zdecyduj, co ma być układane automatycznie, a co ma być pozycjonowane niezależnie. Jeśli element jest częścią przepływu (np. tekst + ikona), powinien być w tym samym układzie; absolutne pozycjonowanie zostaw dla wyjątków (np. nakładki, dekoracje).

• „Hug/Fill/Fixed” ustawione przypadkowo

  Objawy: tekstowe bloki raz się zawijają, raz rozciągają; przy dłuższych labelach przyciski zmieniają szerokość w niekontrolowany sposób; karty nie trzymają równej wysokości.

  Naprawa: ujednolić sposób wymiarowania: elementy treściowe zwykle powinny dopasowywać się do zawartości, a elementy strukturalne (kolumny, kontenery) wypełniać dostępne miejsce lub mieć stały wymiar, jeśli tego wymaga projekt.

• Różne style odstępów (brak konsekwentnej skali spacing)

  Objawy: podobne przerwy mają wartości typu 13, 15, 18; wizualnie „prawie” jest ok, ale całość wygląda mniej równo i trudniej to utrzymać w kolejnych ekranach.

  Naprawa: ogranicz liczbę używanych wartości odstępów i trzymaj się jednej skali w obrębie projektu; poprawki wprowadzaj „od źródła” (na poziomie komponentów), a nie ręcznie na instancjach.

• Wyrównywanie do pikseli „na siłę” (pixel-perfect bez reguł)

  Objawy: elementy są przesuwane o 1 px tu i tam, żeby „lepiej wyglądało”, ale potem trudno utrzymać konsekwencję między ekranami i wariantami.

  Naprawa: jeśli korygujesz wizualnie, rób to konsekwentnie w ramach jednego systemu (np. zawsze ten sam offset dla danej klasy elementów) i tylko wtedy, gdy nie psujesz osi i wspólnych linii układu.

• Niestabilne komponenty (nadpisania w instancjach zamiast poprawy w masterze)

  Objawy: każda instancja komponentu jest „trochę inna”; po zmianie mastera część ekranów wymaga ręcznych poprawek.

  Naprawa: napraw problem u źródła: popraw strukturę komponentu bazowego (padding, wyrównania, zachowanie tekstu) i ogranicz ręczne nadpisania w instancjach do minimum.

• Ukryte elementy i warstwy wpływające na wyrównania

  Objawy: zaznaczenie kontenera pokazuje „dziwne” wymiary; wyrównanie do krawędzi daje niespodziewany odstęp; tło ma większy rozmiar niż widoczny content.

  Naprawa: sprawdź, czy w kontenerze nie ma niewidocznych obiektów, warstw z zerową przezroczystością, obrysów, efektów cienia lub elementów poza obszarem widocznym, które zaburzają bounding box.

• Brak wspólnych punktów odniesienia między sekcjami

  Objawy: sekcje są poprawne lokalnie, ale na długiej stronie widać „złamania” rytmu: inne początki linii tekstu, inne osie kart, inne szerokości modułów.

  Naprawa: zdefiniuj kilka stałych osi, do których „łapiesz” większość elementów (np. lewa krawędź treści, oś kolumn, stała szerokość kontenera) i konsekwentnie je stosuj na wszystkich ekranach tego typu.

Szybki przebieg diagnostyki: zacznij od hierarchii i kontenerów (czy wszystko jest „w środku”), potem sprawdź reguły zachowania przy zmianie rozmiaru (przywiązania i rozciąganie), a na końcu ujednolić wartości odstępów i osie wyrównań. To zwykle usuwa 80% przypadków „pływania” bez przebudowy całego projektu.

8. Checklist końcowy: spójność danych i czytelność (etykiety, skale, kontrast, dostępność)

Ostatni krok przed przekazaniem projektu to szybki przegląd, czy układ nie tylko „trzyma się siatki”, ale też jest zrozumiały, przewidywalny i dostępny. Poniższa checklista pomaga wychwycić najczęstsze problemy z prezentacją danych, hierarchią informacji i czytelnością.

• Hierarchia informacji jest jednoznaczna: najważniejsze elementy (nagłówki, KPI, CTA, kluczowe filtry) mają wyraźny priorytet wizualny, a elementy pomocnicze nie konkurują z nimi.
• Etykiety są konsekwentne: nazwy pól, przycisków i filtrów używają tego samego słownictwa, formy (np. tryb rozkazujący w CTA) oraz tej samej kapitalizacji.
• Jednostki i formaty danych są spójne: waluty, procenty, skróty, daty i godziny mają jeden standard zapisu w całym interfejsie (również w tooltipach, legendach i eksportach).
• Skale i osie w wizualizacjach nie wprowadzają w błąd: zakresy są czytelne, punkty odniesienia (0, min/max) są jasno zakomunikowane, a porównania między kartami/metrami nie mieszają różnych skal bez wyraźnej informacji.
• Kolor nie jest jedynym nośnikiem znaczenia: stany (błąd/sukces/ostrzeżenie), serie na wykresach i statusy mają dodatkowe wsparcie w postaci ikon, wzorów, etykiet lub tekstu.
• Kontrast jest wystarczający: tekst, ikony i kluczowe linie (np. na wykresach) nie „znikają” na tle; elementy drugorzędne są nadal czytelne, tylko mniej dominujące.
• Rozmiary i waga typografii są konsekwentne: te same role (np. nagłówek sekcji, podpis, etykieta pola) mają identyczne parametry w całym projekcie, bez przypadkowych odchyleń.
• Gęstość informacji jest kontrolowana: dashboardy nie są przeładowane, a w web/mobile kluczowe treści nie giną przez nadmiar detali; tam gdzie trzeba, stosowane są skróty z możliwością rozwinięcia.
• Stany komponentów są kompletne: widoki pustego stanu, ładowania, błędu, braku uprawnień oraz stanów interakcji (hover/focus/disabled) są przewidziane i opisane.
• Teksty są zrozumiałe i „scannable”: mikrocopy jest konkretne, unika żargonu, a dłuższe treści są podzielone na krótkie fragmenty (nagłówki, listy, wyróżnienia).
• Interakcje są przewidywalne: elementy klikalne wyglądają jak klikalne, a nieklikalne nie udają akcji; miejsca kliknięcia są wystarczająco duże, zwłaszcza na mobile.
• Focus i nawigacja klawiaturą są przemyślane: kolejność przechodzenia jest logiczna, a stan focus jest widoczny i nie ginie na tle.
• Dostępność jest uwzględniona w treści: ikony mają sens bez koloru, komunikaty błędów mówią co i jak poprawić, a treści wrażliwe (np. ostrzeżenia) nie opierają się wyłącznie na subtelnych różnicach.
• Przypadki brzegowe danych są sprawdzone: bardzo długie nazwy, duże liczby, brak danych, wartości ujemne, wartości skrajne oraz lokalizacje językowe nie psują czytelności i nie łamią układu.
• Legenda i etykiety wykresów są jednoznaczne: użytkownik rozumie, co oznacza każda seria, kolor i metryka; skróty są rozwinięte w razie potrzeby.
• Ikony są spójne stylistycznie: ta sama grubość linii, zaokrąglenia i sposób użycia (z tekstem lub bez), bez mieszania różnych zestawów.
• Warstwy i nazewnictwo ułatwiają współpracę: kluczowe grupy, sekcje i komponenty są nazwane w sposób opisowy, co zmniejsza ryzyko błędów przy dalszych iteracjach.

Jeśli większość punktów przechodzi bez wahań, projekt jest zwykle gotowy do handoffu: dane są przedstawione konsekwentnie, a interfejs pozostaje czytelny w typowych i nietypowych scenariuszach.

Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy ten temat w praktyce.

Rekomendacje następnego kroku w aplikacji: agent vs klasyczny ML (bandyty, sekwencje, reguły) 24 kwietnia 2026

Dataviz dla ESG: jak pokazywać emisje, cele i luki bez greenwashingu na wykresach 22 kwietnia 2026