W pracy nad produktem powtarza się pewien schemat. Zespół dyskutuje o decyzji przez tygodnie. Opinie się utwardzają. Staż w firmie zaczyna liczyć się bardziej niż argumenty. Wtedy ktoś stawia produkt przed pięcioma prawdziwymi użytkownikami i w ciągu godziny odpowiedź staje się oczywista, a nikt się już nie kłóci.
Spór nigdy nie dotyczył produktu. Dotyczył braku dowodów.
User research to sposób, żeby przestać się tak spierać.
Czym jest user research?
User research to systematyczne badanie tego, jak zachowują się ludzie, czego potrzebują i gdzie Twój produkt ich zawodzi. Zastępuje założenia obserwacją i dostarcza dowodów, na których można oprzeć decyzje, zamiast ich bronić.
Najważniejsze rozróżnienie: research bada zachowanie, nie opinię. To, co ludzie mówią, że zrobią, a to, co faktycznie robią, konsekwentnie i przewidywalnie się rozjeżdża. Research zbudowany wokół deklarowanych preferencji daje pewne siebie wnioski, które są błędne — i błędne w sposób, który wygląda na potwierdzony, co jest gorsze niż brak danych w ogóle.
Dwie szerokie kategorie, odpowiadające na różne pytania:
- Badania generatywne — prowadzone przed projektowaniem lub na jego wczesnym etapie, żeby zrozumieć potrzeby, kontekst i zachowanie. Odpowiadają na pytanie *co powinniśmy zbudować?*
- Badania ewaluacyjne — prowadzone na czymś, co już istnieje, żeby znaleźć, gdzie zawodzi. Odpowiadają na pytanie *czy to działa?*
Większość zespołów robi za mało badań pierwszego typu, a za dużo drugiego, a potem dziwi się, że optymalizuje coś, czego nikt nie chciał.
Dlaczego pięciu użytkowników zwykle wystarcza
Najbardziej uporczywy zarzut wobec testowania z użytkownikami dotyczy wielkości próby. To też zarzut najczęściej stosowany błędnie.
W przypadku jakościowego usability testing, od pięciu do ośmiu uczestników na segment użytkowników zwykle ujawnia zdecydowaną większość istotnych problemów. To dobrze udokumentowane ustalenie, a powód jest strukturalny: poważne problemy z użytecznością dotykają większości użytkowników, więc pojawiają się szybko. Dziesiąty uczestnik rzadko ujawnia problem, którego nie ujawnił piąty.
W przypadku badań ilościowych — mierzenia, jak często coś występuje, porównywania projektów statystycznie, szacowania wielkości rynku — pięć osób to zdecydowanie za mało. Takie pytania wymagają setek lub tysięcy odpowiedzi.
Mylenie tych dwóch podejść to najczęstszy błąd badawczy w obie strony. Zespoły albo odrzucają testy jakościowe jako niepoważne, albo wyciągają statystyczne wnioski z ośmiu wywiadów. Dopasowanie metody do pytania to większość tej umiejętności.
Metody badawcze i do czego służy każda z nich
Wywiady pogłębione. Zrozumienie kontekstu, motywacji i tego, jak zadanie wpisuje się w szerszą pracę lub życie danej osoby. Najlepsze do badań generatywnych, gdy trzeba zrozumieć obszar problemu, a nie ocenić rozwiązanie.
Contextual inquiry. Obserwowanie ludzi wykonujących realne zadanie w ich prawdziwym środowisku. Konsekwentnie ujawnia rzeczy, których wywiady całkowicie nie wychwytują — obejścia, przerwania i ograniczenia, o których ludzie nie wspominają, bo przestali je zauważać.
Usability testing. Uczestnicy próbują wykonać realne zadania, a Ty obserwujesz, gdzie się wahają, gdzie ponoszą porażkę albo idą nieoczekiwaną drogą. Najbardziej efektywna metoda znajdowania problemów w istniejącym produkcie lub prototypie.
Moderowane vs. niemoderowane. Sesje moderowane pozwalają zadawać pytania dodatkowe i wyłapywać nieoczekiwane wątki. Testy niemoderowane są tańsze i szybsze i sprawdzają się przy dobrze zdefiniowanych zadaniach, gdy już wiesz, co mierzysz.
Ankiety. Do ustalania częstotliwości — ilu ludzi doświadcza czegoś, co zidentyfikowałeś już jakościowo. Słabe do odkrywania nowych rzeczy, bo można pytać tylko o to, co już przyszło Ci do głowy.
Card sorting i tree testing. Specjalnie do information architecture. Card sorting pokazuje, jak użytkownicy grupują i nazywają treści; tree testing sprawdza, czy proponowana struktura pozwala ludziom znaleźć to, czego szukają.
Diary studies. Śledzenie zachowania przez dni lub tygodnie. Niezbędne, gdy doświadczenie rozgrywa się w czasie — onboarding, budowanie nawyku, powtarzalne zadania — i niewidoczne w pojedynczej sesji.
Analityka i dane behawioralne. To nie zastępuje researchu, ale to najtańszy dostępny wkład. Pokazuje, gdzie są problemy, na dużą skalę, i podpowiada, gdzie skierować metody jakościowe.
Nagrania sesji i heatmapy. Obserwacja behawioralna bez rekrutacji. Świetne do wyłapywania wzorców wartych zbadania; ograniczone, jeśli chodzi o zrozumienie, dlaczego one występują.
Element, który decyduje o wszystkim: rekrutacja
Jakość researchu jest ograniczona jakością uczestników. Osiem sesji z niewłaściwymi osobami daje pewne siebie wnioski wskazujące w złym kierunku — i nie da się wykryć tego błędu na podstawie samych wyników.
Selekcja liczy się bardziej niż liczba. Wąski screener z garstką odpowiednio dobranych uczestników bije luźny screener z dwudziestoma osobami. Rekrutuj pod kątem zachowania ("osoby, które w ostatnim miesiącu zarezerwowały podróż online"), a nie demografii.
Obecni i potencjalni użytkownicy odpowiadają na różne pytania. Obecni użytkownicy powiedzą Ci, gdzie Twój produkt zawodzi; nie powiedzą Ci, dlaczego inni się nie rejestrują. Użytkownicy, którzy odeszli, są często najbardziej wartościową grupą i najrzadziej kontaktowaną.
Uważaj na próby dogodne. Testowanie ze współpracownikami, znajomymi czy najbardziej zaangażowanymi power userami daje pochlebne, niereprezentatywne wyniki. Zaangażowani użytkownicy już przystosowali się do problemów Twojego produktu.
Segmentuj osobno. Jeśli masz odrębne typy użytkowników, każdy potrzebuje własnych uczestników. Pięć sesji rozłożonych na trzy segmenty to nie jest badanie trzech segmentów.
Jak wygląda dobre testowanie
Zadania, nie wycieczki. Poproś uczestników o osiągnięcie czegoś realnego. Nie oprowadzaj ich po interfejsie — to testuje Twoje wyjaśnienia, nie produkt.
Cisza. Najtrudniejsza dyscyplina w moderacji. Gdy ktoś się waha, odruchem jest pomóc. Powstrzymanie się przed tym to właśnie miejsce, w którym rodzi się wniosek.
Pytaj co, nie czy. "Co próbujesz zrobić?" daje informację. "Czy to było mylące?" daje uprzejmość. Uczestnicy chcą być pomocni, a pytania sugerujące odpowiedź to sposób, w jaki research zostaje skażony.
Obserwuj zachowanie bardziej niż komentarz. To, co ktoś robi, waży więcej niż to, co mówi o tym, co zrobił. Tam, gdzie te dwie rzeczy się nie zgadzają, ufaj zachowaniu.
Uwzględnij ścieżki porażek. Błędy, puste stany i przypadki brzegowe to miejsca, w których produkty tracą ludzi, a rutynowo są pomijane w scenariuszach testów, bo trudniej je zaplanować.
Nagrywaj i przeglądaj. Obserwacja na żywo coś pomija. Nagrania pozwalają weryfikować wnioski, a nie polegać na pamięci — i pozwalają stakeholderom obejrzeć materiał, co zmienia zdanie znacznie szybciej niż raport.
Od wniosków do decyzji
Research, który niczego nie zmienia, to kosztowna rozrywka. Etap syntezy to miejsce, w którym wartość powstaje albo się traci.
Grupuj według wzorca, nie sesji. Wniosek zaobserwowany raz to anegdota. Zaobserwowany w czterech z sześciu sesji to wzorzec, na którym warto działać.
Oddziel obserwację od interpretacji. "Trzech uczestników przewinęło sekcję z cenami" to obserwacja. "Użytkownikom nie zależy na cenie" to interpretacja i być może błędna. Utrzymywanie ich rozdziału pozwala innym sprawdzić Twoje rozumowanie.
Ustalaj priorytety według dotkliwości i częstotliwości. Jak bardzo dotyka to użytkownika i ilu użytkowników na to trafia? Razem te dwa wymiary ustalają kolejność wniosków; każdy z osobna wprowadza w błąd.
Rekomenduj, nie tylko raportuj. Lista problemów przenosi pracę, a nie ją zmniejsza. Każdy istotny wniosek powinien nieść ze sobą proponowany kierunek.
Pozwól stakeholderom patrzeć. Dwie minuty prawdziwego użytkownika ponoszącego porażkę w zadaniu przesuwają organizację dalej niż dwadzieścia stron wniosków. Tam, gdzie to możliwe, jest to najbardziej dźwigniowa rzecz, jaką może zrobić research.
Przechowuj to tak, żeby dało się znaleźć. Większość organizacji bada te same pytania wielokrotnie, bo nic nie zostało zachowane. Przeszukiwalne repozytorium zamienia pojedyncze badania w kumulującą się wiedzę.
Częste błędy
Pytanie użytkowników, czego chcą. Ludzie są ekspertami od swoich problemów i niepewnymi projektantami rozwiązań. "Czy skorzystałbyś z funkcji, która…" niezawodnie wywołuje entuzjastyczną zgodę, która nigdy nie zmienia się w zachowanie.
Pytania sugerujące odpowiedź. "Czy to było łatwe?" dostaje odpowiedź "tak". Sformułowanie pytania decyduje o odpowiedzi bardziej, niż większość zespołów sobie uświadamia.
Testowanie zbyt późno. Research po ukończeniu budowy daje wnioski, na które nikogo nie stać, żeby zareagować. Testowanie prototypu kosztuje ułamek tej kwoty i przychodzi, gdy zmiana jest jeszcze możliwa.
Badanie po to, żeby potwierdzić. Badania zlecone, żeby uzasadnić już podjętą decyzję, to teatr. Jeśli wniosek jest z góry ustalony, odpuść research i zachowaj budżet.
Nadmierne badanie. Po osiągnięciu punktu nasycenia dodatkowe sesje przestają dostarczać nowych informacji. Rozpoznanie tego momentu i przejście do syntezy to umiejętność; przegapienie go pali budżet.
Traktowanie wniosków jak nakazów. Użytkownicy dokładnie zgłaszają objawy i słabo przepisują rozwiązania. To, z czym mieli problem, to dane. To, co sugerują zbudować, zwykle nie.
Jednorazowe badania. Izolowany research odpowiada na jedno pytanie. Research jako nawyk się kumuluje — a drugie badanie zawsze kosztuje mniej niż pierwsze, bo infrastruktura już istnieje.
Jak podchodzimy do researchu
Projektujemy badanie wokół decyzji. Pierwsze pytanie zawsze brzmi: co zrobisz inaczej w zależności od wyniku. Jeśli żadna odpowiedź niczego nie zmienia, badanie nie jest warte przeprowadzenia — i powiedzenie tego wprost jest częścią naszej pracy.
Badamy zachowanie, nie opinię. Sesje budujemy wokół realnych zadań w realistycznych warunkach. Tam, gdzie pytamy, pytamy o to, co się wydarzyło, nie o to, co ktoś sobie wyobraża, że by zrobił.
Jesteśmy rygorystyczni w rekrutacji. Selekcja to miejsce, w którym badania się udają albo upadają, i jest to etap najczęściej robiony na szybko. Dobór złych uczestników unieważnia wszystko, co potem, niewidocznie.
Oddzielamy obserwację od interpretacji. Wnioski raportujemy tak, żebyś mógł zobaczyć dowody i ocenić rozumowanie, zamiast przyjmować konkluzje na zasadzie autorytetu.
Zapraszamy Twój zespół do udziału. Obserwowanie użytkownika zmagającego się z zadaniem zmienia zdanie w sposób, w jaki nie robi tego czytanie o tym. Tam, gdzie stakeholderzy mogą obserwować, powinni.
Jesteśmy szczerzy co do tego, co dana metoda może potwierdzić. Osiem sesji nie daje statystyk. Tam, gdzie potrzebujesz liczb, powiemy to wprost i zaprojektujemy badanie odpowiednio, zamiast ubierać wnioski jakościowe w język ilościowy.
Podejście opiera się na certyfikacji Nielsen Norman Group — instytucji, która ukształtowała współczesną praktykę UX — w zakresie usability testing, journey mapping, information architecture, UX leadership i analityki, oraz na trzynastu latach doświadczenia w agencjach, startupach i zespołach korporacyjnych w insurtech, fintech, zdrowiu, edukacji, enterprise i transporcie.
Każde zlecenie prowadzę osobiście. Bez warstwy account managera pomiędzy Tobą a osobą wykonującą pracę.
Najczęściej zadawane pytania
Z iloma użytkownikami trzeba testować?
W przypadku jakościowego usability testing, od pięciu do ośmiu osób na odrębny segment ujawnia większość istotnych problemów. W przypadku pytań ilościowych — mierzenia częstotliwości, porównywania projektów statystycznie — potrzebujesz setek osób. Liczba zależy wyłącznie od typu pytania, a mylenie tych dwóch podejść to najczęstszy błąd w obie strony.
Jaka jest różnica między user research a usability testing?
Usability testing to jedna metoda badawcza, skupiona na tym, czy ludzie potrafią czegoś użyć. User research to szersza dziedzina, obejmująca wywiady, contextual inquiry, ankiety, diary studies i więcej. Testowanie ocenia rozwiązanie; research w szerszym sensie może też badać problem.
Czy możemy testować, zanim cokolwiek zbudujemy?
Tak, i zwykle to najlepszy moment. Można testować prototypy, wireframe'y, a nawet szkice na papierze. Im wcześniej test, tym tańsza zmiana — i tym większa szansa, że wnioski faktycznie zostaną wdrożone.
Czy zajmujecie się rekrutacją?
Tak. Rekrutacja i selekcja to miejsce, w którym badania odnoszą sukces albo ponoszą porażkę, więc nie jest to etap, który warto lekkomyślnie delegować. Tam, gdzie masz dostęp do własnych użytkowników, bywa to szybsze i lepsze — screener zaprojektujemy tak czy inaczej.
Ile trwa badanie?
Skoncentrowany usability test — planowanie, rekrutacja, sesje, synteza — zwykle trwa dwa do trzech tygodni. Research generatywny z wieloma segmentami trwa dłużej, zazwyczaj cztery do sześciu tygodni. Rekrutacja to najczęstsze wąskie gardło, zwłaszcza w przypadku wyspecjalizowanych grup odbiorców.
Co jeśli research zaprzecza temu, w co wierzymy?
To najcenniejszy możliwy wynik i najtańsze miejsce, żeby się o tym dowiedzieć. Research, który zawsze tylko potwierdza istniejące założenia, albo nie był potrzebny, albo nie został dobrze zaprojektowany.
Czy możemy prowadzić research samodzielnie?
Tak, i zespoły z odpowiednimi kompetencjami często powinny — to szybsze i buduje wewnętrzną wiedzę. To, co dodają zewnętrzni praktycy, to projekt badania, dyscyplina moderacji i niezależność. Jeśli chcesz zbudować kompetencję, a nie kupić badanie, to też może być forma współpracy.
Czy sama analityka nie wystarczy?
Analityka pokazuje, co się wydarzyło i jak często, na dużą skalę. Nie powie Ci dlaczego, ani nic o ludziach, którzy nigdy nie dotarli. Połączenie obu jest znacznie silniejsze niż każde z osobna: analityka lokalizuje problem, research jakościowy go wyjaśnia.
Od czego zacząć
Pytanie diagnostyczne: jakie jest najbardziej znaczące założenie, na którym obecnie opiera się Twój produkt, i skąd wiesz, że jest prawdziwe?
Jeśli odpowiedź zawiera słowo "oczywiście", to właśnie tam trzeba zacząć.