Klienci zaczynają wypełniać formularz, ale nie wysyłają zapytania. Nadal trzeba ustalić, dlaczego tak się dzieje. Może widzą niezrozumiały komunikat o błędzie. Może formularz wymaga danych, których jeszcze nie mają. A może dopiero w tym miejscu dowiadują się o warunku oferty, który zniechęca ich do kontaktu.
Każda z tych sytuacji wymaga innej poprawki. Powiększenie przycisku niewiele pomoże, jeśli klient nie rozumie ceny albo nie znajduje potrzebnych informacji.
Audyt UX służy właśnie rozpoznaniu takich przeszkód. UX, czyli doświadczenie użytkownika, dotyczy tego, jak korzysta się ze strony, sklepu lub systemu. W praktyce chodzi o bardzo konkretne rzeczy: znalezienie usługi, rezerwację terminu, złożenie zamówienia albo zatwierdzenie dokumentu w panelu.
Co właściwie sprawdza osoba prowadząca audyt?
Praca zaczyna się od poznania produktu i jego odbiorców. Audytor ustala, jakie zadania są ważne, przechodzi przez uzgodnione ścieżki i sprawdza, gdzie interfejs może utrudniać działanie. Analizuje między innymi nazwy, kolejność informacji, formularze, komunikaty i zachowanie elementów.
Dużo można się dowiedzieć także z rozmów i zgłoszeń. Zgłoszenie do obsługi może wyjaśnić, dlaczego ktoś nie rozumie statusu zamówienia. Rozmowa z pracownikiem może ujawnić, że pozornie prosta czynność wymaga otwarcia drugiego programu i ręcznego przepisania danych.
W audycie eksperckim część oceny opiera się na wiedzy o projektowaniu. Dlatego raport powinien wskazywać, które problemy udało się odtworzyć, na które wskazują zgłoszenia lub dane analityczne, a które są na razie przypuszczeniem.
Pod nazwą „audyt UX” mogą kryć się różne usługi. Zapytaj, czy audyt obejmuje analizę danych, badania z użytkownikami, wersję mobilną i sprawdzenie wybranych aspektów dostępności. Pełny audyt dostępności czy kontrola bezpieczeństwa to osobne zadania, które trzeba uzgodnić z wykonawcą.
Cały produkt czy jedna ścieżka?
Jeśli wiesz, na którym etapie pojawia się problem, audyt można ograniczyć do tego fragmentu. W sklepie może to być przejście od koszyka do potwierdzenia zamówienia. W aplikacji dla pracowników — utworzenie i zatwierdzenie wniosku. Na stronie usługowej — znalezienie właściwej oferty i wysłanie zapytania.
Analiza powinna uwzględniać też to, co użytkownik robi wcześniej i później. Przy audycie koszyka trzeba wiedzieć, jakie informacje klient dostał wcześniej o dostawie i dostępności produktu. Przy formularzu zapytania znaczenie ma opis usługi, który do niego prowadzi. Problem potrafi zacząć się na wcześniejszej podstronie, choć skutki widać dopiero później.
Szerszy przegląd przydaje się, gdy trudności powtarzają się w różnych miejscach, produkt zmieniał się przez lata albo firma planuje większą przebudowę. Pomaga znaleźć wspólną przyczynę problemów, na przykład niespójne nazwy lub odmienny sposób wykonywania podobnych czynności.
Zanim zlecisz audyt, zapisz pytanie, na które chcesz uzyskać odpowiedź. „Chcemy sprawdzić UX” jest bardzo ogólne. Konkretniej brzmi: „Chcemy ustalić, co utrudnia samodzielną zmianę terminu rezerwacji”. Taki cel ułatwia wybór ekranów do analizy, potrzebnych danych i osób, z którymi warto porozmawiać.
Co przygotować przed audytem?
Osoba analizująca produkt powinna znać jego ograniczenia. Dane ze zbędnego na pozór pola mogą być potrzebne na dalszym etapie obsługi. Z kolei czynność uznawana przez zespół za konieczną może być przyzwyczajeniem z czasów, gdy firma pracowała inaczej.
Przed audytem przygotuj:
- listę najważniejszych zadań i opis osób, które je wykonują;
- przykłady trudności ze zgłoszeń, rozmów lub obserwacji pracowników;
- dostępne dane o przebiegu analizowanego procesu;
- informacje o regułach biznesowych oraz powiązanych systemach;
- konto testowe z uprawnieniami potrzebnymi do przejścia całej ścieżki.
Do testów przygotuj przykładowe dane i środowisko, w którym można bezpiecznie popełnić błąd, anulować operację lub wrócić do poprzedniego kroku. Szczególnie przy zamówieniach i płatnościach trzeba ustalić, jak odróżnić takie działania od rzeczywistej obsługi.
Brak analityki nie zamyka drogi do audytu. Ogranicza jednak możliwość określenia, jak często występuje dany problem. Od razu ustal, czego nie da się ocenić bez danych. Jeśli wpływa to na decyzję o zmianach, zaplanuj zbieranie brakujących informacji.
Jeden formularz może ujawnić kilka różnych trudności
Weźmy hipotetyczny serwis umożliwiający rezerwację wizyty. Użytkownik wybiera usługę i godzinę, wpisuje dane, a następnie potwierdza termin. Audytor wykonuje te same kroki. Sprawdza też, co się stanie, gdy użytkownik się pomyli lub pominie potrzebną informację.
Najpierw przygląda się wyborowi usługi. Jeśli nazwy są skrótami znanymi tylko pracownikom, odbiorca może nie wiedzieć, którą pozycję zaznaczyć. Dalej sprawdza kalendarz: czy widać dostępne terminy i czy po przejściu do innego miesiąca nadal wiadomo, który termin jest zaznaczony.
Próbuje wpisać numer telefonu ze spacjami, pomija opcjonalne pole i poprawia adres e-mail. Sprawdza, czy formularz akceptuje różne poprawne sposoby zapisu danych, zrozumiale wskazuje błędy i zachowuje wcześniej wpisane informacje.
Na końcu sprawdza potwierdzenie. Użytkownik powinien móc ustalić, jaki termin wybrał i czy rezerwacja została przyjęta. Jeśli nie dostanie jasnego potwierdzenia, może spróbować ponownie lub zadzwonić do obsługi.
W ten sposób audytor sprawdza treść formularza, jego działanie oraz komunikaty dla użytkownika. Wskazówki W3C podkreślają, że komunikaty o błędach powinny być zrozumiałe i wyjaśniać, co trzeba poprawić w formularzu. Użytkownik powinien też otrzymać potwierdzenie pomyślnego wykonania zadania. Szczegóły znajdziesz w poradniku dotyczącym powiadomień w formularzach.
Jak odróżnić znaleziony problem od przypuszczenia?
Przy każdym wniosku powinno być jasne, skąd się wziął. Stwierdzenie „po błędnym wpisaniu kodu pocztowego formularz usuwa pozostałe dane” można sprawdzić, powtarzając wskazane kroki. Zdanie „użytkownicy rezygnują, bo formularz jest za długi” zawiera już wyjaśnienie ich zachowania. Żeby je potwierdzić, trzeba zebrać dodatkowe dowody.
Podobnie jest z danymi o ruchu. Jeśli wiele osób opuszcza serwis na jednej konkretnej podstronie, warto się jej przyjrzeć. Jednak osoba, która znalazła numer telefonu lub godziny otwarcia, mogła zakończyć zadanie właśnie w tym miejscu. Przy ocenie tych danych trzeba wiedzieć, po co ktoś wszedł na stronę.
Zwróć uwagę, jak uzasadniono zalecenia. Czy problem wystąpił podczas przeglądu? Czy powraca w zgłoszeniach? Czy został zaobserwowany u uczestników badania? Czy jest przewidywanym ryzykiem wynikającym z konstrukcji interfejsu?
Przypuszczenia pomagają zdecydować, co zbadać dalej. W raporcie trzeba je jednak wyraźnie oznaczyć, szczególnie gdy proponowana zmiana wiąże się z dużym kosztem.
Tak może wyglądać jedna uwaga w raporcie
Ogólne zalecenie „uprościć formularz” pozostawia zespołowi wiele pytań. Żeby przygotować poprawkę, trzeba wiedzieć, co dzieje się w konkretnym miejscu i jaki ma być efekt zmiany.
Poniższy zapis jest hipotetycznym przykładem uwagi do opisanego formularza rezerwacji:
- Miejsce: ekran danych kontaktowych, po zatwierdzeniu formularza z błędnym adresem e-mail.
- Obserwacja: komunikat informuje o błędzie, ale formularz usuwa też poprawnie wpisane imię i numer telefonu.
- Podstawa: błąd udało się odtworzyć podczas testu. Nie wiadomo jeszcze, jak często spotykają się z nim użytkownicy.
- Skutek: osoba poprawiająca jedną informację musi ponownie wpisać pozostałe dane.
- Zalecenie: zachować poprawnie wpisane dane, wskazać błędny adres e-mail i podpowiedzieć, co w nim poprawić.
- Sprawdzenie po wdrożeniu: ponownie wysłać formularz z błędnym adresem i sprawdzić, czy po poprawieniu tylko tego pola można dokończyć rezerwację.
Do takiej uwagi można dołączyć zrzut ekranu oraz opis urządzenia i przeglądarki. Dzięki temu zespół wie, jak odtworzyć błąd i czego ma dotyczyć poprawka. Może oszacować pracę i uzgodnić szczegóły rozwiązania.
Które poprawki wdrożyć najpierw?
Waga problemu zależy od tego, komu i w czym przeszkadza. Błąd, który blokuje płatność, jest pilniejszy niż nierówne odstępy między elementami. Utrata wpisanych danych jest bardziej dotkliwa w długim wniosku niż w pojedynczym polu wyszukiwarki.
Sprawdź, czy odbiorca może wykonać zadanie w inny sposób, ile to wymaga wysiłku i czym grozi pomyłka. Uwzględnij też osoby, które z powodu błędu lub niewygodnej obsługi w ogóle nie docierają do kolejnych etapów. Jeśli ktoś nie może wybrać terminu za pomocą klawiatury, statystyka potwierdzonych rezerwacji nie pokaże wprost tej trudności.
Osobno oszacuj koszt poprawki. To ułatwia ułożenie planu, ale nie zmienia znaczenia samego problemu. Kilka prostych zmian można wdrożyć szybko, jednocześnie pracując nad poważniejszym problemem.
Jeśli audyt wykazał wiele podobnych błędów, sprawdź, czy mają wspólną przyczynę. Formularz używany w kilku miejscach może wymagać jednej poprawki, która usunie problem na wszystkich tych ekranach. Warto to uzgodnić z osobą znającą techniczną budowę produktu.
Kiedy potrzebne jest badanie z użytkownikami?
Badanie przydaje się, gdy trzeba sprawdzić, jak odbiorcy rozumieją informacje, dokonują wyboru albo radzą sobie z proponowanym rozwiązaniem. Można zaprosić osoby należące do grupy docelowej i obserwować wykonywanie określonych zadań na obecnej stronie lub prototypie.
Zadanie powinno opisywać cel, pozostawiając uczestnikowi samodzielny wybór drogi. Przykładowo: „Chcesz przenieść wizytę na inny dzień. Sprawdź, jak możesz to zrobić”. Metodę i sposób przygotowania sesji opisuje poradnik testów użyteczności Government Digital Service.
To osobny etap, który można połączyć z audytem. Przed wprowadzeniem zmian pomoże sprawdzić ważne hipotezy. Test prototypu może z kolei ujawnić problemy, które da się usunąć jeszcze przed programowaniem. Dobierz badanie do pytań, na które audyt nie dał odpowiedzi.
Jak przejść od raportu do wdrożenia?
Zarezerwuj czas na omówienie wyników z osobami odpowiedzialnymi za produkt, projekt i technologię. Przy każdej ważnej uwadze ustalcie, czy macie dość informacji do działania. Część zaleceń będzie gotowa do realizacji, inne będą wymagały projektu lub dodatkowego sprawdzenia.
Przy każdym zadaniu ustalcie, kto je wykona i po czym poznacie, że zostało zrobione poprawnie. Ogólne hasło „formularz poprawiony” niewiele mówi. Warunek „po błędzie adresu e-mail pozostałe dane zostają w polach, a użytkownik może dokończyć rezerwację” można sprawdzić, wykonując opisane kroki.
Po wdrożeniu powtórzcie opisane zadania i, jeśli są dostępne, przejrzyjcie dane o korzystaniu z produktu oraz zgłoszenia do obsługi. Przy porównywaniu wyników uwzględnijcie zmiany w ruchu, ofercie i innych częściach produktu. Sam wzrost liczby rezerwacji nie dowodzi jeszcze, że wynika on z tej jednej poprawki.
Na koniec spotkania ustalcie, które zadania możecie już przekazać do realizacji, a czego musicie się jeszcze dowiedzieć. Wtedy łatwiej zaplanować kolejne prace, budżet i sposób sprawdzenia efektów.
