Raporty usability: Jak opisywać problemy?
Komunikowanie rezultatów badań użyteczności – czy to pisemnie czy ustnie – jest ich kluczowym elementem. Świetnie zaplanowane i przeprowadzone testy, bogate w wartościowe dane, pójdą na marne, jeśli ich wyniki nie zostaną wyczerpująco i umiejętnie przekazane oraz udokumentowane.
Wytyczne wobec opisywania problemów z użytecznością
Poniższa lista powstała w toku złożonych, trzyetapowych badań Mirandy Carpy. (Link do szczegółowego opisu jest na końcu tego artykułu).
Kolejność ma znaczenie. Wytyczne są uporządkowane wg ważności (1 = najważniejsza).
| 1. | Wyrażaj się jasno i precyzyjnie. Unikaj wodolejstwa i żargonu.
Definiuj terminy, których używasz. Bądź konkretny/a, koncentruj się na praktycznych aspektach, nie teoretycznych. Opisuj problemy w sposób zrozumiały i przydatny dla osób nie związanych z użytecznością. Unikaj też zbytniego wchodzenia w szczegóły, bo nikomu nie będzie się chciało tego czytać. |
| 2. | Opisuj wagę problemu.
Informuj o tym, jakie konsekwencje dany błąd za sobą pociąga z uwzględnieniem perspektywy biznesowej (koszty obsługi technicznej, marnowany czas, itp.). Opisz jak często dany problem może występować i jak może wpływać na działanie systemu. |
| 3. | Odwołuj się do wyników badań.
Ilu użytkowników napotkało dany błąd i jak często? Ile czasu zajęło im zrealizowanie zadania? Wykorzystuj odpowiednie dane jakościowe i ilościowe zebrane podczas testów, aby zilustrować i potwierdzić istnienie problemu. |
| 4. | Opisuj przyczynę problemu.
Pamiętaj, aby zawrzeć opis kontekstu, w którym dany problem został zaobserwowany (np. opis zadania). Bądź przy tym ostrożny/a i nie staraj się zgadywać myśli użytkownika ani domyślać źródła problemu. |
| 5. | Opisuj zaobserwowane zachowania użytkownika.
Przytaczaj konkretne przykłady z badań (np. drogę użytkownika przez nawigację serwisu, subiektywne reakcje, zrzuty ekranu, itp.). Charakterystykę problemu uzupełniaj o informację, kto go odkrył (zauważony przez użytkownika / przez obserwatora). |
| 6. | Rekomenduj rozwiązanie problemu.
Proponuj alternatywy i kompromisy. Bądź pomocny, ale unikaj autorytaryzmu, domysłów i wyciągania nieuprawnionych wniosków. Sugestie uzupełniaj ilustracjami, zrzutami ekranu, zasadami użyteczności oraz doświadczeniem z badań. |
| 7. | Bądź dyplomatyczny.
Unikaj kategoryczny sądów i wskazywania winnych. Nie ograniczaj się do wytykania błędów, wskazuj także dobre aspekty serwisu. Krytykuj konstruktywnie. |
| 8. | Opisuj metodologię.
Wyjaśnij, jaka technika badawcza została wykorzystana (ocena ekspercka, testy w laboratorium, metody etnograficzne, itp.). Otwarcie mów o ograniczeniach badania, precyzuj jakie grupy użytkowników uczestniczyły w testach i jaki był ich zakres. |
| 9. | Pozwól czytelnikowi wczuć się w rolę użytkownika.
Twórz sugestywne i obrazowe opisy, ale jednocześnie łatwo do czytania i zrozumienia. Wystrzegaj się przy tym nadmiaru szczegółów – ważne jest to, co ma bezpośredni związek z opisywanym problemem. |
| 10. | Bądź profesjonalny.
Opieraj się na wynikach i danych, unikaj snucia domysłów i wygłaszania sądów. Wnioski popieraj także źródłami zewnętrznymi, heurystykami użyteczności i dotychczasowym doświadczeniem. |
Powyższa lista może stanowić poręczną ściągawkę dla badaczy użyteczności. Może być szczególnie przydatna dla początkujących ekspertów usability oraz dla studentów, którzy jeszcze nie mają doświadczenia w badaniach i wdrażaniu ich rezultatów.
Co w tym ciekawego dla doświadczonych?
Zwykle czas na napisanie raportu jest mocno ograniczony, więc przydaje się wiedza, które z wytycznych są najważniejsze oraz jak trudno jest się ich trzymać.
Na jakiej podstawie określać wagę danego błędu i jego przyczynę? Jak obrazuje to wykres, jest to kwestia trudna i jednocześnie ważna. Ten rodzaj oceny zależy w głównej mierze od doświadczenia i umiejętności eksperta, co sprawia, że trudno tutaj o obiektywne sądy – rozbieżności między wagami przyporządkowanymi przez różnych badaczy, nawet doświadczonych są spore. Więcej o ocenianiu wagi problemu: Judging the Severity of Usability Issues on Web Sites: This Doesn’t Work. (Zob. także post o efekcie badacza).
Równie trudną, a przy tym kontrowersyjną kwestią okazuje się przygotowywanie rekomendacji:
| Argumenty | |
| za rekomendacjami | przeciw rekomendacjom |
| Nieodzowny element raportu, m.in. za to płaci klient (szczególnie w opinii konsultantów) | W proponowanie rozwiązań należy zaangażować cały zespół i rozważyć efekty zmian na całość systemu. |
| Klient nie zawsze ma wiedzę i środki pozwalające na samodzielne opracowanie rozwiązań | Wprowadzanie zmian jest złożoną kwestią i pomysły eksperta użyteczności często nie są optymalnym rozwiązaniem. |
| Klient łatwiej przyjmuje krytykę serwisu, gdy towarzyszą jej sugestie poprawek | |
Osobiście trudno mi sobie wyobrazić, aby w warunkach rynkowych raport pozbawiony rekomendacji był wartościowy dla klienta. Nie mam możliwości sprawdzenia tego, ale zgaduję, że argumenty z prawej kolumny były przytaczane głównie ze strony akademików (także brali oni udział w badaniach) :) Niemniej trzeba pamiętać o tym, że rekomendacje powinny być osadzone w kontekście istniejącego systemu.
Wytyczne, jak samo słowo wskazuje, wytyczają tylko drogę. Są przydatne, ale nie stanowią prawdy objawionej. Które z nich są faktycznie niezbędne? Co w opisywaniu problemów z użytecznością jest najtrudniejsze? Pisz w komentarzach.
Artykuł z badania:
Developing Guidelines for Describing Usability Problems (PDF, 776 KB)

















Dodaj odpowiedź!