Jak wybrać agencję UX/UI

Wybór agencji UX/UI opłaca się oprzeć na pięciu filarach: zweryfikowanym doświadczeniu w podobnej skali projektów (liczy się zakres faktycznie wykonanej pracy, nie sama nazwa klienta w portfolio), dostępności konkretnego zespołu, jasno zdefiniowanym procesie z podziałem na etapy, przejrzystym modelu wyceny oraz jakości pytań, które agencja zadaje na starcie współpracy.

Polskie prawo zamówień publicznych wprost zakazuje wyboru wyłącznie na podstawie ceny przy pracach o charakterze twórczym, a projektowanie UX się do nich zalicza (art. 243 ustawy Pzp). Dane McKinsey pokazują z kolei, że duże projekty IT bez odpowiedniego zarządzania dostawcą i ryzykiem przekraczają budżet średnio o 45%. Poniżej rozkładamy to na konkretne kryteria, pytania i sygnały ostrzegawcze.

Dlaczego wybór agencji to decyzja o ryzyku finansowym, nie tylko estetycznym

Wybór partnera projektowego bywa traktowany jako decyzja o "guście", czyli o tym, który zespół zaprojektuje ładniejszy interfejs. To błąd, który kosztuje więcej, niż się wydaje. McKinsey & Company i University of Oxford przebadali ponad 5400 dużych projektów IT o budżecie wyjściowym przekraczającym 15 mln USD. Duże projekty IT przekraczają w nich budżet średnio o 45%, harmonogram o 7% i dostarczają o 56% mniej wartości biznesowej niż zakładano na starcie ^[1]. Badanie ma już kilkanaście lat (2012) i dotyczy dużych wdrożeń enterprise, nie każdego projektu redesignu. Mechanizm, który opisuje, jest jednak wciąż aktualny: im mniej kontroli nad zakresem i dostawcą, tym większe ryzyko finansowe.

W tym samym badaniu projekty o charakterze software'owym wypadają najgorzej ze wszystkich kategorii: średnie przekroczenie budżetu sięga tam 66% ^[1]. Autorzy zwracają też uwagę na zjawisko "czarnych łabędzi". Chodzi o 17% dużych projektów IT, w których przekroczenie budżetu przekracza 200%, a w skrajnych przypadkach nawet 400%. Taka skala realnie zagraża kondycji finansowej organizacji ^[1].

Najbardziej konkretny fragment raportu dotyczy wprost wyboru dostawcy. McKinsey opisuje przypadek banku na Bliskim Wschodzie, który wynegocjował bardzo korzystną cenę z dostawcą, a następnie ucierpiał z powodu niedoświadczonego zespołu wykonawczego tego dostawcy ^[1]. Rekomendacja, która z tego wynika, jest prosta: "dobre zarządzanie interesariuszami wymaga przezorności przy wyborze dostawców i negocjowaniu z nimi umów. Negocjatorzy powinni proaktywnie identyfikować potencjalne ryzyka i rozszerzać punkt widzenia poza cenę jednostkową" ^[1]. Innymi słowy, cena kontraktu to tylko jeden z parametrów decyzji, i czasem najmniej informacyjny.

Jak wygląda proces wyboru agencji w praktyce

Nie ma jednego uniwersalnego schematu wyboru agencji UX. W projektach dla większych organizacji powtarza się jednak pewien wzorzec. W grze jest zwykle od 3 do 6 agencji. Proces składa się z 2-4 realnych etapów: zapytania, oferty, czasem prezentacji lub pitchu, negocjacji. Całość trwa od kilku tygodni do kilku miesięcy. W organizacjach regulowanych, na przykład przy projektowaniu UX dla bankowości, proces potrafi się wydłużyć znacznie bardziej. Nie dlatego, że sam wybór agencji jest trudny, lecz dlatego, że po nim następują procedury zakupowe, prawne i bezpieczeństwa, które w praktyce są osobnym projektem.

Po stronie klienta w procesie uczestniczy zwykle kilka różnych ról, z których każda może mieć prawo powiedzieć "nie", nawet jeśli nie każda realnie wybiera zwycięzcę. Są to: osoba inicjująca projekt (np. product owner albo dyrektor odpowiedzialny za obszar), sponsor budżetowy z prawem weta, dział IT sprawdzający integracje, dział bezpieczeństwa i compliance (szczególnie w sektorze finansowym), zakupy ustalające warunki formalne oraz prawnicy przygotowujący umowę. Im większa organizacja, tym więcej osób w tym łańcuchu. Tym większe znaczenie ma też to, żeby agencja umiała rozmawiać z każdą z tych grup, nie tylko z osobą, która napisała brief. To jest główna różnica między wyborem agencji do małego projektu a wyborem agencji do UX/UI dla dużej firmy. W drugim przypadku samo doprowadzenie procesu do decyzji jest osobną kompetencją, nie mniej istotną niż projektowanie interfejsów.

Przy tym warto znać jedną podstawę prawną. Dotyczy ona sektora publicznego, ale kształtuje też dobre praktyki w sektorze prywatnym. Ustawa Prawo zamówień publicznych w art. 243 wprost zakazuje wyboru wyłącznie na podstawie ceny w przypadku prac, których rezultatu nie można z góry opisać w sposób jednoznaczny i wyczerpujący, a projektowanie UX ze swojej natury do takich prac należy ^[2]. W praktyce jednak przepis ten bywa omijany. Według sprawozdania Prezesa Urzędu Zamówień Publicznych za 2025 rok, w 46% zamówień publicznych na usługi powyżej progów unijnych cena była jedynym kryterium wyboru, podczas gdy rok wcześniej dotyczyło to 35% postępowań ^[3]. Nasza własna analiza 200 ogłoszeń z unijnej platformy TED dotyczących usług związanych z tworzeniem serwisów internetowych pokazała, że mediana wagi przypisywanej cenie w postępowaniach wynosi 60%. Prawo idzie więc w stronę oceny wielokryterialnej, ale praktyka rynkowa wciąż silnie ciąży w stronę ceny jako głównego kryterium. Jak pokazuje sekcja poniżej, to wcale nie musi prowadzić do najlepszego wyboru.

Brief, który nie sabotuje projektu: pięć najczęstszych błędów

Jakość briefu przekłada się bezpośrednio na jakość ofert, które dostaje klient, a w konsekwencji na jakość projektu. Z naszego doświadczenia w pracy z briefami klientów enterprise wynika pięć powtarzających się błędów.

Pierwszy: brief opisuje rozwiązanie, nie problem. "Chcemy przeprojektować stronę główną i dodać kalkulator" nie mówi, dlaczego redesign strony internetowej jest potrzebny, co dokładnie nie działa dzisiaj, ani jaki wynik biznesowy ma przynieść zmiana. Agencja wtedy wycenia zadanie, a nie cel, więc obie strony przegrywają: nikt nie sprawdził, czy zaproponowane rozwiązanie faktycznie rozwiąże problem.

Drugi: pozorna precyzja zakresu. Klient bardzo dokładnie opisuje deliverables - liczbę ekranów, warsztatów, badań - zanim ktokolwiek zweryfikował, czy są one rzeczywiście potrzebne. Dostaje listę, ale nie wiadomo, co ma się dzięki niej zmienić w biznesie.

Trzeci: brak informacji o realnych ograniczeniach wdrożenia. Wdrażać projekt może własny zespół deweloperski klienta, agencja end-to-end albo zespół pracujący na istniejącym design systemie. Ten wybór zmienia wycenę nawet dwukrotnie. Szerzej opisujemy związek wdrożenia i projektowania w artykule o UX w projektowaniu stron internetowych: zmienia on zakres wymaganej dokumentacji, nie tylko liczbę plików. W naszej praktyce mieliśmy projekty dla operatora telekomunikacyjnego i dla pośrednika finansowego, w których wdrożenie w obu przypadkach leżało po stronie klienta. To trzeba było wiedzieć już na etapie briefu, bo zmieniało zakres wymaganej dokumentacji, na przykład specyfikacji stanów, walidacji i breakpointów, nie tylko liczbę przekazywanych plików. Brief, który nie precyzuje tej kwestii, gwarantuje rozjazd ofert konkurujących agencji.

Czwarty: zakres liczony w podstronach, nie w stanach czy procesach. "Piętnaście widoków" nic nie mówi o rzeczywistej złożoności. Jeden z tych widoków może być prostym formularzem kontaktowym, a inny czterdziestostanowym procesem transakcyjnym z walidacjami, komunikatami błędów i wariantem mobilnym. Brief, który nie rozróżnia ekranu statycznego od procesu, w praktyce uniemożliwia porównanie ofert.

Piąty: brak jasnej ścieżki akceptacji. Nie ma informacji, kto akceptuje kolejne etapy, ile osób opiniuje projekt i ile rund poprawek klient przewidział. W praktyce bywa, że makietę ogląda dziewięć osób z pięciu działów, każda ma swoje uwagi, a w umowie zapisano dwie rundy na etap. To, a nie jakość samego projektu, jest najczęstszym źródłem konfliktu w projektach dla dużych organizacji.

Dodatkowy, szósty wzorzec, który warto nazwać: ukryty budżet przy jednoczesnym żądaniu wyceny "co do złotówki". Klient nie podaje żadnego przedziału budżetowego, dostaje oferty różniące się trzykrotnie i wyciąga wniosek, że rynek jest nieprzewidywalny. W praktyce rynek jest przewidywalny, tylko brief był otwarty na kilka różnych interpretacji.

Dobrym testem, czy brief jest gotowy do wysłania, jest wyobrażenie sobie jego przeciwieństwa. W jednym z widzianych przez nas zapytań ofertowych cały opis potrzeby zmieścił się na jednej stronie A4 i sprowadzał się do "potrzebujemy nowego UX, ma być nowoczesnie", z trzema linkami do konkurencji i komentarzem "chcemy tak, ale lepiej". Cele były dwa i wzajemnie się wykluczające: więcej leadów z formularza, a jednocześnie mniej zgłoszeń trafiających do call center. Budżet określono jako "rynkowy", termin jako trzy tygodnie, bez żadnej informacji o systemie, na którym stała strona, dostępie do analityki czy ścieżce akceptacji. Najgorsze w tym briefie nie było to, że był krótki. Krótki brief jest w porządku, jeśli klient uczciwie mówi "nie wiemy jeszcze, pomóżcie nam to zdefiniować". Najgorsze było to, że udawał precyzyjny, mimo że nie definiował niczego, co realnie pozwalałoby wycenić i zaplanować projekt.

Kryteria oceny: co realnie decyduje, a co jest deklarowane, ale nieistotne

W briefach i zapytaniach ofertowych regularnie pojawiają się kryteria, które brzmią poważnie, ale w praktyce nie różnicują ofert, bo nikt nie umie ich rzetelnie ocenić. Do takich "fałszywych" kryteriów należą:

• deklarowana innowacyjność i kreatywność - trudna do zmierzenia, więc rzadko punktowana w praktyce;
• sam wiek firmy na rynku i jej wielkość - sprawdzane najczęściej jako próg formalny, nie jako przewaga konkurencyjna;
• nazwa "autorskiej metodyki" - sama nie ma znaczenia, bo liczy się to, czy klient rozumie kolejne kroki procesu;
• deklaracje dotyczące wykorzystania AI - coraz częstsze, ale rzadko weryfikowane w praktyce.

To, co decyduje o wyborze zwycięzcy, jest mniej formalne, ale bardziej wymierne: poczucie bezpieczeństwa osoby podejmującej decyzję (bo to ona później odpowiada za wynik przed swoją organizacją), dowód na to, że agencja zrozumiała biznes klienta zanim jeszcze zaproponowała rozwiązanie, jasny obraz współpracy krok po kroku oraz referencja z organizacji o podobnej skali i poziomie regulacji.

Prawo zamówień publicznych daje tu ciekawą wskazówkę, przydatną też poza sektorem publicznym. Art. 241 ust. 3 ustawy Pzp zakazuje punktowania renomy samej firmy, ale art. 242 ust. 2 pkt 5 pozwala punktować doświadczenie konkretnych osób wyznaczonych do realizacji zamówienia ^[2]. To twarda podstawa dla zasady "pytaj o zespół, nie o logo firmy". W praktyce niektórzy zamawiający idą w tę stronę bardzo daleko. Jeden z realnych postępowań opublikowanych na platformie TED przypisał aż 50% wagi oceny doświadczeniu trzech konkretnych osób wskazanych do zespołu projektowego, a pozostałe 50% wagi przypisał cenie ^[4]. To skrajny, ale pokazowy przykład tego, jak bardzo doświadczenie konkretnych ludzi może przeważyć nad marką agencji.

Jedno kryterium wymaga osobnego zdania, bo coraz częściej pojawia się w briefach, ale rzadko jest w praktyce weryfikowane: dostępność cyfrowa (WCAG). To nie jest formalny punkt do zaznaczenia w ofercie, tylko konkretna kompetencja. Zaprojektowanie procesu transakcyjnego zgodnego z WCAG 2.2 na poziomie AA wymaga innego procesu testowania UX i innej wiedzy niż standardowy projekt UI. Zapytaj agencję nie o to, czy "zna WCAG", ale o konkretny przykład projektu, w którym dostępność była realnym wymogiem, a nie deklaracją w ofercie.

Od czego zależy cena projektu UX

Cena projektu UX zależy od wielu czynników, a to właśnie ich splot, nie jeden parametr, tłumaczy, dlaczego dwie oferty na "ten sam" zakres mogą się różnić kilkukrotnie. W praktyce najważniejsze czynniki, w przybliżonej kolejności istotności, są następujące:

1. Liczba i złożoność unikalnych ekranów oraz ich stanów - nie samych podstron, ale wariantów: stanu pustego, załadowanego, błędu, walidacji, wersji mobilnej.
2. Skład i poziom doświadczenia zespołu - kto i przez jaką część projektu faktycznie pracuje.
3. Zakres badań UX i dostęp do użytkowników - liczba metod badawczych, grup docelowych, rynków.
4. Złożoność organizacyjna - liczba interesariuszy, warsztatów, iteracji i procesów akceptacyjnych po stronie klienta.
5. Zakres odpowiedzialności agencji - czy ogranicza się do rekomendacji, czy odpowiada za rozwiązanie od początku do końca.
6. Tempo realizacji - krótszy termin wymaga zwykle większego zespołu pracującego równolegle, co zwiększa koszt.
7. Dodatkowe wymagania - dostępność cyfrowa (WCAG), regulacje branżowe, bezpieczeństwo, wiele wersji językowych lub rynków.
8. Model rozliczenia - stała cena (fixed price) zawiera wbudowany bufor na ryzyko, którego nie ma w rozliczeniu godzinowym; to nie kwestia narzutu, a ceny za przewidywalność.
9. Zakres dokumentacji i sposób przekazania projektu do wdrożenia (handoff).
10. Warunki umowne - kary, poziom odpowiedzialności, wyłączność, terminy płatności.

Najczęstszy powód, dla którego dwie agencje wyceniają formalnie ten sam zakres nawet trzykrotnie inaczej, jest prosty. Wcale nie wyceniają tego samego, mimo że oferty mają podobne nagłówki. "Badania użytkowników" mogą oznaczać pięć wywiadów albo rozbudowany proces badawczy na kilku rynkach. "Projekt UX/UI" może oznaczać kilka kluczowych ścieżek użytkownika albo kompletny produkt ze wszystkimi stanami błędów i pełną dokumentacją. "Senior designer" w ofercie może pracować nad projektem przez cały jego czas trwania albo pojawiać się kilka godzin w tygodniu. Różnicę robi też to, ile ryzyka agencja bierze na siebie w cenie. Tańsza oferta bardzo często oznacza po prostu ryzyko przerzucone na klienta w formie późniejszych zmian zakresu, czyli change requestów.

Żeby porównywać oferty rzetelnie, sprowadź je najpierw do wspólnego mianownika, zamiast od razu patrzeć na ostatni wiersz w arkuszu kalkulacyjnym. Pomaga ujednolicenie zakresu przed wyceną, czyli jedna, wspólna lista ekranów i procesów wysłana wszystkim oferentom. Pomaga też wymaganie podziału ceny na etapy z osobnymi kwotami oraz prośba o rozbicie na role i liczbę roboczogodzin - nie po to, by negocjować stawkę, ale by zobaczyć, jakie założenia przyjęła dana agencja. Dobrze porównać też definicję słowa "gotowe" i zakres dokumentacji przekazywanej do wdrożenia. Bardzo dobrze działa zadanie wszystkim oferentom tego samego pytania kontrolnego, na przykład: "co zrobicie, jeśli po trzech tygodniach okaże się, że dane analityczne, na których mieliśmy się opierać, są niekompletne?". Odpowiedzi na takie pytanie rozjeżdżają się zwykle bardziej niż same ceny i mówią więcej o doświadczeniu agencji niż kolejny slajd portfolio. Jedna zasada zostaje w pamięci najlepiej: porównuj ryzyko, nie cenę. Najtańsza oferta bardzo często okazuje się najdroższa w trzecim miesiącu współpracy.

Czerwone flagi po stronie agencji i oferty

Po stronie agencji, na etapie rozmów i prezentacji, liczą się cztery sygnały. Pierwszy: agencja mówi "tak" na wszystko, bez nazywania jakiegokolwiek ryzyka. Dobra agencja od razu wskaże, co jest wykonalne, ale pod pewnymi warunkami. Drugi: agencja nie umie jasno powiedzieć, czego NIE dostarcza w ramach danej oferty. Kto nie zna granic własnego zakresu, będzie je negocjować już w trakcie projektu, kiedy zmiana jest najdroższa. Trzeci: agencja nie potrafi podać konkretnego przykładu sytuacji, w której musiała zarządzić ryzykiem albo nieplanowaną zmianą w trakcie projektu. To lepszy test niż pytanie o same kompetencje, bo pokazuje, jak zespół radzi sobie, gdy coś idzie nie tak, a nie tylko wtedy, gdy wszystko idzie zgodnie z planem. Czwarty: na spotkaniu jest tylko zespół sprzedażowy, a osoby, które realnie miałyby prowadzić projekt, w ogóle się nie pojawiają. To utrudnia ocenę, z kim tak naprawdę będzie się współpracować po podpisaniu umowy.

Po stronie samej oferty równie ważne są sygnały formalne. Brak limitu poprawek jest problemem, ale "nieograniczone poprawki" wcale nie są dobrą wiadomością. To odwrotna wersja tego samego problemu, bo prowadzi do nieskończonego procesu bez wyraźnego zakończenia. Harmonogram, w którym nie ma ani jednego zdania o tym, czego agencja wymaga od klienta, na przykład terminu dostarczenia materiałów, oznacza, że nikt nie policzył ryzyka poślizgu wynikającego z drugiej strony. Jedna kwota podana ryczałtem za cały projekt, bez podziału na etapy i płatności po akceptacjach, jest ryzykowna dla obu stron. Dobry podział na etapy chroni klienta, który nie płaci z góry za całość, i agencję, która nie kredytuje miesięcy pracy. Zwróć uwagę też na kilka innych sygnałów. Widoczny "kopiuj-wklej" w ofercie, gdy nazwa klienta pojawia się tylko w tytule dokumentu. Zbyt niska cena bez wyjaśnienia, skąd wynika różnica względem innych ofert. Prawa autorskie ujęte w jednym ogólnym zdaniu bez wyszczególnienia pól eksploatacji. Deliverables opisane samymi rzeczownikami, na przykład "UX", "UI", "dokumentacja". To nie jest zakres pracy, ale kategoria, pod którą można podłożyć bardzo różne rzeczy.

Pytania, które warto zadać agencji, a rzadko są zadawane

Kilka pytań, które w naszym doświadczeniu najlepiej odróżniają agencje przygotowane do złożonych projektów od tych, które dopiero się tego uczą:

• Jakie duże marki widzę w waszym portfolio - a co konkretnie dla nich zrobiliście? Poproście o opis zakresu, nie tylko nazwę klienta.
• Podajcie przykład sytuacji, w której musieliście zarządzić ryzykiem albo nieplanowaną zmianą w trakcie projektu. Co się wydarzyło i jak zareagowaliście?
• Ile rund poprawek jest w cenie i co dzieje się po ich wyczerpaniu?
• Jak wygląda proces akceptacji kolejnych etapów - kto go formalnie podpisuje po stronie klienta?
• Jak liczycie zmiany zakresu (change requesty) i po jakiej stawce?
• Jak wygląda u was proces komunikacji i raportowania w trakcie projektu?

Takie pytania mówią więcej o realnym doświadczeniu agencji niż kolejna prezentacja portfolio, bo zmuszają do konkretów, a nie ogólnych deklaracji.

Sukces projektu to połowa równania: rola klienta

Wybór dobrej agencji jest tylko jedną stroną równania. Dane z branży zarządzania projektami pokazują wprost, że druga połowa sukcesu zależy od samego klienta: od tego, jak dojrzała jest organizacja zamawiająca, jak sprawnie podejmuje decyzje i jak dobrze definiuje swoje potrzeby na starcie.

Najnowsza pełna edycja raportu CHAOS grupy Standish, "Beyond Infinity" z 2020 roku, klasyfikuje projekty software'owe według tak zwanej "współczesnej miary sukcesu" (Modern measurement): 31% projektów odniosło sukces, 50% zostało zakwalifikowanych jako zagrożone (ukończone, ale z przekroczeniem czasu, budżetu lub okrojonym zakresem), a 19% zakończyło się porażką ^[5]. Ciekawszy niż same liczby jest wniosek dotyczący przyczyn: raport pokazuje, że odsetek sukcesu jest silnie związany z dojrzałością trzech czynników po stronie organizacji zamawiającej: sponsora projektu, zespołu i otoczenia organizacyjnego. Przy wysokiej dojrzałości wszystkich trzech czynników odsetek sukcesu sięga od 50 do 67%, a przy niskiej dojrzałości spada do zakresu 1-23% ^[5]. Innymi słowy: nawet najlepsza agencja ma ograniczone możliwości skompensowania organizacji, która nie jest gotowa na sprawne podejmowanie decyzji.

Potwierdza to najnowsza, szesnasta edycja badania Pulse of the Profession Project Management Institute z 2026 roku, oparta na odpowiedziach ponad 2500 specjalistów z 35 krajów: 31% złożonych projektów nie osiąga pełnego zakresu pierwotnie zamierzonych korzyści biznesowych ^[6]. Raport wskazuje też konkretny mechanizm, który różnicuje organizacje - dopasowanie oczekiwań sponsora projektu na samym początku prac stosuje 40% zespołów o wysokiej skuteczności, wobec 30% zespołów o niskiej skuteczności ^[6]. Podobnie, korzystanie z ustrukturyzowanego frameworku zarządzania projektem przekłada się na wskaźnik sukcesu na poziomie 72%, wobec 61% bez takiego podejścia ^[6]. Dla porównania, wcześniejsza edycja tego samego badania z 2023 roku podaje, że średnio 5,2% zainwestowanych środków jest tracone z powodu słabych wyników projektów - i to nie jest problem dotykający wyłącznie agencje, ale każdą organizację realizującą projekty IT ^[7].

Praktyczny wniosek z tych danych jest taki, że dobra współpraca z agencją zaczyna się od uporządkowania własnej organizacji: jasnego wskazania osoby decyzyjnej, realistycznego harmonogramu akceptacji i przygotowania na to, że nie każdą decyzję da się podjąć raz.

Jak korzystać z rankingów i zestawień agencji UX

Rankingi i zestawienia agencji są użytecznym punktem wyjścia do researchu, o ile podejdzie się do nich z odpowiednią dozą krytycznego myślenia. Cztery rzeczy decydują, czy ranking rzeczywiście pomaga w podjęciu decyzji: czy metodologia oceny jest opisana i powtarzalna (widać, ile agencji zostało ocenionych, jakie kryteria zastosowano i jak przyznawano punkty, nie tylko subiektywną listę nazw), czy dane są aktualizowane (widoczna data ostatniej aktualizacji), czy ranking bierze pod uwagę zakres współpracy z klientami, nie tylko sam fakt, że dany klient był znany, oraz czy jasno widać, kto ranking publikuje. Ranking spełniający te cztery warunki jest znacznie bardziej wiarygodnym punktem wyjścia niż zestawienie bez podanej metodologii.

Podsumowanie

Wybór agencji UX/UI trudno sprowadzić do jednego kryterium. Każda próba takiego uproszczenia, czy to sama cena, samo portfolio, czy sama długość obecności na rynku, zwiększa ryzyko rozczarowania. Prawo, dane branżowe i praktyka pokazują tę samą rzecz z różnych stron: liczy się zespół, który realnie wykona pracę, jasność procesu i wyceny, oraz to, czy klient sam jest gotowy na sprawne podejmowanie decyzji. Najprostszy test na koniec rozmów z kandydatami brzmi tak: nie wybieraj agencji, która najlepiej opowiada o sobie. Wybierz tę, która po kilku rozmowach najlepiej potrafi opowiedzieć o twoim problemie.

Najczęściej zadawane pytania

Czym różni się agencja UX/UI od software house'u lub freelancera?

Agencja UX/UI koncentruje się na badaniach użytkowników, projektowaniu doświadczenia i interfejsu, często bez samodzielnego wdrażania kodu. Software house zwykle oferuje pełny cykl, od projektu do wdrożenia, z większym zespołem deweloperskim. Freelancer bywa dobrym wyborem do wąskich, dobrze zdefiniowanych zadań, ale rzadko dysponuje zapleczem do złożonych, wieloetapowych projektów enterprise, gdzie potrzeba równoległej pracy kilku specjalizacji i ciągłości zespołu.

Ile trwa audyt UX?

Czas realizacji audytu UX zależy od zakresu produktu i liczby analizowanych ścieżek użytkownika, ale typowy audyt trwa od kilku dni do kilku tygodni pracy zespołu. Zakres audytu (liczba stron, urządzeń, segmentów użytkowników) ma większy wpływ na czas trwania niż sama złożoność wizualna produktu.

Co to jest faza discovery i czy jest potrzebna?

Discovery to etap poprzedzający projektowanie, w którym zespół weryfikuje założenia biznesowe, potrzeby użytkowników i ograniczenia technologiczne, zanim powstaną pierwsze koncepcje. Nielsen Norman Group rekomenduje discovery wtedy, gdy w projekcie występuje wiele niewiadomych, ponieważ działanie wyłącznie na założeniach zwiększa ryzyko rozwiązania niewłaściwego problemu (opis fazy discovery). Jest szczególnie istotna, gdy zakres projektu nie jest jeszcze w pełni zdefiniowany - pominięcie tego etapu zwiększa ryzyko, że zespół zaprojektuje dobre rozwiązanie dla niewłaściwie zdefiniowanego problemu.

Czy agencja UX/UI robi też development?

To zależy od modelu działania konkretnej agencji. Część agencji ogranicza się do warstwy projektowej i przekazuje gotową dokumentację zespołowi deweloperskiemu klienta, część oferuje pełny cykl łącznie z wdrożeniem. Warto to ustalić na etapie briefu, bo wpływa na zakres wymaganej dokumentacji i model rozliczenia.

Co powinien obejmować handoff do własnego zespołu IT?

Dobry handoff obejmuje nie tylko finalne ekrany, ale też pełną specyfikację stanów (błędów, walidacji, wariantów), dokumentację interakcji i wytyczne dotyczące komponentów, tak by zespół deweloperski mógł zbudować produkt bez konieczności dopytywania o każdy szczegół.

Czym różni się model fixed price od time & material w projekcie UX?

Fixed price to stała cena za określony zakres, która zawiera wbudowany bufor na ryzyko: klient płaci nią za przewidywalność. Time & material to rozliczenie według faktycznie przepracowanych godzin, elastyczne przy zmieniającym się zakresie, ale wymagające większego zaufania i kontroli po stronie klienta.

Ile agencji warto zapytać o ofertę?

Z praktyki wynika, że sensowna liczba to od trzech do sześciu agencji. Mniejsza liczba ogranicza porównanie, większa znacząco wydłuża proces oceny bez proporcjonalnego wzrostu jakości decyzji, zwłaszcza jeśli oferty nie są od początku ujednolicone co do zakresu.

Przypisy

[1] Michael Bloch, Sven Blumberg, Jürgen Laartz, "Delivering large-scale IT projects on time, on budget, and on value", McKinsey & Company, październik 2012. mckinsey.com
[2] Ustawa z dnia 11 września 2019 r. Prawo zamówień publicznych, art. 241, 242, 243. api.sejm.gov.pl
[3] Sprawozdanie Prezesa Urzędu Zamówień Publicznych z funkcjonowania systemu zamówień publicznych w 2025 r., Urząd Zamówień Publicznych. gov.pl/web/uzp
[4] Ogłoszenie o zamówieniu, Wojewódzki Urząd Pracy w Białymstoku. ted.europa.eu
[5] Henny Portman, "Project Success Quick Reference Card", oparta na CHAOS 2020: Beyond Infinity, The Standish Group, styczeń 2021. hennyportman.wordpress.com
[6] Pulse of the Profession 2026: Driving Success in Complex Projects, Project Management Institute, 16. edycja, maj 2026. pmi.org
[7] Pulse of the Profession 2023: Power Skills, Redefining Project Success, Project Management Institute, 14. edycja. pmi.org