Ta sama strona, to samo doświadczenie, a wycena potrafi różnić się 10×

To jeden z tych tematów, które wyglądają jak „dziwactwo branży”, dopóki nie zobaczysz pracy od środka. Dwie osoby o podobnym doświadczeniu potrafią wycenić ten sam projekt strony internetowej w skrajnie inny sposób. Jeden UX/UI designer mówi: 25 godzin przy 180 zł/h, czyli 4 500 zł. Drugi: 250 godzin przy 180 zł/h, czyli 45 000 zł. I wcale nie musi chodzić o to, że ktoś „naciąga”. Często chodzi o warsztat, który na zewnątrz jest niewidoczny, a w środku robi różnicę dziesięciokrotną.

Wiele osób zakłada, że czas projektu to głównie myślenie: koncepcja, układ treści, logika ścieżek. I jasne, to jest fundament. Ale kiedy koncepcja jest podobna, a różnica nadal jest ogromna, odpowiedź zwykle leży w sposobie wykonania. W tym, czy projektowanie w Figma jest płynnym składaniem makiety UX/UI z gotowych, reużywalnych elementów, czy ręcznym rysowaniem wszystkiego od zera.

Czego dowiesz się z tego artykułu

• Dowiesz się, skąd naprawdę biorą się różnice w wycenach, gdy pozornie zakres i doświadczenie są podobne.
  Zrozumiesz, jak warsztat w Figma wpływa na koszt i tempo pracy nad makietą strony internetowej oraz liczbę poprawek.
• Zobaczysz, dlaczego „makieta UX” może powstawać sprawnie albo boleśnie wolno, mimo podobnego pomysłu na całość.
• Poznasz konkretne przykłady, jak komponenty, stany i auto-layout skracają czas pracy nad makietą aplikacji i makietą UX/UI.
• Dostaniesz prosty sposób, by rozmawiać o wycenie z projektantem bez wojny o stawki i bez niedomówień.

Dwie wyceny, jeden zakres, dwie rzeczywistości

Wyobraź sobie, że obaj projektanci mają w głowie podobny plan. Wiedzą, jak poprowadzić użytkownika, co jest ważne na stronie, jak ustawić hierarchię, gdzie musi pojawić się zaufanie i jak domknąć działanie. I tu zaczyna się różnica, która nie wynika z „myślenia UX”, tylko z mechaniki pracy.

Projektant A buduje makietę Figma na komponentach i wariantach. Przycisk nie jest przyciskiem narysowanym raz. Jest komponentem z różnymi stanami: domyślny, hover, disabled, loading. Karta produktu nie jest kopiowana i poprawiana ręcznie, tylko ma swoją logikę. Układ sekcji nie jest ustawiany „na oko”, tylko wynika z auto-layoutu. Zmiana jednego detalu nie oznacza przesuwania całego ekranu, bo wszystko jest ułożone systemowo.

Projektant B rysuje element po elemencie. Wyrównuje ręcznie. Kopiuje i poprawia ręcznie. Kiedy przychodzi feedback, zmiana jednego parametru zaczyna ciągnąć za sobą cały ekran. A potem kolejny ekran. A potem jeszcze kolejny. W efekcie ta sama makieta UX/UI potrafi kosztować kilkanaście razy więcej godzin nie dlatego, że jest lepsza, tylko dlatego, że powstała „ręcznie”.

Makieta strony internetowej jako projekt, a nie grafika do oglądania

Klient widzi finalny efekt: makieta strony internetowej wygląda podobnie w obu przypadkach. Czasem nawet identycznie. Ale koszt powstaje w tle, w tym, ile razy trzeba coś przestawić, dopracować i dostosować. I tu warsztat ma ogromne znaczenie.

Makieta UX i makieta UX/UI nie są jednorazowym rysunkiem. To narzędzie do rozmowy i iteracji. Im projekt większy, im więcej interesariuszy i im bardziej prawdopodobny feedback, tym bardziej liczy się sposób, w jaki makieta jest zbudowana. Jeśli jest zbudowana jak dom z kart, każda poprawka jest drogą przez mękę. Jeśli jest zbudowana jak system, poprawki są naturalną częścią pracy, a nie „przerabianiem wszystkiego od nowa”.

W praktyce oznacza to, że dwie identyczne stawki godzinowe nie mówią nic o finalnym koszcie. Możesz mieć 180 zł/h i płacić 4 500 zł, a możesz mieć 180 zł/h i płacić 45 000 zł, bo po prostu kupujesz inną efektywność.

Dlaczego to ma znaczenie jeszcze bardziej przy makiecie aplikacji

W aplikacjach skala zwykle rośnie szybciej. Więcej stanów, więcej wariantów, więcej zależności. Makieta aplikacji, która na początku wygląda na „kilkanaście ekranów”, często po tygodniu ma już drugie tyle, bo dochodzą stany: puste, błędy, loading, różne role użytkowników. Wtedy projektant bez systemu dostaje efekt kuli śnieżnej.

Kiedy UX/UI designer ma Figmę „w ręce”, potrafi budować makietę aplikacji jak układanie klocków. Nie chodzi o sztuczki. Chodzi o to, że komponenty, stany i auto-layout robią porządek tam, gdzie inaczej zaczyna się manualna walka z narzędziem. I to jest wprost przekładalne na koszt. Klient finalnie nie płaci za to, że ktoś zna skrót klawiszowy. Klient płaci za to, że poprawka, która powinna trwać godzinę, nie trwa ośmiu.

Narzędzie nie jest najważniejsze. Ale bywa decydujące dla budżetu

W zeszłym tygodniu pisałem o tym, że narzędzie nie jest sednem UX/UI. To nadal prawda. Sednem jest myślenie: cel, użytkownik, wartość, logika ścieżek. Ale jeśli Figma nie jest dla projektanta „trzecią ręką”, to koszt ponosi klient. Tak samo jak w każdej pracy: możesz mieć świetne pomysły, ale jeśli wykonanie jest wolne i chaotyczne, rachunek rośnie szybciej niż wartość.

Dlatego w pracy mentoringowej i na kursach cisnę rzeczy, które dla wielu są „drugorzędne”: skróty, workflow, auto-layout, komponenty, stany, projektowanie systemowe. Nie po to, żeby było bardziej „pro”, tylko po to, żeby jakość nie kosztowała 10× więcej godzin. To jest jedna z najbardziej praktycznych różnic między osobą, która projektuje, a osobą, która projektuje skutecznie w realnym czasie.

Jeśli interesuje Cię temat opanowania Figmy tak, żeby realnie przyspieszała pracę nad makietą UX/UI i żeby projektowanie w Figma było przewidywalne czasowo, zebrałem to w moich kursach UX/UI: https://ux-man.pl/kursy-ux-ux-designer

Jeśli chcesz zobaczyć, jak to przekłada się na realne deliverable’e, tutaj masz opis mojej pracy nad makietą strony internetowej i sklepu: https://ux-man.pl/makieta-ux-ui-design-strony-internetowej-sklepu oraz nad makietą aplikacji w Figma: https://ux-man.pl/makieta-ux-ui-design-aplikacji .

Pytania i odpowiedzi

Czy wysoka liczba godzin zawsze oznacza lepszą jakość makiety?

Nie. Wysoka liczba godzin może oznaczać złożony projekt, ale może też oznaczać wolny sposób pracy. Warto dopytać, co jest w tych godzinach: struktura, sitemapa, makieta UX, makieta UX/UI, iteracje, stany, design system, przygotowanie do wdrożenia.

Jak klient może porównać dwie wyceny, jeśli obie brzmią sensownie?

Najlepiej porównać założenia: ile ekranów i typów widoków, ile rund poprawek, czy wchodzą stany i warianty, czy powstaje system komponentów w Figma. Dwie wyceny często różnią się nie stawką, tylko modelem pracy i tym, co projektant bierze na siebie.

Czy „szybciej” może oznaczać „gorzej”?

Może, jeśli szybkość bierze się z pójścia na skróty w myśleniu. Ale jeśli szybkość wynika z dobrego workflow i automatyzacji, to zazwyczaj jest odwrotnie: jest więcej przestrzeni na dopracowanie, test scenariuszy i sensowne iteracje, bo czas nie ucieka na ręczne dłubanie.

Jakie umiejętności Figmy najbardziej wpływają na czas projektu?

W praktyce: auto-layout, komponenty i warianty (stany), biblioteki, style, konsekwentny system spacing/typografii oraz skróty i workflow. To są rzeczy, które decydują, czy makieta Figma skaluje się płynnie, czy rozpada przy pierwszych poprawkach.

Czy warto pytać projektanta o sposób pracy w Figma?

Tak. To jedno z najtańszych pytań, które potrafi oszczędzić budżet. Jeśli projektant mówi o systemie komponentów, stanach, reużywalności i tym, jak obsługuje zmiany, zwykle jest to dobry znak, że makieta UX/UI będzie „żywa” i odporna na feedback.

Na koniec

Wycena to nie tylko liczba godzin i stawka. To także to, czy projektant ma narzędzie opanowane na poziomie, który pozwala mu dowozić szybko, konsekwentnie i bez przepalania czasu na ręczne poprawki. I to jest jedna z tych różnic, które widać dopiero wtedy, gdy raz przeżyjesz projekt, w którym każda drobna zmiana kosztuje dzień pracy.

Co u Ciebie w ostatnim czasie najbardziej przyspieszyło pracę: zmiana podejścia, lepszy proces, czy małe usprawnienia w codziennym wykonaniu?