Testy użyteczności 1:1 — na co uważać?

Testy użyteczności 1:1 — na co uważać?

Dobry projektant UX wie, że wymyślenie rozwiązania problemu, przed którym stoją przyszli użytkownicy opracowywanego systemu to tylko zalążek sukcesu. Dopóki nie uzyskamy potwierdzenia swojej tezy — czyli: dopóki ktoś, kto będzie projektowanego produktu używał nie będzie zadowolony — dopóty nie możemy być pewni, że nasza praca przynosi dobre rezultaty.

Ostatnimi czasy wiele osób pytało mnie o podstawy planowania testów z użytkownikami (chodzi o wersję 1:1, twarzą w twarz) i o etapy takiego procesu. Nie będę mógł napisać na ten temat wszystkiego, co powinieneś wiedzieć. Jest tego po prostu za dużo na jeden wpis. Warto natomiast wspomnieć o tym, na co trzeba uważać.

Krótki plan akcji

Gotowy? Jedziemy. Aby coś przetestować z użytkownikiem w formie wywiadu 1:1, możesz postąpić według poniższych kroków:

  1. Zrozum, czego chcesz się dowiedzieć.
  2. Uświadom sobie, kto może dostarczyć Ci tych informacji.
  3. Wybierz: usługi agencji, klient czy Ty sam? Kto poprowadzi rekrutację?
  4. Skonstruuj screener czyli scenariusz dla agencji rekrutacyjnej. Jeżeli będziesz pracować z dobrą agencją, to może zamiast tego będziesz mógł sprawdzić screener tejże.
  5. Zrekrutuj partycypantów. Sprawdź jak dobrze profile partycypantów odpowiadają twoim kryteriom (tu właśnie kłania się powyższy screener).
  6. Spisz pytania, które zadasz w czasie sesji testowej i podziel materiał z klientem.
  7. Przeprowadź testy.
  8. Zgodnie z tym, czego potrzebuje twoja grupa docelowa interesariuszy, przygotuj informacje o potrzebnych poprawkach. Podziel się nimi.

Proste? Właściwie tak. Dlaczego więc wydaje się to tak skomplikowane dla wielu projektantów UX?

Problemy związane z testami użyteczności

O co chcesz zapytać?

Usiądź wygodnie w fotelu i zastanów się, na jakie pytania chcesz odpowiedzieć sobie prowadząc testy użyteczności. Czy chodzi Ci o zagadnienia związane z interfejsem i funkcjonalnością? Czy może próbujesz sformułować odpowiedzi na pytania, które lepiej zostałyby zaadresowane w formacie grupy fokusowej lub prostych wywiadów, w których nie przedstawisz partycypantom interfejsu? Jednym z problemów, który często trawi początkujących UXów jest brak umiejętności dobrania dobrego narzędzia badawczego do pytań, które ich drążą. Przetestuj produkt 1:1 jeśli szukasz odpowiedzi na pytania związane z interfejsem lub drogą użytkownika poprzez proces. Wybierz inne narzędzie, jeżeli chcesz dowiedzieć się więcej o samych użytkownikach lub wymaganiach początkowych dla produktu, do tego potrzebujesz bowiem dużo więcej informacji niż zdobyć zdołasz w ciągu krótkiej sesji.

Źle dobrana grupa testowa

Liczba partycypantów nie jest tak ważna jak ich “przydatność do spożycia”. O wiele więcej wyciągniesz z dobrze wyprofilowanych pięciu osób niż z przypadkowo zaproszonych ośmiu (a przynajmniej na to wskazuje moja praktyka). Upewnij się, że każdy, z kim będziesz rozmawiał odpowiada przynajmniej w dużej części wymaganiam nakreślonym na etapie definiowania grupy docelowej dla produktu. Z drugiej strony nie łam rąk, jeżeli okaże się, że jest bardzo trudno znaleźć dokładnych reprezentantów twoich person czy profili opracowanych w innej metodologii. Jeśli znajdziesz się w tej sytuacji, po prostu zrekrutuj dwie lub trzy głowy więcej. Tak, wiem, to przeciwko temu, co wkłada się do głów na wielu kursach. Praktyka jednak pokazuje, że czasem trzeba działać “po partyzancku”.

Brak weryfikacji grupy docelowej

Rekrutacja przeprowadzona przez agencję jest zdecydowanie najlepszą opcją, bo nie zajmuje dużo czasu i pewnym można być (jeśli agencja jest dobra) tego, że przyjdą do nas właściwe osoby. Wiąże się ona jednak z dużym kosztem. Dlatego dobrą opcją jest rekrutacja z pomocą klienta, ale tylko, jeżeli napiszesz dobry screener, czyli dokument-scenariusz, który posłuży jako lista pytań dla chętnych do udziału w badaniach. O tym często zapominamy i pozwalamy klientowi wytypować do testów mamy, wujków i przyjaciół interesariuszy — a potem oglądamy, jak wszystko idzie nie w stronę, w którą powinno.

O co więc chodzi? A o to, by zadzwonić (porozmawiać — mailem nie da się tego zrobić dobrze, bo ważne są odpowiedzi w czasie rzeczywistym!) do wszystkich, którzy zgłosili kandydaturę do testów po to, by dowiedzieć się, czy są ludźmi, których potrzebujemy. Dla przykładu, jeżeli testujemy stronę producenta rowerów, możemy zapytać o to, czy ktoś jeździ na rowerze, prawda? Jednak wtedy spodziewać się można, że odpowie ochoczo “tak!”, niezależnie od tego, czy jeździ (wszakże na końcu czeka parę złotych pozyskanych za pomoc w testach). Zapytaj więc o coś innego: “kiedy ostatni raz jeździłeś na rowerze? Dokąd pojechałeś i co pamiętasz z tej przejażdżki?”. Rozumiesz? Ważne jest, żeby nie marnować swojego czasu i testować produkty z tymi, którzy się do tego nadają, czyli pasują do definicji grupy docelowej.

Pytania zadawaj także, a nawet zwłaszcza, jeżeli rekrutujesz spośród przyjaciół i znajomych. Tak, tego też nie powinieneś robić, ale test z mamą lepszy niż żaden. Naprawdę.

Brak dobrego scenariusza testowego

Napisz scenariusz testowy (z angielska mówi się o tym discussion guide), w którym ujmiesz w punktach zadania, które powinien wykonać partycypant i pytania, na które poszukujesz odpowiedzi. Dla przykładu — znów rowery:

Zadanie 1

Zakup nowego łańcucha do roweru

Instrukcje dla partycypanta: Używając dostępnych metod (nawigacja, wyszukiwarka wewnętrzna) znajdź łańcuch dobry dla twojego roweru.

Obserwuj

  1. Jak partycypant wybiera markę, której łańcuch kupi? Czy użyje nawigacji czy też listy po prawej albo wyszukiwarki?
  2. Jak partycypant wybiera długość łańcucha?
  3. Czy przydają się na coś zdjęcia? Jak łatwo prowadzić z nimi interakcję?

Zapytaj

  1. Jak oceniasz to doświadczenie?
  2. Skąd jesteś pewien, że dobrałeś łańcuch poprawnej długości?
  3. Jak trudno było dobrać długość łańcucha?

I tak dalej. Zadawaj pytania w sposób, który nie sugeruje odpowiedzi i pozostawiaj je otwartymi. Jeśli zapytasz: “czy trudno było kupić łańcuch?”, partycypant odpowie “tak” albo “nie”. Oczywiście możesz zapytać — a nawet powinieneś! — “dlaczego?”, ale lepiej już od początku uzyskiwać jak najbardziej wyczerpujące odpowiedzi. To pytanie powinno w ogóle stać się twoim ulubionym. Bez niego wiele się nie dowiesz.

Swój plan podeślij klientowi i poproś o recenzję. Jeżeli dobrze go sprzedasz i uwzględnisz pytania swojego zleceniodawcy w scenariuszu (oczywiście, te wybrane), to unikniesz kłopotu związanego z tłumaczeniem, dlaczego testy są reprezentatywne i miarodajne.

Bezużyteczne rekomendacje poprawek

Pisałem już o tym kilka razy, ale jeżeli na wskutek testów dowiesz się, że coś trzeba poprawić, to zespołowi technicznemu zakomunikuj to językiem technicznym, a interesariuszom, którzy liczą wyniki finansowe powiedz to zupełnie inaczej. Widziałem już prezentacje dla pełnych sal developerów, z których nic nie wynika, bo badacz mówił o konwersji i referował do KPI. Czytałem również raporty pisane dla interesariuszy wysokiego szczebla, w którym projektant powoływał się na zasady projektowania interakcji i wspominał o kolorystyce interfejsu bez choćby śladowej wzmianki o tym, jak zmiana wprowadzi poprawę konwersji czy też przybliży użytkownika do organizacji. Znaj język swojej grupy docelowej.

Brak odpowiedniej ilustracji

Klipy video z gadającymi głowami, które nie mogą się przegryźć przez funkcjonalność stworzoną tylko na podstawie żądań interesariuszy działają cuda. Warto po nie sięgać, nawet jeśli ich zmontowanie zajmuje czas. Ale nie ma sensu tego robić, jeśli klient stoi po “naszej” stronie. To samo tyczy się eyetrackingu — nie inwestuj w niego pieniędzy, jeżeli nikt nie obserwuje testów. Szkoda gotówki, którą lepiej przeznaczyć na dopieszczenie selekcji partycypantów.

Powodzenia!

Problemów i kłopotów może być więcej, ale to temat na obszerną książkę albo szkolenie (może powinienem takie zorganizować?), a nie na pojedynczy wpis. Mimo wszystko, jeżeli trzymać będziesz się planu, zadanie nie jest wcale takie skomplikowane. Dobrze przeprowadzone testy z użytkownikami zawsze zwracają ciekawe efekty i są niezwykle przydatnym narzędziem. Usuwaj je z planu projektowego tylko, jeśli naprawdę musisz.

Za dużo wiemy o projektowaniu interfejsów, żeby projektować je z zamkniętymi oczami.

Najciemniej jest zawsze pod latarnią!


Komentarze

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *