Większość nieudanych produktów cyfrowych nie jest źle zbudowana. Jest źle wycelowana. Kod działa, interfejs jest czysty, launch wychodzi na czas — a prawie nikt tego nie używa. Problem zapadł na długo przed pierwszym sprintem: nikt nie potwierdził, że produkt rozwiązuje problem, który ludzie faktycznie mieli.
UX discovery to etap, który temu zapobiega. To uporządkowana praca polegająca na ustaleniu, czego naprawdę potrzebują Twoi użytkownicy, co Twój biznes realistycznie może dostarczyć i gdzie te dwie rzeczy się przecinają — zanim wydasz budżet na design i development.
Czym jest UX discovery?
UX discovery to faza researchu i definiowania na początku projektu produktowego. Jej celem jest zastąpienie założeń dowodami i zdefiniowanie właściwego problemu, zanim ktokolwiek zaproponuje rozwiązanie.
Faza discovery zwykle odpowiada na cztery pytania:
- Dla kogo tak naprawdę budujemy? Nie demograficzne domysły, tylko realne segmenty użytkowników z realnymi zachowaniami i ograniczeniami.
- Jaki problem rozwiązujemy? Sformułowany językiem użytkownika, nie językiem funkcji.
- Dlaczego nie rozwiązano go wcześniej? Co robi konkurencja, gdzie zawodzi i jaka luka pozostaje.
- Co zbudować najpierw? Uporządkowany kierunek, a nie lista życzeń.
Efektem nie jest design. To decyzja — poparta wystarczającą liczbą dowodów, by zespół mógł się jej trzymać bez asekuracji.
Dlaczego zespoły pomijają discovery i ile to kosztuje
Discovery jest cięte z powodów, które łatwo zrozumieć. Wygląda jak opóźnienie. Stakeholderzy chcą zobaczyć ekrany. Inwestorzy chcą zobaczyć postępy. Inżynieria chce backlog, od którego może zacząć. Research wydaje się luksusem, gdy runway jest krótki.
Koszt ujawnia się później i rzadko przypisuje się go do prawdziwej przyczyny.
Koszt zbudowania niewłaściwej rzeczy. Funkcja, której rozwój zajmuje trzy miesiące i nie zyskuje żadnej adopcji, to nie strata trzech miesięcy. To trzy miesiące inżynierii plus czas designu, plus koszt alternatywny wszystkiego innego, co mogło powstać, plus obciążenie utrzymaniem kodu, którego nikt nigdy nie usunie.
Koszt przeróbek. Zmiana kierunku podczas discovery kosztuje jedną rozmowę. Zmiana podczas designu kosztuje tydzień. Zmiana po launchu kosztuje całą roadmapę.
Koszt wewnętrznych sporów. Bez wspólnych dowodów decyzje produktowe podejmuje ten, kto najbardziej przekonująco argumentuje w pokoju. Zespoły co kwartał wracają do tych samych pytań, bo nigdy nic naprawdę nie zostało ustalone.
Discovery nie jest opóźnieniem budowy. Jest tym, co sprawia, że budowa ma sens.
Co dokładnie dzieje się podczas procesu UX discovery
Discovery jest często opisywane w sposób ogólnikowy, co po części tłumaczy, dlaczego bywa pomijane. Oto, z czego konkretnie składa się ta praca.
Wywiady ze stakeholderami
Zanim porozmawiasz z użytkownikami, rozmawiasz z osobami, które zleciły produkt. Founderzy, product ownerzy, sprzedaż, support, liderzy inżynierii. Celem jest ujawnienie, w co organizacja wierzy, że jest prawdą — i zauważenie, gdzie te przekonania sobie przeczą.
To bardziej odkrywcze, niż się wydaje. Nierzadko po pięciu wywiadach ze stakeholderami wyłania się pięć różnych definicji użytkownika docelowego. Ta niezgodność sama w sobie jest wynikiem badania, a jej rozwiązanie bywa najcenniejszym efektem całej fazy.
User research
Rdzeń discovery. W zależności od produktu i ograniczeń oznacza to:
- Pogłębione wywiady z obecnymi lub potencjalnymi użytkownikami, skupione na zachowaniu i kontekście, a nie opiniach o funkcjach.
- Contextual inquiry — obserwowanie ludzi wykonujących realne zadanie w realnym otoczeniu, co niezawodnie ujawnia obejścia i frustracje, o których nikt nie wspomina w wywiadzie.
- Ankiety, gdy trzeba zbadać skalę czegoś, co zostało już odkryte jakościowo.
- Przegląd analityki i zgłoszeń supportu dla istniejących produktów, gdzie dane behawioralne już istnieją i zwykle są niedoceniane.
Kluczowa dyscyplina to pytanie o to, co ludzie robią, a nie co deklarują, że by zrobili. Deklarowane preferencje są notorycznie słabym predyktorem rzeczywistego zachowania, a discovery oparte na nich prowadzi do pewnych siebie, ale błędnych wniosków.
Analiza konkurencji i rynku
To nie jest arkusz porównania funkcji. Użyteczna wersja pyta, dlaczego konkurenci podjęli takie, a nie inne decyzje, które z tych decyzji działają i gdzie istnieje realna luka, którą Twój produkt mógłby zająć.
Journey mapping
Mapowanie pełnej ścieżki użytkownika, w tym części, które dzieją się poza Twoim produktem. Journey mapping konsekwentnie ujawnia dwie rzeczy: punkty tarcia, których nikt nie jest właścicielem, bo wypadają między zespołami, oraz momenty wysokiej intencji, w których niewielka interwencja daje nieproporcjonalnie duży efekt.
Definiowanie problemu i priorytetyzacja
Etap syntezy — ten, który najbardziej odróżnia użyteczne discovery od kosztownego raportu badawczego. Ustalenia grupuje się w problem statements. Problem statements ocenia się pod kątem wpływu na użytkownika, wartości biznesowej i wykonalności. Powstaje obronna odpowiedź na pytanie „co zbudować najpierw i dlaczego”.
Co dostajesz na koniec fazy discovery
Faza discovery powinna kończyć się materiałami, na których zespół może działać, a nie slajdem, który trafia do archiwum.
- Zweryfikowany problem statement — konkretny problem, który rozwiązuje produkt, sformułowany językiem użytkowników.
- Segmenty użytkowników i persony oparte na researchu, a nie wymyślone.
- Journey map pokazująca obecny stan doświadczenia i miejsca, w których się załamuje.
- Uporządkowaną listę szans — problemy warte rozwiązania, ocenione, z uzasadnieniem.
- Rekomendowany kierunek dla produktu, w tym co jest jawnie poza zakresem.
- Otwarte pytania i ryzyka — co pozostaje niepewne i jak to tanio sprawdzić.
Ten ostatni punkt znaczy więcej, niż się wydaje. Discovery, które twierdzi, że jest w pełni pewne, to naciąganie. Discovery, które nazywa własne luki, to takie, któremu można zaufać.
Kiedy potrzebujesz UX discovery — a kiedy nie
Discovery nie zawsze jest właściwym pierwszym krokiem. Znajomość różnicy oszczędza wszystkim pieniądze.
Potrzebujesz discovery, gdy:
- Budujesz nowy produkt, a użytkownik docelowy jest zdefiniowany na podstawie założeń, nie dowodów.
- Twój istniejący produkt ma płaskie lub malejące zaangażowanie, a zespół nie może się zgodzić co do przyczyny.
- Wchodzisz na nowy rynek, segment lub w nowy region, gdzie dotychczasowa wiedza o użytkownikach może się nie przekładać.
- Właśnie zmieniłeś kierunek (pivot), a roadmapa jest odziedziczona po poprzedniej strategii.
- Stakeholderzy nie zgadzają się co do kierunku, a spór stał się cykliczny.
- Masz długi backlog funkcji i brak zasadnej metody jego priorytetyzacji.
Prawdopodobnie nie potrzebujesz pełnego discovery, gdy:
- Problem jest naprawdę dobrze zrozumiany, a niepewność dotyczy wykonania, nie kierunku — w takim przypadku lepiej sprawdzi się audyt UX lub usability testing.
- Wprowadzasz małą, ograniczoną zmianę w ustalonym flow.
- Działasz w kontekście regulacyjnym lub compliance, gdzie wymagania są narzucone z zewnątrz.
Uczciwe studio powie Ci, kiedy wystarczy lżejsza forma współpracy. Discovery jest kosztowne, gdy jest niepotrzebne.
Ile trwa UX discovery?
Dla większości produktów skoncentrowana faza discovery zajmuje od trzech do sześciu tygodni. Zakres zależy od trzech zmiennych:
- Dostęp do użytkowników. Jeśli uczestników można szybko zrekrutować, research idzie sprawnie. Jeśli Twoimi użytkownikami są administratorzy szpitali czy menedżerowie zakupów w dużych firmach, sama rekrutacja może zająć dwa tygodnie.
- Złożoność produktu. Aplikacja konsumencka o jednym celu to mniejszy obszar niż wieloroliowa platforma B2B.
- Wewnętrzne dopasowanie. Tam, gdzie stakeholderzy już w dużej mierze się zgadzają, synteza idzie szybko. Tam, gdzie nie, faza obejmuje dodatkową pracę nad wypracowaniem konsensusu.
Fazy discovery przeciągające się poza osiem tygodni zwykle cierpią na niejasny zakres, a nie na prawdziwą złożoność. Celem jest zredukowanie niepewności na tyle, by móc ruszyć — nie wyeliminowanie jej całkowicie, co jest niemożliwe.
UX discovery vs. audyt UX vs. user research
Te terminy bywają używane zamiennie, a to zamieszanie prowadzi do zakupu niewłaściwej usługi.
UX discovery patrzy w przyszłość. Pyta, co powinno istnieć. Stosuje się je, gdy kierunek jest niepewny, zwykle przed lub na wczesnym etapie budowy.
Audyt UX patrzy wstecz. Ocenia coś, co już istnieje, względem zasad użyteczności i heurystyk, i tworzy listę problemów do naprawienia. Stosuje się go, gdy produkt istnieje i słabo działa, a Ty musisz wiedzieć dlaczego.
User research to zestaw metod, nie faza. Wywiady, usability testing, ankiety i diary studies to wszystko user research. Discovery korzysta z metod badawczych; audyt też; podobnie bieżąca optymalizacja.
Praktyczne rozróżnienie: jeśli nie wiesz, co zbudować, potrzebujesz discovery. Jeśli wiesz, co zbudować, ale to nie działa, potrzebujesz audytu.
Najczęstsze błędy w UX discovery
Traktowanie go jako formalności. Discovery prowadzone, by uzasadnić decyzję już podjętą, to teatr. Jeśli wniosek jest z góry ustalony, pomiń research i zaoszczędź pieniądze.
Pytanie użytkowników, czego chcą. Użytkownicy są ekspertami od swoich problemów, nie od rozwiązań. Wywiady zadające pytanie „czy skorzystałbyś z funkcji, która…” niezmiennie dają entuzjastyczne „tak”, które nigdy nie przekładają się na zachowanie.
Rekrutowanie niewłaściwych osób. Pięć wywiadów z niewłaściwym segmentem jest gorsze niż brak wywiadów, bo prowadzi do pewnych siebie wniosków wskazujących niewłaściwy kierunek.
Zatrzymywanie się na ustaleniach. Lista obserwacji nie jest wynikiem discovery. Wartość leży w syntezie — przekształceniu tego, co zaobserwowano, w uporządkowaną, obronną rekomendację.
Nadmierny research. Po przekroczeniu pewnego punktu kolejne wywiady przestają dostarczać nowych informacji. Rozpoznanie nasycenia i przejście do syntezy to umiejętność; jego brak pochłania budżet.
Dostarczanie dokumentu, którego nikt nie czyta. 60-stronicowy raport to sposób na przeniesienie odpowiedzialności, nie na przekazanie insightu. Ustalenia powinny być prezentowane na roboczej sesji, na której zespół może je zakwestionować.
Jak prowadzimy UX discovery
Każde discovery, które prowadzimy, kieruje się tą samą zasadą: celem jest decyzja, nie dokument.
W praktyce oznacza to fazę discovery zbudowaną wokół trzech ruchów.
Zaczynamy od tego, co już wiesz. Większość organizacji siedzi na większej ilości dowodów, niż im się wydaje — zgłoszenia supportu, notatki z rozmów sprzedażowych, analityka, wywiady o odejściu klientów, wcześniejszy research. Zanim zlecimy nowe badania, przekopujemy to, co już istnieje. Jest to szybsze, tańsze i wyostrza pytania, na które warto wydać budżet badawczy.
Badamy zachowanie, nie opinię. Wywiady są zbudowane wokół tego, co ludzie zrobili, kiedy i co wydarzyło się dalej. Tam, gdzie to możliwe, obserwujemy zadanie, zamiast o nim rozmawiać.
Syntezujemy w otwarty sposób. Ustalenia przepracowujemy razem z Twoim zespołem, a nie prezentujemy im gotowe. Zespoły, które uczestniczą w syntezie, biorą odpowiedzialność za wnioski; zespoły, które dostają gotowy raport, zwykle zaczynają go podważać.
To podejście wynika z trzynastu lat pracy w UX w agencjach, startupach i zespołach korporacyjnych oraz z ponad pięćdziesięciu audytów i projektów discovery w sektorach takich jak insurtech, fintech, zdrowie, edukacja, enterprise i transport. Ma też podstawę w formalnym wykształceniu: certyfikacie Nielsen Norman Group — instytucji stojącej za współczesnym UX, jaki znamy — obejmującym information architecture, journey mapping, usability testing, przywództwo w UX i analitykę.
Każdy projekt prowadzę osobiście, od początku do końca. Nie ma warstwy account managementu między Tobą a osobą wykonującą pracę.
Najczęściej zadawane pytania
Jaka jest różnica między product discovery a UX discovery?
Znacząco się pokrywają i często są używane zamiennie. Product discovery zwykle podkreśla rentowność biznesową i szansę rynkową; UX discovery zwykle podkreśla potrzeby i zachowania użytkowników. W praktyce dobra faza discovery obejmuje oba te aspekty, bo rozwiązanie, które kochają użytkownicy, ale którego biznes nie jest w stanie utrzymać, nie jest rozwiązaniem.
Ile kosztuje UX discovery?
Koszt zależy od zakresu, liczby segmentów użytkowników i głębokości researchu. Skoncentrowana faza discovery dla jednego produktu i jednego głównego segmentu to inny budżet niż discovery obejmujące wiele ról i rynków. Uczciwy dostawca poda widełki dopiero po krótkiej rozmowie o zakresie, nie z góry.
Czy możemy przeprowadzić discovery sami?
Tak, i zespoły z doświadczeniem badawczym często powinny to robić. Dwie rzeczy, które wnosi zewnętrzny praktyk, to rygor metodologiczny — zwłaszcza w projektowaniu wywiadów i unikaniu pytań sugerujących — oraz niezależność. Zespoły wewnętrzne są, co zrozumiałe, zaangażowane emocjonalnie w istniejące plany. Osoba z zewnątrz nie ma w tym żadnego interesu.
Ilu użytkowników musimy przebadać?
W przypadku discovery jakościowego pięciu do ośmiu uczestników na wyraźny segment użytkowników zwykle wystarcza, by kolejne wywiady przestały ujawniać nowe wątki. Więcej segmentów oznacza więcej wywiadów; więcej uczestników w obrębie jednego segmentu szybko daje malejące zwroty.
Co, jeśli research pokaże, że nasz pomysł nie działa?
To najcenniejszy możliwy wynik i najtańsze miejsce, by go odkryć. Discovery, które przekierowuje produkt jeszcze przed budową, zwraca się z nawiązką.
Czy potrzebujemy discovery, jeśli już mamy użytkowników?
Często tak — ale zmienia się forma. Przy istniejącym produkcie discovery opiera się na danych behawioralnych, sygnałach z supportu i wywiadach z obecnymi użytkownikami, a pytanie zmienia się z „co powinniśmy zbudować” na „gdzie jest realna szansa, którą przeoczamy”.
Od czego zacząć
Jeśli nie masz pewności, czy Twój produkt potrzebuje discovery, przydatny test to pytanie: czy każdy w Twoim zespole niezależnie zapisałby, kim jest Twój główny użytkownik i jaki problem dla niego rozwiązujecie — i czy te odpowiedzi by się zgadzały?
Jeśli nie, ta luka kosztuje Cię więcej, niż kosztowałaby faza discovery.