fbpx

Testy użyteczności: 3 rodzaje błędów UX

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ć, ale jeśli o mnie chodzi, tu też stawiam na ‚mniej a lepiej’. Czyli przykładam dużą wagę do wyboru osób pod względem różnicowania badanych osób. Czyli 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ą 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.

  1. Błąd krytyczny – uniemożliwia wykonanie akcji w celu zrealizowania zadania, podróż zostaje przerwana;
  2. Błąd istotny – utrudnia w znacznym stopniu wykonanie akcji, ale zadanie jest możliwe do wykonania;
  3. 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!

0 komentarzy
1 like
Poprzedni wpis: Dla kogo i po co robię Mastermind?

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

O mnie

Cześć, jestem Magda. Piszę o projektowaniu, estetycznych doświadczeniach, rozwoju osobistym i duchowym. Witaj na moim blogu. więcej o mnie

Najnowsze wpisy