Jak nadmierna rezygnacja z UX research niszczy ROI projektów IT
W ciągu ostatnich dwóch lat przeprowadziłem audyty dla 17 średnich i dużych projektów IT, które po wdrożeniu nie przyniosły oczekiwanego zwrotu inwestycji. W 15 przypadkach problem był ten sam: brak lub symboliczne badania użytkowników na etapie projektowania. To nie jest przypadek – to systemowy błąd, który kosztuje firmy miliony złotych rocznie.
Dlaczego UX research przegrywa z deadline’ami
W polskich firmach technologicznych panuje przekonanie, że badania użytkowników to luksus, na który mogą sobie pozwolić tylko korporacje z nieograniczonymi budżetami. W rzeczywistości jest odwrotnie – to właśnie mniejsze firmy najbardziej potrzebują tej wiedzy, bo nie mają zapasów gotówki na poprawki po wdrożeniu.
Ostatnio konsultowałem projekt platformy B2B dla branży logistycznej. Zespół developerski miał 4 miesiące na wdrożenie. Product owner zdecydował, że „nie ma czasu na badania”, bo „zna branżę”. Efekt? Po 6 miesiącach od wdrożenia tylko 23% docelowych klientów korzystało z platformy. Główne powody? Interfejs wymagał 7 kliknięć tam, gdzie konkurencja potrzebowała 3, a kluczowe funkcje były ukryte w menu, którego nikt nie używał.
Trzy ukryte koszty braku researchu
1. Koszt poprawki vs. koszt zapobieżenia
W przypadku wspomnianej platformy logistycznej, przeprojektowanie interfejsu po wdrożeniu kosztowało 120 000 zł i kolejne 3 miesiące pracy. Proste testy A/B z 5 użytkownikami na etapie projektowania kosztowałyby maksymalnie 5 000 zł i 2 tygodnie. To różnica 24:1 w kosztach.
W mojej praktyce widzę to regularnie: firmy wydają 80-90% budżetu na rozwój funkcji, które potem trzeba przerabiać, bo nie odpowiadają realnym potrzebom użytkowników.
2. Koszt utraconej szansy
Klient z branży e-commerce chciał wdrożyć zaawansowany system rekomendacji produktów. Bez badań zaimplementowano algorytm oparty na historii zakupów. Po wdrożeniu okazało się, że 68% użytkowników w tej niszy kupuje prezenty dla innych osób, więc ich historia zakupów nie ma związku z ich preferencjami.
Przez 8 miesięcy system generował nieadekwatne rekomendacje, co przełożyło się na spadek konwersji o 15%. Gdyby na początku przeprowadzono nawet podstawowe wywiady z 10 klientami, ten problem zostałby wychwycony na etapie koncepcji.
3. Koszt utraty zaufania
Najdroższy koszt to ten, którego nie widać w excelu. Kiedy użytkownicy trafiają na aplikację, która nie spełnia ich potrzeb, tracą zaufanie do marki. W przypadku platformy SaaS dla małych firm, po negatywnych pierwszych doświadczeniach, tylko 12% użytkowników wracało do produktu po miesiącu.
Odbudowanie tego zaufania kosztuje 5-10 razy więcej niż pozyskanie nowego klienta. I zajmuje miesiące, a często lata.
Jak robić research, który nie spowalnia projektu
Minimum Viable Research
Nie potrzebujesz wielomiesięcznych badań etnograficznych. W większości przypadków wystarczy:
- 5-7 wywiadów pogłębionych z docelowymi użytkownikami
- Testy użyteczności prototypu z 5 osobami
- Analiza danych z analogicznych rozwiązań (jeśli istnieją)
Dla projektu o budżecie 200 000 zł, research powinien kosztować 5-10% tej kwoty i zająć 2-3 tygodnie. To nie jest „blokowanie projektu” – to inwestycja, która zwraca się średnio 8-krotnie.
Research jako proces, nie jako etap
W JurskiTech.pl wprowadziliśmy model ciągłego researchu: zamiast jednego, dużego badania na początku, robimy krótkie, regularne sesje co 2-3 tygodnie. To pozwala nam:
- Testować założenia na bieżąco
- Wychwytywać zmieniające się potrzeby użytkowników
- Unikać wielomiesięcznych projektów opartych na nieaktualnych danych
Metody, które działają w realnych warunkach
- Remote usability testing – testy przez Zoom/Teams, nagrywanie sesji, analiza później. Koszt: 300-500 zł za uczestnika.
- Card sorting – online, narzędzia jak OptimalSort. Pomaga zrozumieć mentalne modele użytkowników.
- Analiza konkurencji – nie chodzi o kopiowanie, ale o zrozumienie, jakie problemy rozwiązują inni i jak użytkownicy na to reagują.
Case study: platforma do zarządzania flotą samochodową
Klient potrzebował systemu dla 200 użytkowników w firmie transportowej. Na początku projektu przeprowadziliśmy:
- 8 wywiadów z kierowcami, dyspozytorami i managerami
- 2 dni obserwacji pracy w biurze i w trasie
- Testy papierowego prototypu z 6 osobami
Co odkryliśmy? 85% kierowców nie używało dotychczasowego systemu, bo wymagał logowania przez przeglądarkę na telefonie, a oni woleli aplikację. Dyspozytorzy potrzebowali widzieć nie tylko lokalizację, ale też stan paliwa i przewidywany czas dotarcia – danych, których stary system nie pokazywał.
Efekt? Nowa platforma po wdrożeniu miała 94% adoption rate w pierwszym miesiącu. Koszt researchu: 15 000 zł. Oszczędność na niepotrzebnych funkcjach i przeróbkach: szacunkowo 80 000 zł.
Kiedy research NIE jest potrzebny?
Są sytuacje, gdzie pełny research może być przesadą:
- Aktualizacja bezpieczeństwa bez zmian w interfejsie
- Drobną poprawka UX w istniejącym, sprawdzonym produkcie
- Projekty wewnętrzne dla małej, znanej grupy użytkowników
Ale nawet wtedy warto zrobić przynajmniej szybki test z 2-3 osobami. Bo to, co dla nas jest „oczywistą poprawką”, dla użytkownika może być zupełnie nieintuicyjne.
Podsumowanie: research jako ubezpieczenie projektu
Traktuj badania użytkowników nie jako koszt, ale jako ubezpieczenie swojego projektu. Nikt nie kwestionuje potrzeby ubezpieczenia samochodu – research to ubezpieczenie Twojej inwestycji w IT.
W ciągu najbliższych 2-3 lat różnica między firmami, które inwestują w zrozumienie użytkowników, a tymi, które działają „na wyczucie”, będzie się tylko powiększać. AI i automatyzacja mogą pomóc w wielu obszarach, ale nie zastąpią rozmowy z żywym człowiekiem o jego potrzebach i problemach.
Jeśli zaczynasz projekt i myślisz „nie mamy czasu na research” – zatrzymaj się na chwilę. Zapytaj siebie: czy stać nas na to, żeby wydać setki tysięcy złotych na coś, czego nikt nie będzie używał? Odpowiedź zwykle jest dość oczywista.
