Projektowanie UI UX w Figmie — po co makieta przed kodem
Co dostajesz na etapie projektu w Figmie, jak czytać prototyp, żeby wyłapać błąd zawczasu, i dlaczego zmiana w makiecie kosztuje ułamek tego samego w kodzie.
Karol Łukaszuk
Karol Łukaszuk — solo developer z Białej Podlaskiej. Od 2025 robi strony i aplikacje dla małych firm: stała cena w umowie, faktura VAT, kod należy do klienta.
Makieta w Figmie powstaje przed kodem po to, żeby spory o wygląd kosztowały minuty zamiast dni. Przesunięcie sekcji w projekcie to kilka kliknięć. To samo przesunięcie w gotowym kodzie oznacza poprawki w układzie, na telefonie, w animacji i ponowne testy. Poniżej pokazuję, co dostajesz na etapie projektu, jak czytać prototyp, żeby wyłapać błąd zawczasu, i jak wygląda akceptacja z dwiema rundami poprawek w cenie.
Figma to program do projektowania interfejsów, który działa w przeglądarce. Nie musisz niczego instalować ani kupować — dostajesz link, klikasz i oglądasz. Tyle wiedzy technicznej wystarczy.
Co dostajesz na etapie projektu
Projekt to nie jeden obrazek. To zestaw plików, na podstawie których powstaje strona — i który zostaje Twoją własnością po odbiorze.
- Makieta każdej podstrony w dwóch szerokościach — telefon i komputer. Telefon zawsze pierwszy, bo stamtąd przychodzi większość ruchu.
- Prototyp klikalny — makieta z podpiętymi przejściami. Klikasz „Usługi" i przechodzisz na podstronę usług, tak jak zrobi to Twój klient.
- Zestaw kolorów i krojów pisma, opisany i spójny. To ta sama paleta, która trafi potem do kodu.
- Stany elementów — jak wygląda przycisk po najechaniu, jak wygląda formularz z błędem, co widać, gdy lista jest pusta.
- Ostateczna treść w miejscach docelowych. Nie „Lorem ipsum", tylko Twoje nagłówki i opisy usług, bo dopiero one pokazują, czy układ się broni.
Ostatni punkt bywa niedoceniany. Projekt wypełniony tekstem zastępczym wygląda ładnie zawsze. Prawdziwa nazwa usługi, która ma siedem słów zamiast dwóch, potrafi rozłożyć cały nagłówek.
Dlaczego zmiana w Figmie kosztuje ułamek zmiany w kodzie
To najważniejsza rzecz w tym wpisie i warto ją pokazać na konkretnym przykładzie.
Prośba: „przenieśmy cennik nad opinie i zróbmy z niego tabelę zamiast kafelków".
| Etap | Co trzeba zrobić | Skala |
|---|---|---|
| W Figmie | przesunąć sekcję, zamienić układ na tabelę, sprawdzić wersję mobilną | minuty |
| W kodzie | przepisać komponent, dopasować układ na trzech szerokościach ekranu, poprawić odstępy sąsiadów, sprawdzić animacje wejścia, zaktualizować testy automatyczne, przejrzeć wynik na urządzeniach | godziny, czasem dzień |
Skąd ta różnica: w Figmie przesuwasz obrazek strony. W kodzie zmieniasz działający mechanizm, który ma sąsiadów, zachowuje się inaczej na każdej szerokości i jest objęty testami. Dlatego decyzje o układzie zapadają na etapie, na którym są tanie.
Jest jeszcze druga korzyść, mniej oczywista: makieta zmusza do rozstrzygnięcia, co jest najważniejsze na stronie. Kiedy widzisz pusty ekran telefonu i wiesz, że mieszczą się w nim trzy rzeczy, wybór staje się konkretny.
Jak czytać prototyp, żeby wyłapać błąd zawczasu
Dostajesz link i pierwszym odruchem jest ocena „ładne — nieładne". To najmniej użyteczne pytanie. Przejdź zamiast tego przez tę listę:
- Otwórz prototyp na telefonie, nie na komputerze. Tak zrobi Twój klient.
- Odlicz trzy sekundy i sprawdź, czy z tego, co widać bez przewijania, wynika, czym się zajmujesz i gdzie kliknąć.
- Znajdź numer telefonu. Ile ruchów palcem zajęło?
- Przejdź drogę klienta do końca — od wejścia do wysłania formularza albo wybrania numeru. Policz kliknięcia.
- Wczytaj się w teksty. Czy nazwy usług są takie, jakich używają Twoi klienci, czy takie, jakich używasz Ty w rozmowie z branżą?
- Sprawdź, czego brakuje. Godziny otwarcia, dojazd, parking, ceny, obszar działania — te pytania i tak dostajesz przez telefon.
- Wypisz uwagi w jednej wiadomości, punkt po punkcie, z nazwą sekcji. To skraca rundę poprawek o połowę.
Uwaga „coś mi tu nie gra" jest zrozumiała, ale kosztowna. Uwaga „nagłówek nie mówi, że dojeżdżam do klienta" da się poprawić od razu.
Akceptacja i rewizje — jak to wygląda w praktyce
W pakietach z projektem graficznym są dwie rundy poprawek w cenie. Przebieg wygląda tak:
- Brief — rozmowa i formularz. Ustalamy, kto jest Twoim klientem i co ma się wydarzyć po wejściu na stronę.
- Projekt — makieta strony głównej i jednej podstrony wzorcowej. Dostajesz link do Figmy.
- Runda pierwsza — Twoje uwagi, moje poprawki. Tu zapadają decyzje o układzie i kolorach.
- Runda druga — dopięcie szczegółów: odstępy, teksty przycisków, dobór zdjęć.
- Akceptacja — potwierdzasz projekt, dopiero potem zaczyna się kod.
- Wdrożenie na adresie testowym, który widzisz od pierwszego dnia prac.
Dwie rundy to nie jest sztuczne ograniczenie, tylko granica, po przekroczeniu której zmiany zwykle przestają być poprawianiem, a stają się nowym pomysłem. Jeśli po drugiej rundzie chcesz zmienić kierunek, przygotowuję aneks przed pracami, ze stałą kwotą — nigdy dopłata po fakcie. Cały przebieg opisałem szerzej na stronie proces.
Kiedy makieta nie jest potrzebna
Powiem szczerze: nie w każdym projekcie ma sens.
- Przy jednej podstronie z formularzem (pakiet Mini za 690 zł) projekt bywa droższy niż wartość, którą wnosi. Prościej pokazać gotową stronę na adresie testowym i poprawić na miejscu.
- Przy odświeżeniu istniejącej strony, gdzie układ zostaje, a zmienia się kolorystyka i zdjęcia.
- Przy stronie wydarzenia z terminem ważności, gdzie liczy się tempo.
Osobne zamówienie samego projektu UI/UX zaczyna się u mnie od 400 zł — bywa to sensowne, gdy stronę ma wdrożyć ktoś inny albo gdy chcesz najpierw zobaczyć kierunek, zanim zdecydujesz o całości. Zakres opisałem w usłudze projektowanie UI/UX.
Najczęstsze pytania
Czy muszę znać Figmę, żeby obejrzeć projekt?
Nie. Dostajesz link, otwierasz w przeglądarce lub na telefonie i klikasz. Komentarz zostawiasz albo w wiadomości, albo bezpośrednio przy elemencie — pokazuję to na pierwszej rozmowie.
Czy projekt należy do mnie?
Tak. Po odbiorze pliki projektowe i kod przechodzą na Twoją własność. Możesz przekazać je innemu wykonawcy.
Co, jeśli po zobaczeniu projektu stwierdzę, że to nie to?
Jeśli po pierwszym dniu prac uznasz, że współpraca nie ma sensu, zwracam 100% zaliczki. Bez negocjacji i bez tłumaczenia się.
Ile trwa etap projektowy?
Zwykle 2–4 dni roboczych do pierwszej wersji, licząc od kompletnego briefu. Terminy całych pakietów to 3–5 dni (Mini), 7–10 dni (Standard) i 2–3 tygodnie (Pro) — etap projektowy mieści się w nich, a nie dochodzi do nich.
Czy dostanę projekt przed podpisaniem umowy?
Rozmowa i wycena w PDF są bezpłatne i bez zobowiązań. Projekt jest już pracą i zaczyna się po umowie oraz zaliczce — z zapisanym zwrotem, jeśli po pierwszym dniu zmienisz zdanie.
Co z tym zrobić
Zanim zamówisz stronę, przygotuj trzy rzeczy: listę usług nazwanych językiem Twoich klientów, jedno zdanie o tym, co ma zrobić osoba wchodząca na stronę, i zdjęcia, które masz. To wystarczy, żeby makieta powstała bez zgadywania.
Jeśli chcesz zobaczyć kierunek przed decyzją o całości, napisz — na podstawie briefu odsyłam wycenę z terminem w 24 godziny, bez zobowiązań. Jak przygotować dobry brief, rozpisałem we wpisie jak przygotować brief na stronę.
O autorze
Karol Łukaszuk
Karol Łukaszuk — solo developer z Białej Podlaskiej. Od 2025 robi strony i aplikacje dla małych firm: stała cena w umowie, faktura VAT, kod należy do klienta.