Raport z testu użyteczności: jak powiązać problemy z nagraniem
Jak opisać wyniki testu użyteczności: obserwacja, kontekst zadania, skutki, priorytet i weryfikacja zmiany. Przykładowa karta problemu i szablon raportu.
Raport zaczyna się od obserwacji
„Uczestnikowi nie spodobała się nawigacja” nie wyjaśnia, co poprawić. Nagranie może pokazać, że osoba trzykrotnie otworzyła sekcję płatności w poszukiwaniu zwrotów, a potem poprosiła o pomoc. To już problem, który da się odtworzyć w konkretnym zadaniu.
Zapisz warunki testu: wersję interfejsu, urządzenie, scenariusz, kryterium powodzenia i pomoc moderatora. Bez tego zespół może uznać trudność w prototypie za błąd działającego produktu albo zaliczyć wynik uzyskany po podpowiedzi jako samodzielne wykonanie.
Przełóż sesje na wyniki, które można sprawdzić
Oznacz ważne fragmenty
W każdej sesji zaznacz początek zadania, trudności, powrót do pracy i wynik. Porównaj transkrypcję z nagraniem ekranu. „Kliknąłem” nie zawsze oznacza rzeczywiste kliknięcie. Zachowaj znaczniki czasu sprzed działania i po nim, aby pokazać kontekst.
Oddziel obserwację od wyjaśnienia
Zapisz działanie i rezultat w polu obserwacji. Przypuszczalną przyczynę umieść w osobnym polu. „Szukał zwrotu w Płatnościach” to obserwacja. „Nazwa sekcji jest niejasna” to hipoteza do sprawdzenia w kolejnej wersji interfejsu.
Porównaj podobne przypadki
Łącz epizody tylko wtedy, gdy występuje ten sam problem w porównywalnym zadaniu. Podaj, ilu uczestników go napotkało i ilu wykonywało zadanie. Nie uogólniaj proporcji z małej grupy badawczej na wszystkich użytkowników produktu.
Ustal działanie i sposób sprawdzenia
Oceń skutek: zadanie zostało przerwane, wymagało pomocy lub zajęło dodatkowe kroki. Uzgodnij priorytet z uwzględnieniem kontekstu produktu. Określ, jaki obserwowalny wynik następnego testu pokaże, czy proponowana zmiana pomogła.
Użytkownik szuka sposobu na zwrot zamówienia
Poniższy przykład szkoleniowy jest fikcyjny. Nazwy, warunki i rezultaty służą wyłącznie wyjaśnieniu metody.
Pewnie jest w Płatnościach. Nie, tutaj jest tylko karta. Może napisać do pomocy? Nie widzę, gdzie zwrócić zamówienie.
Jedna wypowiedź nie pokazuje, co działo się na ekranie. Nagranie w przykładzie pokazuje dwa wejścia do Płatności i przerwanie zadania do czasu podpowiedzi moderatora. Zapisz to na karcie razem z wersją prototypu.
Link w szczegółach zamówienia to propozycja do sprawdzenia. Następny test pokaże, czy uczestnik znajdzie tę czynność bez pomocy i zrozumie, które zamówienie zwraca.
| Pole | Przykładowy zapis | Zastosowanie |
|---|---|---|
| Kontekst | Prototyp A, zwrot opłaconego zamówienia | Zrozumieć warunki |
| Dowód | Sesja U3, 08:15–09:02 | Sprawdzić fragment |
| Skutek | Kontynuowano dopiero po podpowiedzi | Ocenić wpływ |
| Następne działanie | Sprawdzić umiejscowienie w szczegółach zamówienia | Zaplanować weryfikację |
Karta problemu do raportu
Najpierw przygotuj karty, potem podsumuj główne przeszkody. Dzięki temu wnioski pozostaną związane z materiałem z testu.
Krótka nazwa problemu: Wersja / urządzenie / zadanie: Uczestnik i znacznik czasu: Zaobserwowane działanie: Skutek dla zadania: Czy moderator pomógł: Powtórzenia w porównywalnych sesjach: Przypuszczalna przyczyna: Priorytet i uzasadnienie: Proponowana zmiana: Jak zweryfikujemy wynik:
Sprawdź, czy raport pozwala podjąć działanie
- Ważne ustalenia można odnaleźć w nagraniu.
- Wiadomo, czy zadanie wykonano samodzielnie.
- Przyczynę opisano jako hipotezę.
- Propozycja ma kryterium weryfikacji w następnym teście.
Przyjrzyjmy się szczegółom
Czy potrzebne jest długie nagranie dla każdego problemu?
Nie. Wystarczy precyzyjny link lub znacznik czasu z potrzebnym kontekstem, jeśli zespół ma dostęp do źródła. Krótki fragment powinien zachować podpowiedzi i zmiany w zadaniu.
Czy można od razu podać rozwiązanie?
Tak, jako propozycję zespołu z uzasadnieniem i sposobem sprawdzenia. Podobny przycisk zasugerowany przez uczestnika nie dowodzi, że rozwiązanie działa.