Badania opinii traktowane jako testy usability, badania z udziałem użytkowników prowadzone dopiero po stworzeniu finalnego produktu jako QA, przekonanie o zbyt wysokich kosztach badań... Niestety z tego typu błędnym myśleniem wciąż można się zetknąć.
1. Użyteczność serwisu WWW można przetestować podczas badań focusowych
Wielu firmom nadal wydaje się, że wystarczy z rzutnika wyświetlić projekt graficzny strony WWW grupie focusowej, aby konsumenci wydali wyrok czy serwis jest użyteczny. Niestety, w ten sposób można jedynie dojść do mylnych wniosków. Grupowe wywiady zogniskowane (focus group interviews) służą badaniu opinii i postaw, ale zupełnie nie nadają się do oceny tego jak produkt działa i nie pozwalają na sprawdzenie, czy osoby badane będą faktycznie potrafiły i chciały z niego korzystać.
Różnica pomiędzy badaniami focusowymi a testami użyteczności jest taka jak między wydaniem opinii o parze butów po zobaczeniu ich na fotografii i po tym jak pochodziło się w tych butach przez godzinę. Albo między obejrzeniem jakiegoś dania na zdjęciu w menu a spróbowaniem go 😉
Nie sposób ocenić produktu interaktywnego nie używając go, a sama rozmowa z użytkownikami nie może dostarczyć informacji o tym jak będzie wyglądać ich percepcja i zachowanie podczas korzystania z serwisu WWW lub aplikacji (ludzie mówią jedno, a robią drugie, często nieświadomie). Nawet jeśli osoby badane miały wcześniej okazję używać produktu prawdopodobnie ich relacje będą niezbyt wierne i niejasne (opiszcie komuś tak prostą czynność jak zawiązanie sznurowadła!). Wreszcie, sytuacja badania grupowego odbiega znacznie od naturalnych warunków korzystania z komputera, co zwykle jest aktywnością indywidualną.
Podczas prawdziwych testów użyteczności osoby badane samodzielnie wykonują na testowanym produkcie serię specjalnie przygotowanych zadań, a analiza wypowiedzi werbalnych pełni jedynie rolę uzupełniającą w stosunku do obserwacji zachowania.
W procesie projektowania interakcji badania FGI mogą przydać się jedynie na jego początkowym etapie, kiedy zbierane są informacje o potrzebach użytkowników. Choć nawet wtedy w większości przypadków lepiej sprawdzą się indywidualne wywiady pogłębione (individual in-depth interviews).
2. Tylko badania ilościowe na dużych próbach mają sens
Nieprawda. Badania użyteczności mają przede wszystkim charakter jakościowy i eksploracyjny (poszukiwanie najlepszych rozwiązań i źródeł problemów). Ich cel jest czysto praktyczny, a nie trzeba bardzo dokładnie mierzyć użyteczności, aby móc ją poprawić.
Powtarzające się analizy (Virzi 1992; Nielsen i Landauer 1993; Lewis 1994; Nielsen 2000, 2006; Faulkner 2003) wykazały, że testy prowadzone z niewielkimi grupami użytkowników (minimalne 5 osób, standardowo od 12 do 20) pozwalają na wykrycie przeważającej liczby problemów z użytecznością produktu, a dalsze zwiększanie liczby osób badanych wnosi niewiele nowych odkryć. Wymieniona liczebność próby jest optymalna ze względu na stosunek kosztów do uzyskanych efektów, choć oczywiście finalna decyzja o liczbie badanych powinna zawsze zależeć od składu grupy celowej i złożoności produktu.
(Źródło: Jakob Nielsen, Alertbox 19/03/2000, useit.com)
Podstawową zasadą, jest to że lepiej testować na mniejszej liczbie osób, za to wielokrotnie, w kolejnych iteracjach projektu. Jest tak ponieważ błędy poważniejsze przesłaniają błędy mniejsze i utrudniają ich wykrycie. (Poza tym upewniamy się, że nie wkradły się jakieś nowe błędy na późniejszym etapie.) W swoim słynnym tekście "Why You Only Need to Test With 5 Users" Jakob Nielsen nie rekomenduje wcale testowania jedynie z pięcioma użytkownikami, ale z piętnastoma - po pięciu na jedną z trzech iteracji projektu w cyklu test -> poprawki -> test -> poprawki -> test! Jest to często błędnie rozumiane.
Pewne nowe badania (Lindgaard i Chattratichart 2007) wskazały wręcz na brak istotnej korelacji między liczbą uczestników testów usability a liczbą wykrytych problemów, za to potwierdziły duże znaczenie liczby i doboru wykonywanych przez użytkowników zadań (więcej zadań to więcej wykrytych błędów).
Podobnie jak w przypadku wielu eksperymentów psychologicznych, założeniem testów usability jest to, że mimo różnic indywidualnych podstawowe zasady są wspólne dla wszystkich ludzi. Jeśli produkt na badaniach sprawia powtarzające się problemy kilkunastu użytkownikom o zupełnie przeciętnej percepcji, inteligencji, wiedzy i doświadczeniu, to prawdopodobnie będzie sprawiał podobne problemy tysiącom innych osób. Rozkład wyników testów usability jest rozkładem normalnym (Nielsen 2006) - wyniki skrajne są marginesem. Na testach należy przywiązywać uwagę do powtarzających się prawidłowości, a podchodzić z nieufnością do wyników jednostkowych.
Niektórym osobom wydaje się, że dobrą metodą przebadania użyteczności serwisu mogą być badania ankietowe przeprowadzone na reprezentatywnej próbie użytkowników. To zupełna pomyłka. Badania ankietowe, tak jak badania focusowe są badaniami opinii, a nie badaniami użycia. Można skorzystać z nich przy ocenie jednego z wymiarów użyteczności, jakim jest satysfakcja z użytkowania produktu, np. dając osobom badanym do wypełnienia ankiety po przeprowadzonych testach zadaniowych. Badania ankietowe nie umożliwią jednak poznania dokładnych powodów niezadowolenia konsumentów - do tego niezbędne są testy behawioralne.
Badania ankietowe nie tylko nie nadają się do badania użyteczności, ale nie są także dobrą metodą dla określania funkcjonalności systemu, do czego nierzadko bywają stosowane. Zwykle mamy tu do czynienia z odpowiedziami zamkniętymi, bo analiza setek pytań otwartych jest kłopotliwa, no i nie wiemy nic o kontekście dokonywanych wyborów. Sami użytkownicy nie zawsze są w stanie zaproponować najlepsze rozwiązania dla swoich potrzeb.
Dla określenia wymagań funkcjonalnych lepiej jest przeprowadzić wywiady pogłębione (IDI) ze znacznie mniejszą liczbą osób, niż zdawać się na badania ankietowe. W oparciu o narracje użytkowników podczas wywiadów można zorientować się jakie są najważniejsze scenariusze użycia produktu i na tej podstawie zaprojektować funkcjonalności. Opracowane scenariusze mogą później posłużyć do skonstruowania zadań na testy usability.
3. Szkoda czasu na badania przy projektowaniu, skoro zawsze można później przetestować gotowy serwis
Zawsze warto przeprowadzić testy usability na gotowym serwisie, aby sprawdzić użyteczność po ukończeniu produkcji, na stronach wypełnionych realną treścią. Jeśli jednak przy tworzeniu złożonych serwisów lub aplikacji pominięte zostały badania z udziałem użytkowników na etapie projektowania, może okazać się że cały model interakcji nie spełnia wymagań konsumentów. W niektórych przypadkach liczba poprawek może być tak duża, że oznaczać to będzie przebudowę niemal od zera.
Aby uniknąć przykrych i kosztownych niespodzianek warto skorzystać z możliwości przeprowadzenia badań usability na prototypie produktu, zanim zostaną poniesione koszty produkcji.
4. Projektanci, który testują użyteczność zaprojektowanego przez siebie serwisu nie są obiektywni
Celem testów nie jest przyłapanie projektantów na błędach, ale odkrycie najkorzystniejszych rozwiązań. Dzięki prowadzeniu lub obserwacji testów na żywo projektanci mogą w najpełniejszy sposób zapoznać się z problemami i potrzebami użytkowników.
Badania użyteczności powinny być traktowane jako integralny element procesu projektowego. Testy usability to nie QA, ale działalność wspomagająca projektowanie (bądź przeprojektowywanie 😉 ). Zadaniem testów jest doprowadzenie do optymalizacji projektu, a nie dokumentacja problemów - same statystyki wykonywanych przez użytkowników zadań są bezużyteczne.
Z tego względu zlecanie testów użyteczności agencjom badawczym, które nie zatrudniają prawdziwych projektantów interakcji mija się z celem. Osoby prowadzące testy, które nie zajmują się na co dzień projektowaniem nie będą mogły zadać użytkownikom zaimprowizowanych pytań dotyczących rozwiązań projektowych jakie przyszły im do głowy w czasie badania, nie wprowadzą drobnych zmian do prototypu w przerwie testów aby wypróbować jakiś nowy pomysł, nie będą potrafiły wyciągnąć praktycznych wniosków.
Z drugiej strony cenne może okazać się uwolnienie osób testujących serwis i projektantów od nacisków ludzi odpowiedzialnych za jego produkcję, którzy mogą wymuszać rozwiązania wygodne dla siebie a nie dla użytkowników 😉
5. Badania są drogim luksusem
Jak już wspominałem, wcale nie potrzeba badać olbrzymiej liczby ludzi, w dodatku dobór grupy badanej nie musi idealnie odzwierciedlać wszystkich segmentów grupy celowej, bo nie ma to aż takiego znaczenia przy testowaniu użyteczności. Koszty profesjonalnych badań usability w porównaniu do wielu badań marketingowych są niewielkie, natomiast ich rezultaty o wiele bardziej wymierne. Lepiej upewnić się, że produkt dobrze spełnia potrzeby i wymagania użytkowników, niż narażać się na spadek zysków, utratę klientów i pogorszenie opinii o marce wskutek braku użyteczności firmowej strony.
6. Badania są jedynym sposobem oceny użyteczności
Choć nic nie zastąpi badań z końcowymi użytkownikami istnieją też inne metody ewaluacji usability, takie jak audyty eksperckie. Audyty mogą składać się z analizy zadań użytkowników i sposobu w jaki produkt je realizuje oraz analizy heurystycznej użyteczności, która polega na ocenie serwisu przez kilku ekspertów w oparciu o specjalną listę zaleceń tzw. heurystyk.
Audyt ekspercki jest także podstawową metodą badania dostępności, bo oprócz testów automatycznych dotyczących głównie zgodności kodu ze specyfikacją i zaleceniami W3C, ocena wszystkich aspektów dostępności wymaga dogłębnej analizy przeprowadzonej przez człowieka.
Do poczytania:
- Focus groups vs usability testing - porównanie obu metod badawczych
- Lane Becker (Adaptive Path) - 90% of All Usability Testing is Useless - o tym że testy są bezużyteczne jeśli nie służą projektowaniu
- Jared Spool - Usability testing is an excellent training tool
- Jakob Nielsen - Voodoo Usability (1999) - o nieprawidłowych metodykach badania użyteczności
- Jakob Nielsen - Why You Only Need to Test With 5 Users (2000)
- Jakob Nielsen - Quantitative Studies: How Many Users to Test (2006) - 20 osób badanych daje wystarczający margines błędu przy analizie ilościowej
- Jakob Nielsen - Outliers and Luck in User Performance (2006) - rozkład normalny w badaniach usability
- Steve Krug - Nie każ mi myśleć! O życiowym podejściu do funkcjonalności stron internetowych, Helion 2005 - o badaniach usability dla początkujących
- Virzi, R. A. Refining the test phase of usability evaluation: How many subjects is enough? Human Factors, 34, 457-468, 1992
- Landauer, T. K., & Nielsen, J. A mathematical model of the finding of usability problems. Interchi '93, ACM Computer Human Interface Special Interest Group, 1993
- Lewis, J. R. Sample sizes for usability studies: Additional considerations. Human Factors, 36, 368-378, 1994
- Faulkner, L. Beyond the five-user assumption: Benefits of increased sample sizes in usability testing. Behavior Research Methods, Instruments and Computers, 35(3), 379-383, 2003
- G. Lindgaard, J. Chattratichart, Usability testing: What have we overlooked?, Proceedings of CHI 2007
wszystko fajnie, czy mamy / są gdzieś materiały przykładowe takich badań do wglądu ?
a co najlepsze dobry UX wpływa na SEO i wyniki w Google, więc tym bardziej warto.
Dobry artykuł.
Proszę poprawić w artykule znacznik 3 na h3, ponieważ ostatni punkt nie jest wyróżniony.
W punkcie drugim: ciągły wykres?!
Jak badać wygodę mechanizmów bezpieczeństwa?…
We wpisie 6 mitów związanych z badaniami użyteczności można przeczytać, że już w badaniach z udziałem 5 użytkowników można zidentyfikować większość problemów z użytecznością aplikacji. Zapewne w większości przypadków jest to prawda, ale mimo wszystko m…
[…] wyszukiwania najlepiej odpowiadają ich potrzebom. (Liczne grono odwiedzających trafiło do tego artykułu na moim blogu wpisując w Google frazę “testy z mitów” Sorry, to nie pomoże Wam w […]
[…] nie korzystałem z tej metody, ale jestem zwolennikiem praktycznego, jakościowego podejścia do badań użyteczności i integracji testów z procesem projektowania, więc taka metodologiczna herezja wydaje mi się […]
Witam serdecznie,
na wstępie chciałbym podzielić się moją pozytywną oceną tego wpisu – fantastyczny artykuł ! 🙂
Ponieważ w ostatnim czasie przyszło mi zmierzyć się z zagadnieniem użyteczności na potrzeby mocno niestandardowej i nowatorskiej realizacji, szukam wszystkiego co mówi o użyteczności trochę inaczej, powyżej zebrana linkologia dała mi sporo nowych miejsc pozyskiwania wiedzy 😉
Dzięki, pozdrawiam, MKowalski.
ciekawy artykul, mialem podobny przedmiot na studiach – zarzadzanie projektem 🙂