Projektowanie UI UX strony internetowej w Figmie
Jak projektuję UI UX strony internetowej w Figmie: od makiety lo-fi, przez hi-fi i klikalny prototyp, po akceptację. Po co ten etap i co zyskujesz, zanim powstanie kod.
Karol Mazek
Solo full-stack developer z Białej Podlaskiej. Od 2025 robi strony i aplikacje dla małych firm — fixed-price, na fakturę VAT, kod należy do klienta.
Zanim na twojej stronie pojawi się choćby linijka kodu, powstaje projekt. To etap, na którym decyduje się, czy strona będzie czytelna, czy klient szybko znajdzie kontakt i czy całość będzie wyglądać jak twoja marka, a nie jak kolejny szablon. Robię to w Figmie — i w tym tekście pokazuję krok po kroku, jak wygląda projektowanie UI UX strony internetowej, zanim cokolwiek trafi do produkcji.
Piszę to dla osoby, która zamawia stronę pierwszy raz i nie do końca wie, za co właściwie płaci na etapie „projektu”. Krótko: płacisz za to, żeby zobaczyć i zaakceptować całą stronę, zanim powstanie jako kod. To najtańszy moment na zmiany — w Figmie przesunięcie sekcji to minuty, w gotowym kodzie to godziny.
Czym jest UI, czym jest UX — bez żargonu
Te dwa skróty mylą się notorycznie, więc po ludzku:
- UX (User Experience) to jak się z tego korzysta. Czy klient w trzy sekundy rozumie, co oferujesz. Czy przycisk „Umów wizytę” jest tam, gdzie go szuka. Czy ścieżka od wejścia do kontaktu jest krótka i bez tarcia.
- UI (User Interface) to jak to wygląda. Kolory, typografia, odstępy, ikony, zdjęcia, mikrointerakcje. Warstwa wizualna, która buduje wiarygodność i spójność z twoją marką.
Dobra strona potrzebuje obu. Ładny interfejs bez przemyślanego UX to galeria, która nie sprzedaje. Sprawny UX bez UI wygląda jak surowy szkielet, któremu nikt nie ufa. Projekt w Figmie godzi jedno z drugim, zanim zaczniemy kodować.
Dlaczego Figma, a nie Photoshop czy „od razu kod”
Figma działa w przeglądarce, więc nie musisz nic instalować. Wysyłam ci link, ty otwierasz na telefonie albo na laptopie i komentujesz bezpośrednio przy danym elemencie — „ten przycisk wyżej”, „logo za małe”. Bez zrzutów ekranu krążących po mailu, bez plików, których nie da się otworzyć.
Drugi powód jest praktyczny. Projektowanie strony „od razu w kodzie” brzmi szybciej, ale jest pułapką: każda zmiana układu wymaga przebudowy i testów. W Figmie tasujemy sekcje, kolory i nagłówki w minuty. Dopiero gdy projekt jest zaakceptowany, przekładam go na Next.js, React i Tailwind — i wtedy kod robi się raz, porządnie.
Mój proces w Figmie — krok po kroku
Pracuję etapami, żebyś widział postęp i miał wpływ na każdy z nich.
1. Brief i architektura informacji
Najpierw ustalamy cel strony, grupę docelową i to, co klient ma zrobić — zadzwonić, wypełnić formularz, zarezerwować. Z tego wynika, jakie podstrony są potrzebne i w jakiej kolejności układają się sekcje. Jeśli nie masz jeszcze materiałów, podpowiadam, jak przygotować brief na stronę, żeby ten etap poszedł gładko.
2. Makieta lo-fi (wireframe)
Szkielet bez kolorów i zdjęć. Skupiamy się wyłącznie na strukturze: gdzie nagłówek, gdzie oferta, gdzie CTA, jak prowadzi ścieżka użytkownika. To etap na śmiałe zmiany — wszystko jest jeszcze tanie i szybkie do przestawienia.
3. Projekt hi-fi (high-fidelity)
Dokładny wygląd gotowej strony: kolory, typografia, zdjęcia, odstępy, mikrointerakcje. Widzisz dokładnie to, co dostaniesz po wdrożeniu — żadnych niespodzianek typu „myślałem, że będzie inaczej”. Projektuję mobile-first, bo większość ruchu lokalnego biznesu to telefony.
4. Klikalny prototyp
W Figmie da się połączyć ekrany w działający prototyp — klikasz przyciski, przechodzisz między podstronami, czujesz nawigację jeszcze przed kodem. To moment, w którym wychodzą rzeczy, których nie widać na statycznym obrazku.
5. Akceptacja i przekazanie do developmentu
Gdy projekt jest zatwierdzony, zamykam etap UI/UX i przechodzę do kodu. Akceptacja projektu jest punktem odniesienia — to, co zaklikałeś w Figmie, to, co zobaczysz na żywo.
Co zyskujesz dzięki temu etapowi
Projekt w Figmie to nie „dodatkowy koszt”, tylko zabezpieczenie twoich pieniędzy i czasu:
- Widzisz całość przed kodem — akceptujesz świadomie, nie w ciemno.
- Tanie poprawki — zmiany na etapie projektu są szybkie; w gotowym kodzie kosztują znacznie więcej.
- Brak nieporozumień — projekt jest umową wizualną. Wiadomo, co powstanie.
- Lepszy efekt biznesowy — przemyślany UX prowadzi klienta prosto do kontaktu, a nie po krętej ścieżce.
- Spójność z marką — typografia, kolory i ton dopasowane do tego, kim jesteś.
U mnie ten etap prowadzi jedna osoba — ta sama, która potem pisze kod. Nie ma efektu głuchego telefonu między „działem projektowym” a „działem programistów”. To, co zaprojektowane, jest dokładnie tym, co zakodowane.
UX to nie gust, tylko decyzje oparte na celu
Najczęstszy błąd przy projektowaniu strony to traktowanie go jak konkursu piękności — „podoba mi się / nie podoba mi się”. Estetyka jest ważna, ale to nie ona decyduje, czy klient zadzwoni. Dlatego każdą decyzję w projekcie podpinam pod cel biznesowy, nie pod prywatny gust:
- Hierarchia treści — najważniejsza rzecz (co robisz i jak się skontaktować) musi być widoczna bez przewijania. Reszta układa się pod spodem według wagi.
- Rozmieszczenie CTA — przycisk akcji powtarza się tam, gdzie klient jest gotów go kliknąć, a nie tylko raz na samym dole.
- Mobile-first — większość ruchu lokalnego biznesu to telefon, więc projekt zaczyna się od ekranu telefonu, a dopiero potem rozwijam go na desktop.
- Mniej znaczy więcej — usuwam wszystko, co odciąga od głównego celu strony. Każda sekcja musi mieć powód, dla którego tam jest.
Najlepszy interfejs to taki, którego użytkownik nie musi się uczyć. Jeśli klient zastanawia się, gdzie kliknąć, to nie jego wina — to wina projektu. Dlatego makietę testuję pod kątem ścieżki użytkownika, zanim w ogóle dobiorę kolory.
Ile to trwa i kiedy widzisz pierwszy projekt
Przy stronie usługowej etap projektu to zwykle kilka dni — od briefu, przez makietę, po hi-fi i prototyp. Cały czas dostajesz link do Figmy, więc komentujesz na bieżąco, bez czekania na finalną wersję. Im szybszy feedback z twojej strony, tym szybciej domykamy projekt i ruszamy z kodem.
Największym hamulcem na tym etapie nie jest projektowanie, tylko komunikacja. Jeśli odpowiadasz na propozycje w ciągu dnia czy dwóch, projekt domyka się błyskawicznie. Jeśli feedback przychodzi po dwóch tygodniach, etap się rozciąga — nie dlatego, że praca trwa, tylko dlatego, że czekamy na decyzję. Dlatego z góry ustalam, kto po twojej stronie zatwierdza projekt, żeby nie utknąć w „muszę to z kimś skonsultować”.
Jeśli chcesz, żeby twoja strona była zaprojektowana świadomie, a nie złożona z gotowca, opisz mi swój pomysł. Odeślę propozycję zakresu, terminu i stałą cenę — z projektem UI/UX wliczonym w proces, nie doklejonym jako niespodzianka na fakturze.
Czy projekt w Figmie jest osobno płatny?
Nie traktuję go jako oddzielnej usługi doklejanej do faktury. Projektowanie UI/UX jest częścią procesu tworzenia strony i mieści się w stałej cenie pakietu. Wyjątkiem jest sytuacja, gdy chcesz wyłącznie projekt w Figmie bez wdrożenia — wtedy ustalamy zakres osobno.
Ile rund poprawek mam na etapie projektu?
Nie liczę poprawek na sztuki. Na etapie makiety i projektu hi-fi dopracowujemy stronę, aż będzie zgodna z tym, o co nam chodziło. Liczy się efekt, nie limit rund — dlatego ważne jest, żeby projekt został świadomie zaakceptowany przed przejściem do kodu.
Czy dostanę plik z Figmy?
W trakcie pracy masz dostęp do projektu przez link do komentowania i podglądu. Gotowa strona trafia do ciebie jako działający kod w repozytorium — to on jest produktem końcowym. Eksport źródłowego pliku Figmy ustalamy indywidualnie, jeśli go potrzebujesz.
O autorze
Karol Mazek
Solo full-stack developer z Białej Podlaskiej. Od 2025 robi strony i aplikacje dla małych firm — fixed-price, na fakturę VAT, kod należy do klienta.