Błędy w testowaniu użyteczności serwisów

Nikogo, kto zajmuje się zagadnieniem tworzenia i rozwoju serwisów internetowych nie trzeba przekonywać o zaletach testowania użyteczności witryn internetowych. Testowanie użyteczności umożliwia wykrywanie potencjalnych problemów, związanych z użytkowaniem danego serwisu jeszcze na stadium projektowania systemu i jego wdrażania.

Testowanie użyteczności jak udowadnia Krug i Nielsen niekoniecznie musi być operacją kosztowaną i wymagającą olbrzymiej wiedzy. Jednocześnie jednak nawet kosztowne i przeprowadzone na wielką skalę testowanie użyteczności nie gwarantuje dobrych i wiernie oddających rzeczywistość rezultatów. W poniższym zestawieniu postaram się przedstawić najczęstsze błędy, które występują przy testowaniu użyteczności serwisów internetowych.

Najczęstsze błędy towarzyszące testowaniu użyteczności

Brak wprowadzenia w kwestie planowanego i przeprowadzanego testowania użyteczności całego zespołu, zaangażowanego w prace przy rozwoju witryny.

• Nierzadko ze względu na kwestie przesadnej i źle pojmowanej ochrony danych i informacji o projekcie lub też rywalizację pomiędzy poszczególnymi działami firmy (np. Działu Marketingu i Działu IT) informacje, związane z testowaniem użyteczności są przekazywane członkom zespołu w bardzo ograniczonym zakresie. Wnioski z badania przekazywane są menedżerom, którzy nie do końca wiedzą co z nimi zrobić i przekazują te w takim zakresie, w jakim je sami zrozumieli.
• Szum informacyjny może się w tym przypadku mieszać z brakiem koordynacji współpracy pomiędzy osobami „technicznymi” i „marketingowymi”. W efekcie do wdrożenia i poprawy trafia tylko część problemów znalezionych przy okazji testowania użyteczności lub też trafiają rzeczy, które mają poważny wpływ na funkcjonalność projektu (np. bez odpowiedniej konsultacji z odpowiednimi osobami z IT „poprawiono” błąd wykryty w czasie testowania użyteczności, który w wysokim stopniu obniżył funkcjonalność projektu z punktu widzenia SEO).
• Brak zaangażowania całego zespołu w prace przy testowaniu użyteczności, zapoznania wszystkich z założeniami, nagraniami, wynikami testowania użyteczności ma szczególnie opłakane konsekwencje w sytuacji odejścia z firmy kluczowej osoby, w której gromadziła się cała wiedza ( lub duża jej cześć), związana z prowadzonymi pracami testowania.

Testowanie witryny w zbyt późnym stadium rozwoju witryny.

• Ważne jest aby testowanie witryny rozpocząć w jak najwcześniejszym etapie rozwoju witryny internetowej. Zbyt często testowanie witryny przeprowadzane jest na krótko przed samym oddaniem strony internetowej do użytku (np. przeprowadza się wówczas testowanie, które ma na celu sprawdzenie, czy menu powinno mieć kolor szary czy zielony, testowanie zaś wykazuje, że bez względu na kolorystykę menu i tak będzie mało intuicyjne dla użytkowników).
• Im we wcześniejszym etapie przeprowadzi się testowanie użyteczności, tym mniejsze koszty będzie generowało wdrożenie zmian, które będą wynikały z tego testowania.

Niewłaściwe zadania postawione przed testami użyteczności.

• Testowanie użyteczności nie pozwala na zdobycie całej wiedzy, połączonej z prowadzonym projektem.
• Testowanie pozwala tylko na sprawdzenie zachowania użytkowników w czasie użytkowania serwisu i potencjalne problemy, które będą związane z potencjalnym użytkowaniem serwisu.
• Często osoby, które zlecają testowanie użyteczności chcą poznać uczucia, które wzbudza w użytkownikach oprawa graficzna serwisu, poszczególne jej elementy. Zbyt wiele uwagi poświęca się wówczas subiektywnym odczuciom i słowom użytkownika (użytkownikowi może się podobać serwis, chociaż ze względu na problemy użyteczności nie był w stanie skorzystać z funkcjonalności oferowanych przez serwis; z drugiej strony inny użytkownik szybko wykonał zadanie w serwisie a jednocześnie nie polubił serwisu, ponieważ nie lubił koloru zielonego, który występował w serwisie).
• Im węższe i bardziej sprecyzowane zadania postawi się przed planowanym testowaniem użyteczności, tym lepsze rezultaty ono przyniesie (zamiast idei „Testowanie użyteczności serwisu www.mojastrona.pl lepsze będzie „Czy strona www.mojastrona.pl jest zaprojektowana na tyle dobrze i przystępnie dla użytkownika, że zdoła zmniejszyć liczbę maili wysyłanych do Centrum Obsługi Klienta?”).

Niewłaściwe wybieranie użytkowników testów użyteczności.

• Jak już wcześniej opisywałem w poście Testowanie użyteczności – 5 użytkowników wystarcza wcale nie powinniśmy tracić cennego czasu i energii na znalezienie testerów, którzy będą ściśle pasowali do określonego schematu demograficznego lub psychologicznego. Zamiast tego warto skupić się na takiej segmentacji kandydatów do testowania, która będzie odpowiadała określonym problemom związanym z obsługą strony internetowej (np. w przypadku szkoły zamiast sztywnego podziału na „studenci” i „ profesorowie” podział na „osoby szukające głownie informacji o zajęciach”, „osoby używające strony do znajdywania informacji o bieżących wydarzeniach w szkole – imprezach, odczytach”, „osoby, wykorzystujące stronę do umieszczania materiałów naukowych z swoich wykładów i zajęć” i itp.).
• Przy wyborze kandydatów do testowania strony musimy zadbać o to, aby wybrane osoby reprezentowały określony stopień zaawansowania internetowego (osoby, które wiedzą za dużo o stronie zbyt szybko sobie poradzą z zadaniami’; z drugiej zaś osoby pozbawione doświadczenia w użytkowaniu Internetu nie poradzą sobie nawet z łatwymi zadaniami, które nie sprawiały by trudności „przeciętnemu” użytkownikowi Internetu)

Niewłaściwy scenariusz testowania i niewłaściwe zadania postawione testowanym użytkownikom.

• Zadania stawiane użytkownikom powinny odzwierciedlać problemy potencjalnych użytkowników serwisu, tzn. powinny uwzględniać niewiedzę potencjalnych użytkowników na temat działania serwisu, jego specyficznych schematów nawigacyjnych, wyszukiwawczych i itp.
• Zadania stawiane użytkownikom nie mogą być zbyt ogólne i jednocześnie nie mogą być zbyt zawężone (nie ma sensu zlecenie użytkownikowi znalezienie w internetowej księgarni książki „Potop” – bardzo rzadko szukając czegoś w księgarni wiemy dokładnie, co chcemy znaleźć; częściej szukamy :książki o cenie poniżej 80zł, ładnie oprawionej, z gatunku powieści przygodowe).

Niewłaściwe przeprowadzanie testu użyteczności

• Błędem jest „prowadzenie użytkownika za rączkę” w czasie testu. Trzeba mieć na uwadze, że potencjalny użytkownik naszego serwisu nie będzie miał w czasie korzystania z serwisu nikogo, kto będzie mu podpowiadał który przycisk kliknąć, czy też co znaczy „submit” po angielsku.
• Sztuką jest takie przeprowadzenie testu, aby jednocześnie nie był on nudny dla użytkowników a jednocześnie nie zamienił się w „luźną pogawędkę” na temat serwisu. Odprężanie osoby testowanej lekką i swobodną rozmową z nie może przesłonić głównego celu testowania – zdobycia możliwie najwięcej rzeczowych informacji na temat problemów związanych z użytkowaniem serwisu.
• Lepiej jest przeprowadzić 3 testy z 5 użytkownikami każdy niż jeden test z 15 użytkownikami. Częstsze przeprowadzanie mniejszych testów użyteczności daje lepsze rezultaty niż rzadkie testowanie przeprowadzane na wielką skalę.

Zbędna biurokracja i niewłaściwa analiza wyników testowania

• W wielu sytuacjach etapem końcowym testowania użyteczności jest stworzenie obszernego raportu na temat całego procesu testowania i jego wyników, którego później nikt nie czyta. Dużo ważniejsze jest zapewnienie płynnej i szybkiej komunikacji pomiędzy uczestnikami zespołu niż archiwizowanie tej komunikacji (oczywiście jest to też bardzo ważne, ale nie można z tym przesadzać); im szybciej te sprawy zostaną omówione i zanalizowane tym mniejsze niebezpieczeństwo wynikające z powstawania „szumu informacyjnego”.
• W procesie zbierania i analizy wyników testów trzeba unikać zbędnej biurokracji i „szczeblowania” prezentacji wyników . Może się wręcz zdarzyć, że osoba A tworzy prezentację z wyników testowania dla swojego przełożonego B, ten na podstawie otrzymanych informacji tworzy z tego prezentację dla swojego przełożonego C, który z kolei ostatecznie to wszystko prezentuje przełożonemu D ( tak stworzona drabina uniemożliwia efektywne wprowadzanie zmian w serwisie – każdy będzie do swojej prezentacji dodawał „coś od siebie”, w efekcie czego to co przedstawiła osoba A będzie się diametralnie różniła od tego, co otrzymała osoba D).

Zbyt ścisła lub zbyt luźna interpretacja wyników testowania

• Nierzadko w efekcie wykrycia problemów użyteczności następują próby zamydlania wyników testowania użyteczności i znajdowania „wytłumaczenia” dla konkretnych problemów użytkowników (występuje to zwłaszcza wtedy, kiedy decyzje o testowaniu witryny podjęto za późno a same wyniki testowania postawiły pod znakiem zapytania sensowność wdrażania całego serwisu (wówczas osoby, które go stworzyły musiały by się przyznać do błędu, czego efektem było by nawet tzw. „lecenie głów”).
• Osoby, które zlecają testowanie rzadko zdają sobie sprawę z tego, że testowanie nie jest procesem jednorazowym, a wdrożenie wykrytych w czasie testowania zmian nie powinno być zamknięciem tematu testowania witryny na zawsze. Zmiany, które wprowadzi się aby naprawić jeden z problemów użyteczności serwisu mogą powodować powstanie nowego problemu, który wcześniej nie występował.
• Często w sytuacji, kiedy wyniki testów wykazują, że użytkownicy gubią się jakimś momencie w serwisie pierwszym odruchem osób, które zarządzają projektem jest pomysł dodania instrukcji lub informacji dla użytkowników. Dużo lepszym rozwiązanie jest jednak usuniecie przyczyn problemów użytkowników niż dodawanie kolejnej instrukcji.
• W poprawianiu serwisu i wprowadzaniu zmian proponowany przez użytkowników trzeba się z rezerwą odnieść do propozycji dodawania nowych funkcjonalności (użytkownicy często na teście mówią coś w stylu: ”Świetnie by było, gdybym tutaj mógł również…”.

Trackback URI | Comments RSS