MeasuringU: Rating the Severity of Usability Problems

Jeśli tylko jeden na 1000 użytkowników napotyka problem z witryną, to jest to problem niewielki.

Jeśli to zdanie Cię zaniepokoiło, to powinno.

Może być tak, że ten pojedynczy problem spowodował, że informacje finansowe jednego odwiedzającego zostały nieumyślnie umieszczone w witrynie, aby mógł je zobaczyć cały świat.

Albo może to być niewielkie wahanie z etykietą na niejasnej części witryny.

Częścią odpowiedzialności specjalistów ds. doświadczeń użytkownika jest pomaganie programistom w podejmowaniu decyzji dotyczących tego, co należy naprawić.

Obliczanie częstotliwości występowania problemów i ich wagi to dwa krytyczne składniki podczas komunikowania znaczenia problemów z użytecznością. Są to również dwa z danych wejściowych potrzebnych do analizy FMEA (Failure Modes Effects Analysis), bardziej ustrukturyzowanego procesu ustalania priorytetów.

Częstotliwość problemu

Mierzenie częstotliwości występowania problemu jest generalnie proste. Weź liczbę użytkowników, którzy napotykają problem, podzieloną przez całkowitą liczbę użytkowników. Na przykład, jeśli 1 na 5 użytkowników napotka problem, częstotliwość problemu wynosi .20, czyli 20%. Częstotliwość występowania problemów może być następnie przedstawiona w postaci macierzy użytkownik po problemie. Można jej również użyć do oszacowania wielkości próbki potrzebnej do wykrycia określonego procentu problemów.

Poważność problemu

Ocena poważności problemu jest mniej obiektywna niż znalezienie częstotliwości problemu. Istnieje wiele sposobów przypisywania ocen dotkliwości. Wybrałem kilka bardziej popularnych podejść opisanych w literaturze i skontrastuję je z metodą, której używamy w Measuring Usability.

Pomimo różnic w podejściach, generalnie każda metoda proponuje podobną strukturę: zestaw uporządkowanych kategorii odzwierciedlających wpływ, jaki problem ma na użytkownika, od mniejszego do większego.

Jakob Nielsen

Jakob Nielsen zaproponował kilkadziesiąt lat temu następującą czterostopniową skalę:

0 = Nie zgadzam się, że to w ogóle jest problem z użytecznością
1 = Tylko problem kosmetyczny: nie musi być naprawiany, chyba że w projekcie jest dostępny dodatkowy czas
2 = Drobny problem z użytecznością: naprawa tego powinna mieć niski priorytet
3 = Poważny problem użyteczności: ważny do naprawienia, więc powinien mieć wysoki priorytet
4 = Katastrofa użyteczności: konieczność naprawienia tego przed wypuszczeniem produktu na rynek

Jeff Rubin

W swojej wpływowej książce z 1994 roku, Jeff nakreślił następującą skalę ważności problemu:

4: Nieużyteczny: Użytkownik nie jest w stanie lub nie będzie chciał używać określonej części produktu ze względu na sposób, w jaki produkt został zaprojektowany i wdrożony.
3: Poważny: Użytkownik prawdopodobnie użyje lub spróbuje użyć produktu w tym miejscu, ale będzie poważnie ograniczony w swoich możliwościach.
2: Umiarkowany: Użytkownik będzie w stanie korzystać z produktu w większości przypadków, ale będzie musiał podjąć pewien umiarkowany wysiłek w obejściu problemu.
1: Drażniący: Problem występuje tylko sporadycznie, można go łatwo obejść lub jest zależny od standardu, który jest poza granicami produktu. Może być również problemem kosmetycznym.

Dumas i Redish

Joe Dumas i Ginny Redish, w swojej przełomowej książce, A Practical Guide to Usability Testing, oferują podobną kategoryzację jak Rubin i Nielsen, ale dodają do problemów wymiar globalny versus lokalny. Idea jest taka, że jeśli problem wpływa na globalną nawigację w witrynie, staje się bardziej krytyczny niż lokalny problem wpływający tylko na, powiedzmy, jedną stronę.

Poziom 1: Uniemożliwia ukończenie zadania
Poziom 2: Powoduje znaczne opóźnienia i frustrację
Poziom 3: Problemy mają niewielki wpływ na użyteczność
Poziom 4: Subtelne i możliwe ulepszenia/sugestie

Chauncey Wilson

Chauncey Wilson sugeruje, że skale nasilenia użyteczności powinny odpowiadać skalom nasilenia systemów śledzenia błędów w firmie. Proponuje on pięciopunktową skalę z następującymi poziomami. Wcześniej używał podobnego czteropunktowego wariantu.

Poziom 1: Katastrofalny błąd powodujący nieodwracalną utratę danych lub uszkodzenie sprzętu lub oprogramowania. Problem może powodować awarie na dużą skalę, które uniemożliwiają wielu osobom wykonywanie pracy. Wydajność jest tak zła, że system nie może zrealizować celów biznesowych.
Poziom 2: Poważny problem, powodujący możliwą utratę danych. Użytkownik nie ma możliwości obejścia problemu. Wydajność jest tak niska, że system jest powszechnie uważany za „żałosny”.
Poziom 3: Umiarkowany problem, nie powodujący trwałej utraty danych, ale stratę czasu. Istnieje obejście problemu. Wewnętrzne niespójności skutkują zwiększonym poziomem uczenia się lub błędów. Ważna funkcja lub cecha nie działa zgodnie z oczekiwaniami.
Poziom 4: Drobny, ale irytujący problem. Ogólnie rzecz biorąc, powoduje utratę danych, ale problem nieznacznie spowalnia użytkowników. Występują minimalne naruszenia wytycznych, które mają wpływ na wygląd lub postrzeganie, a błędy są możliwe do naprawienia.
Poziom 5: Błąd minimalny. Problem jest rzadki i nie powoduje utraty danych ani dużej straty czasu. Drobny problem kosmetyczny lub dotyczący spójności.

Wilson i Dumas & Skale czerwonawe mają poważniejszy problem z niższymi liczbami. Wynika to z faktu, że we wczesnych dniach informatyki poważne błędy były nazywane „błędami poziomu 1” i te musiały być naprawione przed wydaniem produktu (Dumas, komunikacja osobista 2013). W tej skali problemy są definiowane w kategoriach utraty danych, a nie ich wpływu na wydajność lub stan emocjonalny użytkowników.

Molich & Jeffries

Rolf Molich jest znany ze swojej serii porównawczych ocen użyteczności (CUE). Znany jest również z recenzowania i pisania (często krytycznie) o jakości raportów użyteczności. On i Robin Jeffries zaproponowali trzypunktową skalę.

1. Niewielkie: krótko opóźnia użytkownika.
2. Poważne: znacznie opóźnia użytkownika, ale w końcu pozwala mu wykonać zadanie.
3. Katastrofalne: uniemożliwia użytkownikowi wykonanie zadania.

Ta trzypunktowa skala jest prostsza niż inne, ale ma tendencję do opierania się w dużym stopniu na tym, jak problem wpływa na czas wykonania zadania.

Nasze podejście

Początkowo zaczęliśmy od 7-punktowej skali oceny, w której oceniający przypisywali powadze problemu wartość od kosmetycznej (1) do katastrofalnej (7), ale stwierdziliśmy, że trudno jest łatwo rozróżnić poziomy 2 i 6. Zredukowaliśmy to do skali czteropunktowej podobnej do Rubina, Nielsena i Dumasa/Redisha powyżej i traktowaliśmy je bardziej jako kategorie niż kontinuum.

Jakkolwiek było znacznie mniej niejednoznaczności z czterema punktami, nadal znajdowaliśmy niewyraźne rozróżnienie pomiędzy dwoma środkowymi poziomami zarówno w przypisywaniu ciężkości, jak i raportowaniu poziomów problemów klientom.

Zmniejszyliśmy więc naszą skalę dotkliwości do zaledwie trzech poziomów, wraz z jednym dla spostrzeżeń, sugestii użytkownika lub pozytywnych atrybutów.

1. Niewielka: Powoduje pewne wahania lub lekką irytację.
2. Umiarkowany: Powoduje sporadyczne niepowodzenie zadania dla niektórych użytkowników; powoduje opóźnienia i umiarkowaną irytację.
3. Krytyczny: Prowadzi do niepowodzenia zadania. Powoduje skrajną irytację użytkownika.

Wgląd/Sugestia/Pozytywny: Użytkownicy wspominają o pomyśle lub obserwacji, która poprawia lub mogłaby poprawić ogólne doświadczenie.

Podsumowanie

Zamieściłem skrócone wersje tych skal poniżej w tabeli, aby pokazać podobieństwa w niektórych terminach i poziomach. Wyrównałem również skale, więc wyższe liczby wskazują na poważniejsze problemy.

Niektóre wnioski z tych poziomów nasilenia problemu:

1. Nie należy popadać w obsesję na punkcie znalezienia odpowiedniej liczby kategorii lub etykiet: Trzy kategorie są prawdopodobnie wystarczające, ale łączenie skal z poziomami śledzenia błędów lub posiadanie większej liczby poziomów, aby wygenerować więcej wewnętrznego buy-in, są zarówno uzasadnionymi powodami, aby mieć więcej punktów. Kiedy już wybierzesz system, spróbuj się go trzymać, aby umożliwić porównanie w czasie.
2. Wciąż będą występować różnice zdań między autorami i wezwania do oceny: To są przybliżone przewodniki, a nie precyzyjne instrumenty. Różni oceniający nie będą się ze sobą zgadzać, pomimo jasności poziomów ciężkości. Jednym z najlepszych podejść jest niezależne ocenianie dotkliwości przez wielu oceniających, obliczanie zgodności, a następnie uśrednianie ocen.
3. Liczby przypisane do każdego poziomu są w pewnym sensie arbitralne: Nie należy zbytnio obsesyjnie zastanawiać się, czy problemy o wyższej dotkliwości powinny mieć wyższe czy niższe numery. Ja wolę to drugie, ale to kolejność ma znaczenie. Podczas gdy odstępy między stopniami ciężkości 1, 2 i 3 są prawdopodobnie różne, rangi mogą być użyte do dodatkowej analizy przy porównywaniu różnych oceniających lub ciężkości i częstotliwości problemów.
4. Nie zapominaj o pozytywach: Dumas, Molich & Jeffries napisali przekonujący artykuł mówiący o potrzebie wskazywania pozytywnych ustaleń. Podczas gdy test użyteczności jest zwykle przeznaczony do odkrywania problemów, zrozumienie pozytywów zachęca deweloperów i nie sprawia, że ty lub twój zespół stajecie się ciągłymi zwiastunami złych wiadomości.
5. Traktuj częstotliwość oddzielnie od dotkliwości: Zgłaszamy częstotliwość występowania problemu wraz z jego dotkliwością. Gdy jest to możliwe, oddzielny analityk ocenia wagę problemu, nie znając jego częstotliwości – temat na przyszły blog.