Jedna z osób zapytała mnie ostatnio w jaki sposób notuję błędy podczas testowania. Tak się składa, że od kilku dni przeprowadzam testy użyteczności na jednej z platform, nad którą obecnie pracuję, więc dzielę się tematem na gorąco. Przyznaję, że nie przepadam ostatnio za pisaniem na tematy projektowo-egzekucyjne. Po pierwsze dużo informacji można znaleźć w sieci a po drugie uważam, że są ważniejsze tematy, o których warto teraz pisać.
Testy użyteczności
Testy są ważne i warto je robić. Przykładam dość dużą wagę do wyboru osób pod względem różnicowania badanych osób. Po to, żeby otrzymać najbardziej optymalny wynik. Najpierw robię założenia do rekrutacji badanych i różnicuję mocno w ramach wybranej grupy docelowej pod względem wieku, płci, predyspozycji, zawodu, stylu życia. Zapraszam do testów nie więcej niż 4-6 osób. Optymalizuje w ten sposób koszty, czas a wyniki są zazwyczaj wystarczające.
Obserwacja zachowań użytkowników pozwala na sprawdzenie, które miejsca utrudniają wykonanie akcji, na której nam zależy a które są zmienne w zależności od gustu czy preferencji. Rekomenduję sprawdzenie rozwiązania przez 3-4 osoby w podejściu iteracyjnym. Błędy dzielę na 3 rodzaje.
3 rodzaje błędów: krytyczne, istotne i drobne.
- Błąd krytyczny – uniemożliwia wykonanie akcji w celu zrealizowania zadania, podróż zostaje przerwana;
- Błąd istotny – utrudnia w znacznym stopniu wykonanie akcji, ale zadanie jest możliwe do wykonania;
- Błąd drobny – przeszkadza w płynnym flow i wpływa na przyjemność podróżowania i/lub opóźnia wykonanie zadania.
Na podstawie analizy, wniosków i obserwacji przygotowujemy rekomendację zmian. Błędy krytyczne wymagają natychmiastowej poprawy, bo zatrzymują proces podróży użytkownika. Wszystkie rodzaje błędów mają wpływ na flow i ogólną ocenę, ale to błędy krytyczne uniemożliwiają sprawdzenie kolejnych błędów istotnych i drobnych w dalszej wędrówce. Dlatego testowanie powinno odbywać się iteracyjnie, (czyli poprawiam, sprawdzam, poprawiam etc.), ponieważ jedną serią testów nie jesteśmy w stanie zlokalizować i wyeliminować wszystkich błędów.
W jaki sposób opisuję błędy?
Poniższe przykłady są tylko wycinkiem raportu po testach użyteczności. Chcę Ci pokazać, w jaki sposób opisuję błędy, których może być od kilku do kilkudziesięciu. Ilość i jakość błędów zależy od złożoności projektu. Im bardziej skomplikowany system tym więcej błędów. Tworząc nowy system, na początku może pojawić się sporo błędów krytycznych, z kolejnymi testami jest ich coraz mniej. Najwięcej spotykam błędów istotnych. Błędy drobne występują w prawie każdym rozwiązaniu i według mnie ich występowanie nie powinno blokować uruchomienie MVP (minimum viable product). Jednocześnie uważam, że o powodzeniu projektu często decydują detale i warto o nie dbać. O jakości, detalach i wyróżnieniu się na tle konkurencji piszę tutaj.
Przykłady opisu błędów krytycznych (wycinek z analizy):
- użytkownik długo szuka możliwości rejestracji. Klika na wszystkie CTA “dowiedz się więcej”, nie widzi możliwości rejestracji w górnym ekranie (potrzebna pomoc moderatora) – błąd krytyczny;
- bezskuteczne próby logowania – żaden z użytkowników nie aktywuje konta za pomocą maila (potrzebna pomoc moderatora) – błąd krytyczny;
Przykłady opisu błędów istotnych (wycinek z analizy):
- użytkownik nie wie, jaką cenę należy wpisać, brak komunikatów naprowadzających, wydłużony czas oczekiwania na decyzję – błąd istotny;
- po wypełnieniu danych rejestracyjnych następuje przekierowanie na stronę główną w celu zalogowania, ale bez okna logowania – błąd istotny;
Przykłady opisu błędów drobnych (wycinek z analizy):
- przy wyborze daty i rodzaju zajęć, kolorowy pasek (wykres) na górze ekranu zachęca do kliknięcia, po czym nic się nie dzieje – błąd drobny;
- jeden z użytkowników wskazuje na niewidoczne okna do wypełnienia (wskazuje na zbyt cienkie linie) – błąd drobny;
Powyższe opisy błędów nie wskazują powodów zdarzenia. Warto rozróżnić same obserwacje od wniosków i rekomendacji. Takie podejście oddziela stawianie hipotez przez moderatora / obserwatora i pozwala na analizę np. pozostałym członkom zespołu.
Nagrywaj ekran i głos
Najlepiej zapisywać testy użyteczności w formie video i audio, bo każda wskazówka jest cenną informacją do analizy i rekomendacji rozwiązań (zawsze proszę o komentarz podczas klikania, zastanawianie się na głos, czas działania, reakcja, patrzę na postawę ciała i wyraz twarzy).
Dobrze, gdy raport jest dokumentem zrozumiałym i pomocnym również dla osób, które nie brały udziału w testach (np. biznes /inwestorzy /projektanci) i do którego można się odwołać lub przypomnieć zdarzenie po jakimś czasie.
Testując rozwiązanie i pracując nad raportem z badań, rekomenduję taką kolejność:
1. Cel badania (jakie zadanie ma wykonać użytkownik);
2. Błędy i obserwacje z podziałem na etapu realizacji celu;
3. Wnioski i rekomendacje.
Testujesz? Masz pytania? Skorzystaj z bezpłatnej grupowej burzy mózgów i mojego wsparcia w każdą środę 11.00 – 13.00.
A jeśli chcesz rozwijać swoje umiejętności UX, zapraszam na Mastermind’UX, który rusza na przełomie wrzesień / październik 2020. Edycja tylko dla Kobiet.
Program trwa, zapraszam na kolejne edycje w 2021!