Testowanie użyteczności ma niezasłużoną reputację bycia drogim i wolnym. Kiedy ludzie słyszą "badania użytkowników", wyobrażają sobie lustro jednostronne, moderatora z notatnikiem i dwutygodniowy harmonogram. Ta wersja testowania istnieje i ma swoje zastosowania – ale to nie ta wersja, której większość zespołów produktowych potrzebuje przez większość czasu.
Wersja, której większość zespołów potrzebuje, jest prostsza: pięciu użytkowników, prototyp Figmy lub środowisko przejściowe, rozmowa wideo i 45 minut na sesję. Zrobione dobrze, to ujawnia większość poważnych problemów użyteczności zanim trafia na rynek. Zrobione konsekwentnie – nawet raz na sprincie – to produkuje łączną poprawę w jakości produktu, którą żadna ilość analityki po uruchomieniu nie może powielić.
Oto jak to przeprowadzić od zera.
Pięciu uczestników to prawidłowa liczba dla większości testów użyteczności. Badania Jakoba Nielsena wykazały, że pięciu użytkowników ujawnia około 85% problemów użyteczności, z malejącymi zwrotami po tym. Przeprowadzenie trzech sesji pięciu użytkowników w różnych punktach procesu projektowania jest bardziej wartościowe niż jedna sesja z piętnastu.
Kryteria rekrutacji są ważniejsze niż liczba. Test użyteczności z pięcioma osobami, które ściśle pasują do Twojego docelowego użytkownika, ujawni rzeczywiste problemy. Test z piętnastu osobami, które nie pasują, wygeneruje szum. Zdefiniuj dwa lub trzy kryteria przesiewu – rolę, kontekst użycia, poziom wygody technicznej – i się ich trzymaj.
Najszybsza ścieżka rekrutacji dla większości zespołów to wysyłanie e-maili do istniejących użytkowników, którzy udzielili uprawnienia do kontaktu. Zaoferuj skromną zachętę – karta podarunkowa o wartości 20 funtów wystarczy na 45-minutową sesję. Staraj się zaplanować sesje w ciągu tego samego tygodnia; im dłuższa przerwa między rekrutacją a testowaniem, tym wyższy wskaźnik niedostawień.
Najczęstszy błąd w pisaniu scenariusza to pisanie zadań jako instrukcji: "Kliknij na Ustawienia, a następnie przejdź do Powiadomień i zmień swoją preferencję na..." To mówi użytkownikowi, co robić, co oznacza, że testujesz, czy potrafią podążać za kierunkami, a nie czy interfejs jest intuicyjny.
Zamiast tego napisz zadania jako scenariusze: "Wyobraź sobie, że otrzymujesz zbyt wiele powiadomień i chcesz otrzymywać alerty tylko wtedy, gdy ktoś cię wspomni bezpośrednio. Pokaż mi, co byś zrobił." To daje użytkownikowi realistyczny cel i pozwala ci obserwować, jak faktycznie nawigują – w tym gdzie się mylą.
Najtrudniejsza część moderowania testu użyteczności to opieranie się pokusie pomocy. Gdy użytkownik jest zdezorientowany, każdy instynkt mówi, aby wkroczyć i pokazać mu gdzie kliknąć. Ale zamęt to dane. Użytkownik, który się zmaga, mówi ci, że coś jest nie tak z interfejsem – i w momencie, gdy interweniujesz, tracisz sygnał.
Poproś użytkowników, aby myśleli na głos przez całą sesję: "Gdy idziesz dalej, po prostu powiedz mi co patrzysz i co myślisz." To tworzy ciągły strumień danych o ich modelu mentalnym. Zanotuj nie tylko błędy, ale wahania – użytkownik, który pauzuje przez trzy sekundy przed kliknięciem prawidłowego przycisku, nadal ujawnił problem projektowy, nawet jeśli ostatecznie odnieśli sukces.
Krok syntezy to gdzie większość wartości jest tworzona – i gdzie większość zespołów się nie daje radę. Surowe notatki z pięciu sesji nie są ustaleniami. Stają się ustaleniami, gdy omawiasz je razem jako zespół, grupujesz obserwacje według tematu i przypisując oceny ważności.
Zrób omówienie w tym samym dniu co sesje, podczas gdy obserwacje są świeże. Pogrupuj problemy do trzech kategorii: krytyczne (użytkownicy nie mogli ukończyć zadania), umiarkowane (użytkownicy ukończyli zadanie, ale ze znaczną trudnością lub błędem) i mniejsze (tarcie, które nie uniemożliwiło ukończenia). Problemy krytyczne muszą być naprawione przed uruchomieniem. Problemy umiarkowane powinny być priorytetem w następnym sprincie. Mniejsze problemy trafiają do zaległości.
Napisz ustalenia na jednej stronie: trzy główne problemy krytyczne, z dowodami od co najmniej dwóch uczestników każdy i proponowana zmiana projektu dla każdego. Wszystko, co wymaga więcej miejsca niż to, powinno być w osobnym dokumencie.