Jak nagrania sesji mogą skłonić zespół do rozwiązania niewłaściwego problemu

Aby zrozumieć, dlaczego użytkownicy nie wykonują kluczowego działania na stronie, zespoły często analizują nagrania sesji. Pozwalają one zobaczyć, jak konkretna osoba korzystała ze strony: gdzie kliknęła, co przewijała, na którym etapie się zatrzymała i kiedy opuściła witrynę.

Takie nagrania dobrze pokazują, co się wydarzyło. Problem zaczyna się wtedy, gdy zespół próbuje na podstawie tych samych działań od razu ustalić, dlaczego do tego doszło.

Załóżmy, że strona generuje ruch, ale niewielu użytkowników wysyła formularz kontaktowy. Nagrania sesji pokazują powtarzający się scenariusz. Użytkownik zaczyna wypełniać formularz, dociera do pola z numerem telefonu i opuszcza stronę.

Powód wydaje się oczywisty. Użytkownik nie chce rozmawiać z przedstawicielem firmy.

Zespół rozważa kilka rozwiązań. Można sprawić, aby numer telefonu nie był obowiązkowy, skrócić formularz albo zaproponować kontakt przez komunikator. Każda z tych zmian może poprawić wynik. Samo nagranie nie potwierdza jednak, że użytkownik zrezygnował właśnie z powodu perspektywy rozmowy telefonicznej.

Pole mogło nie działać poprawnie na konkretnym urządzeniu. Użytkownik mógł też nie rozumieć, w jakim formacie należy wpisać numer. W innych przypadkach problem pojawia się dopiero w związku z tym, co ma wydarzyć się po wysłaniu formularza. Użytkownik nie wie, kto się z nim skontaktuje ani jak będzie wyglądał kolejny krok.

W dokumentacji Microsoft dotyczącej formularzy pole z numerem telefonu może wymagać określonego formatu, a nieprawidłowe dane mogą prowadzić do błędu walidacji. Dlatego problem widoczny na nagraniu nie musi wynikać z niechęci do podania numeru. Przyczyną może być również samo działanie pola.

Źródło:
Microsoft Learn — Zarządzanie formularzami Customer Insights – Journeys

Zespół widzi moment rezygnacji i otrzymuje kilka możliwych wyjaśnień. Błąd pojawia się wtedy, gdy jedno z nich zostaje uznane za ustaloną przyczynę i od razu zamienia się w zadanie dla projektanta, programisty albo marketera.

Łatwo w to uwierzyć właśnie dlatego, że nagranie wydaje się znacznie bardziej konkretne niż tradycyjna analityka.

Dlaczego nagranie łatwo uznać za wyjaśnienie

Lejek pokazuje etap, na którym tracimy użytkowników. Nagranie sesji pozwala prześledzić pojedynczą wizytę niemal krok po kroku. Widzimy przewijanie strony, kliknięcia, przechodzenie między ekranami i interakcje z formularzami.

Taki poziom szczegółowości tworzy wrażenie, że zachowanie użytkownika zostało już wyjaśnione.

XTB opisuje wykorzystanie narzędzi do analityki behawioralnej, takich jak Hotjar, Google Analytics czy UXCam, do śledzenia ścieżek użytkowników, punktów opuszczenia, map ciepła i nagrań sesji. Takie dane pomagają zobaczyć, gdzie użytkownicy zatrzymują się, wracają lub rezygnują. Sama sekwencja działań nadal nie wyjaśnia jednak automatycznie ich motywacji.

Źródło:
XTB — Być jak nasi klienci: badania User Experience w XTB

Wyobraźmy sobie, że użytkownik kilka razy przełącza się między planami cenowymi, wraca do poprzedniej opcji, ponownie czyta opisy, a następnie zamyka stronę.

Zespół łączy rezygnację z ceną. Naturalnym pomysłem wydaje się wprowadzenie rabatu, specjalnej oferty albo dokładniejsze uzasadnienie kosztu.

Możliwe jest jednak inne wyjaśnienie. Być może plany są po prostu trudne do porównania. Jeden pakiet opisano przez funkcje, drugi przez korzyści, a trzeci przez ograniczenia. Użytkownik musi zapamiętać kilka długich opisów, aby znaleźć między nimi różnice.

Opuszcza stronę, zanim zdąży właściwie ocenić cenę. Rabat obniży koszt, ale sam proces wyboru nadal pozostanie równie trudny.

Nagranie pozwala na obie interpretacje. Samo narzędzie nie określa, która z nich jest trafniejsza.

Dodatkowa weryfikacja nie zawsze jest jednak potrzebna. Czasami problem jest bezpośrednio widoczny w interfejsie.

Kiedy nagranie daje wystarczające podstawy do zmiany

Nie każda obserwacja wymaga osobnego badania z użytkownikami.

Do pierwszej kategorii należą również niektóre mniej oczywiste problemy interfejsu. Użytkownicy mogą na przykład regularnie brać dany element za przycisk, nie zauważać ważnej akcji albo kilka razy wracać do tego samego elementu nawigacji.

Jeśli taki wzorzec się powtarza, zespół może sprawdzić, czy wynika z konstrukcji interfejsu, i uzasadnić lokalną zmianę bez prowadzenia pełnego badania motywacji użytkowników.

Gdy jednak możliwe wyjaśnienia dotyczą oczekiwań, zaufania albo postrzeganej wartości, samo obserwowane działanie nie wystarcza. Możemy zobaczyć, że użytkownik nie wysłał formularza, ale nie wiemy z pełnym przekonaniem, czy obawiał się telefonu, nie rozumiał kolejnego kroku, nie widział wystarczającej wartości w ofercie czy po prostu postanowił wrócić później.

Podobnie opuszczenie strony z cennikiem nie dowodzi, że cena była zbyt wysoka, a powrót do pierwszego ekranu nie oznacza automatycznie, że nagłówek był słaby.

Nagrania sesji pomagają znajdować wyraźne bariery w interfejsie oraz miejsca wymagające dalszej diagnozy. To, czy potrzebny jest kolejny etap badania, zależy od tego, czy powtarzające się zachowanie można powiązać z konkretną przeszkodą bez zgadywania, co użytkownik miał na myśli.

Ryzyko pojawia się wtedy, gdy zespół nie rozróżnia tych dwóch sytuacji i od razu zamienia interpretację w zadanie.

Jak wiarygodna wersja zamienia się w niepotrzebne koszty

Zespoły rzadko mają czas, aby szczegółowo badać każdy spadek wyników. Biznes potrzebuje planu, specjaliści potrzebują konkretnego zadania, a projekt musi posuwać się dalej.

Zdanie „formularz jest zbyt długi” natychmiast podpowiada rozwiązanie. Można usunąć część pól, zmienić ich kolejność albo je połączyć.

Przyznanie, że przyczyna nie jest jeszcze pewna, komplikuje kolejny krok. Trzeba sprawdzić stronę techniczną, obejrzeć inne nagrania, przeanalizować pytania klientów i rozważyć kilka możliwych powodów.

Na interpretację wpływają również problemy, o których firma już wcześniej dyskutowała. Jeśli zespół ma wątpliwości co do jakości ruchu, krótkie sesje zaczynają wyglądać jak dowód na niedopasowanych odbiorców. Jeśli zarząd martwi się cenami, wyjścia ze strony z cennikiem zaczynają potwierdzać przekonanie, że oferta jest zbyt droga. Jeśli redesign został już zaplanowany, trudności użytkowników mogą stać się kolejnym argumentem za przebudową całego interfejsu.

W tym miejscu przydaje się rozróżnienie danych ilościowych i jakościowych. Dane ilościowe pomagają określić skalę, częstotliwość i zakres zjawiska, natomiast dane jakościowe pozwalają lepiej zrozumieć przyczyny i problemy użytkowników. Dlatego sposób weryfikacji powinien zależeć od konkretnej hipotezy, a pojedyncza obserwacja nie zawsze wystarcza do wyciągnięcia wniosku.

Źródło:
The Story — Badania ilościowe w UX

Wybrane wyjaśnienie określa dalszą pracę. Wątpliwości dotyczące jakości ruchu kierują uwagę marketingu na kampanie reklamowe. Hipoteza dotycząca ceny prowadzi do zmian w ofercie. Podejrzenie problemu z formularzem trafia do projektantów i programistów.

Każda z tych decyzji wygląda racjonalnie, ponieważ odpowiada postawionej diagnozie.

Zespół przygotowuje projekt, wdraża zmiany i czeka na rezultat. Wyniki prawie się nie zmieniają, więc pojawia się kolejne wyjaśnienie. Do skróconego formularza dodawany jest pop-up, uruchamiana jest inna kampania reklamowa albo wprowadzany rabat.

Pierwotna bariera może przez cały ten czas pozostać nietknięta.

Szczególnie kosztowne są duże zmiany. Pełny redesign może sprawić, że strona będzie wyglądać nowocześniej, a jednocześnie zachowa ten sam problem w konkretnym scenariuszu użytkownika. Nowa wersja może być bardziej przejrzysta i dopracowana, ale użytkownicy nadal zatrzymują się dokładnie w tym samym miejscu.

Przed rozpoczęciem pracy warto więc sprawdzić zarówno problematyczny fragment ścieżki, jak i logikę, na podstawie której zespół przypisał mu określoną przyczynę.

Jak sprawdzić hipotezę przed wdrożeniem

Najlepiej zacząć od możliwie precyzyjnego opisu obserwowanego zachowania.

Dalszą weryfikację można podzielić na cztery etapy.

Część hipotez można sprawdzić technicznie albo za pomocą dodatkowych danych. Gdy jednak pytanie dotyczy oczekiwań lub motywacji użytkownika, sama obserwacja interfejsu może nie wystarczyć.

Kiedy przydaje się test z użytkownikami

Nagranie sesji pokazuje działania użytkownika bez jego komentarza. Podczas testu użyteczności uczestnik otrzymuje realistyczne zadanie i może na bieżąco opisywać swoje myśli oraz oczekiwania.

Można go na przykład poprosić o wybranie odpowiedniego planu i wysłanie prośby o konsultację.

Moderator nie prowadzi użytkownika przez interfejs. Obserwuje, w których miejscach uczestnik się waha, które elementy uważa za interaktywne, jakich informacji szuka i czego oczekuje po kliknięciu przycisku.

W ten sposób można odkryć przyczyny, których nie da się wiarygodnie odtworzyć na podstawie samych ruchów kursora. Jeden uczestnik może zakładać, że formularz od razu poprosi o dane karty. Inny może nie widzieć różnicy między planami. Jeszcze ktoś może odłożyć kontakt, ponieważ nie wie, kto i kiedy do niego zadzwoni.

Metoda głośnego myślenia polega na werbalizacji procesu myślenia podczas wykonywania zadania. Komentarze uczestnika, połączone z obserwacją jego działań, pomagają zrozumieć, jak postrzega interfejs, czego mu brakuje i na jakie bariery natrafia.

Źródło:
UsabilityLAB — Słownik pojęć Usability/UX

Kilka testów nie daje statystycznie pełnego obrazu całej grupy odbiorców. Pomagają natomiast odkryć bariery i możliwe wyjaśnienia, których zespół wcześniej nie brał pod uwagę.

W praktyce wnioski zwykle powstają na podstawie połączenia nagrań sesji, danych z lejka, kontroli technicznej i sygnałów pochodzących bezpośrednio od użytkowników.

Jeśli użytkownicy regularnie zatrzymują się w tym samym miejscu, a pozornie logiczne zmiany nie poprawiają wyniku, warto wstrzymać kolejne wdrożenie do czasu sprawdzenia pierwotnej hipotezy. Zmniejsza to ryzyko wydawania zasobów na rozwiązanie, które brzmi przekonująco wewnątrz zespołu, ale nie poprawia doświadczenia użytkownika.

Co zrobić po sprawdzeniu hipotezy

Sprawdzenie hipotezy pomaga określić rzeczywisty zakres zadania, zanim zespół zacznie przeznaczać zasoby na wdrożenie.

Czasami problem dotyczy pojedynczego pola, stanu przycisku, nazwy sekcji albo innego lokalnego elementu. W takiej sytuacji nie ma potrzeby przebudowywać całej ścieżki użytkownika.

W innych przypadkach kilka trudności jest ze sobą powiązanych. Użytkownik może mieć problem ze znalezieniem właściwej informacji, porównaniem opcji albo zrozumieniem kolejnego kroku. Wtedy lokalne poprawki mogą nie wystarczyć i potrzebna będzie większa przebudowa interfejsu.

Po sprawdzeniu hipotezy łatwiej określić właściwy zakres zmian. Może to być lokalna poprawka interfejsu, przebudowa konkretnej ścieżki użytkownika albo pełny redesign strony.

Jeśli rozwiązanie problemu wymaga projektowania i programowania, zespół El Pixel może wdrożyć zmiany w odpowiedniej skali. Pracujemy zarówno nad pojedynczymi elementami i ścieżkami użytkowników, jak i nad kompleksową przebudową produktu.

Zobacz także:
Dlaczego koszt redesignu strony jest różny i jak zrozumieć, za co płacisz →