Testy użyteczności to jedno z głównych zadań, którymi zajmują się osoby usprawniające UX w produktach. Pozwalają na ewaluację – czyli weryfikację naszych pomysłów z realnymi odbiorcami. Sprawdzamy jakie emocje produkt wywołuje wśród użytkowników i jak oceniają jego estetykę i użyteczność.
I dziś o metodzie, która pozwoli wam taką weryfikację przeprowadzić i której powinniście się nauczyć. Co więcej, możecie przeprowadzić ją bez problemu na własnych projektach, tych do szuflady i zaprezentować efekty w portfolio. Takie podejście pozwoli wyróżnić się na tle portfolio, które skupiają się wyłącznie na warstwie wizualnej.
Moderowane, zdalne testy użyteczności
Polegają na testowaniu interfejsu wg opracowanego wcześniej scenariusza. Osoba moderująca spotkanie przekazuje polecenia np.:
Znajdź na stronie informacje o konkretnym modelu pralki i sprawdź czy możesz obejrzeć ją w najbliższym sklepie stacjonarnym.
Obserwujemy co robi testująca naszą stronę osoba i prosimy jednocześnie by mówiła głośno, co robi i co myśli, czego szuka w trakcie wykonywania zadania. Takich zadań wykonuje się z reguły kilka i po wykonaniu ich często zadajemy dodatkowe pytania np. o opinię, ocenę interfejsu. Po przeprowadzeniu testów z kilkoma osobami, wyłonią nam się grupy obserwacji, powtarzające się problemy, uwagi. To pomaga nam poprawiać interfejsy i proponować ulepszone rozwiązania.
Dzisiaj skupimy się na moderowanych, zadaniowych testach użyteczności, które możemy poprowadzić zdalnie. Przykładem produktu, który będziemy chcieli przebadać, będzie serwis internetowy, który użytkownicy mogą przetestować używając swojej przeglądarki. Oczywiście testować można aplikacje natywne, mobilne i każdy inny typ produktu, np. ostatnio w pracy testowaliśmy urządzenia POS dla kasjerów.
Ale gdybym poruszyła wszystkie zagadnienia testowania ten materiał będzie zbyt długi.
1: Plan badawczy
Plan badawczy to dokument zawierający informacje o celach badania, problemach badawczych, metodologii, uczestnikach, narzędziach i harmonogramie. Po prostu porządkuje najważniejsze informacje o naszych planach i przydaje się gdy pracujemy w większym zespole. Nie musi mieć formy formalnego dokumentu, może być po prostu mailem z kilkoma punktami. A tu macie przykładową formatkę za darmo.
Nawet jeśli robicie badania dla siebie, zachęcam żeby zrobić go, zapisać gdzieś na kartce kilka punktów, bo pozwala się lepiej zorganizować. Taki plan będzie niezbędny jeśli realizujecie zlecenia lub pracujecie jako agencja dla klienta. Więc warto nauczyć się jak go przygotować. Robimy go niezależnie od tego jaką metodą badawczą będziemy się posługiwać.
Opowiadam dziś o testach użyteczności, więc możemy założyć, że wiemy już, że chcemy np. poprawić intuicyjność interfejsu, sprawdzić czy używana terminologia w UI jest jasna i zrozumiała oraz co możemy jeszcze usprawnić.
2: Respondenci
Kluczem do przetestowania rozwiązania będą ludzie, których prosimy o wykonywanie określonych zadań. Oznacza to, że musimy znaleźć osoby, które po pierwsze – będą chciały poświęcić swój czas, ale przede wszystkich wpiszą się w profil potencjalnych użytkowników produktu, który chcemy przetestować.
Jak dopierać osoby do testów użyteczności?
Jeżeli naszym celem jest przetestowanie interfejsu aplikacji webowej, która ma być głównym narzędziem dla księgowych, to testowanie tego interfejsu z osobami, które księgowością się nigdy nie zajmowały, da nam z pewnością sporo uwag i wskaże problemy. Ale nie będą to te same problemy i uwagi, które otrzymalibyśmy od kogoś kto zna terminologię, procesy i doskonale wie czego szuka i potrzebuje. I ma już jakieś doświadczenia z innymi produktami, a to oznacza, że ma też pewne oczekiwania. W tym przypadku powinniśmy szukać wśród respondentów osób, które pracują w tym konkretnym zawodzie.
Inaczej będzie jeśli chcemy poszerzyć grupę odbiorców tego produktu na osoby, które chciałyby się rozliczać samodzielnie z urzędem skarbowym, ale zawodowo nie zajmują się księgowością. Jeśli celem badania jest sprawdzenie jak ta grupa odbiera nasz produkt, wtedy do testów zapraszamy ludzi, którzy np. założyli niedawno swoje firmy i dopiero uczą się wszystkich formalności. Albo nigdy nie musieli tego robić, bo korzystają z usług księgowych i chcieli by na tych usługach teraz zaoszczędzić.
Respondentów zawsze dopasowujemy do typu produktu i grupy docelowej oraz celu badania.
Możemy mieć wspomniany serwis do księgowości, ale wiemy z innych źródeł, że profesjonaliści i osoby z doświadczeniem nie mają problemu żeby znaleźć informacje. Za to osoby początkujące mają ogromny problem. Wtedy do testów zapraszamy tylko tę grupę początkujących.
Tutaj podawałam przykłady konkretnych zawodów/doświadczenia, ale to nie jedyne cechy, które mogą identyfikować naszą grupę. Mamy produkty, w których doświadczenie zawodowe czy poziom wykształcenia nie ma żadnego znaczenia, a istotniejsze są np. zainteresowania lub przyzwyczajenia.
Ile osób do testów użyteczności potrzebujemy?
Złotą liczbą osób do testowania jest od 5-10 osób dla jednorodnej grupy, czyli np. tylko specjaliści o konkretnym profilu. Jeśli chciecie prowadzić testy również dla początkujących wtedy zapraszacie osobno 5-10 osób z tego profilu, czyli w testach takiego produktu bierze udział minimum 10 osób (min. 5 z jednej grupy).
Są też inne podejścia, które mówią np. o tym by do jednej tury zaprosić 3-4 użytkowników. Po tych testach wprowadzamy zmiany do produktu/prototypu i kontynuujemy testy na poprawionej wersji w kolejnych iteracjach.
Wynagrodzenie za testy użyteczności?
Za udział w testach z reguły płacimy – to może być kasa albo jakaś inna forma wynagrodzenia – np. vouchery do sklepu. Dlatego na etapie nauki i projektów do szuflady zachęcam do testowania produktów, które nie wymagają osób wyspecjalizowanych w konkretnej branży. Te trudniej znaleźć i często wyceniają swój czas dużo wyżej niż przeciętny konsument internetu.
Popytajcie znajomych i rodzinę czy nie znają kogoś, kto mógłby pomóc w testowaniu. Mam znajomą, która zachęcała do udziału w testach w zamian za domowej roboty muffinki lub ciasteczka. Mi się zdarzyło przeprowadzać testy, które robiłam na uczelni za kawę postawioną w kawiarni.
W kontekście rekrutacji możecie spotkać się z pojęciem screenera, czyli wstępnej ankiety, która pomaga upewnić się, że osoba do testów faktycznie jest z naszej grupy docelowej. Zachęcam do pogłębienia tego tematu – jest uniwersalnym narzędziem, niezależnym od wybranej metody badawczej.
3: Scenariusz
Wiemy dzięki celom badania i problemom badawczym czego chcemy się dowiedzieć, np.:
- które zadania księgowe sprawiają najwięcej trudności i dlaczego?
- jakie raporty i analizy są najważniejsze i jak często ich potrzebują?
- jakich udogodnień i cech brakuje w produkcie?
- jak często korzystają z produktu i od czego zaczynają interakcję z nim?
Wiemy, że chcemy przetestować rozwiązanie na osobach, które zaczynają prowadzenie własnej firmy i chcą oszczędzić kasę na usługach księgowych. Teraz trzeba się zastanowić, co właściwie ci ludzie mają robić w interfejsie, żebyśmy mogli go ocenić? I jakie pytania musimy zadać, by odpowiedzieć na pytania badawcze?
Np. jeśli jednym z pytań badawczych jest „jakie raporty i analizy są najważniejsze i jak często ich potrzebują?” to naturalnym będzie zrobienie zadania, które będzie zahaczało o tworzenie raportu, wyszukiwanie raportu lub coś z tymi raportami związanego.
Scenariusz testów jest po prostu listą zadań, które ludzie mają zrobić w trakcie badania. Kluczem jest odpowiednia kolejność tych zadań i treść, która nie będzie sugerowała właściwego rozwiązania. I to tworzenie niesugerujących pytań i zadań, jest w gruncie rzeczy najtrudniejszym punktem.
Formułowanie zadań i pytań w testach użyteczności
Załóżmy, że chcecie sprawdzić w jaki sposób ludzie wyszukują ebooki w konkretnej aplikacji i przy okazji ocenić jak działa nawigacja. Czy nazwy w niej użyte są intuicyjne? Jeśli treść zadania brzmiałaby:
Wyszukaj w katalogu aplikacji Wydawnictwo Czarne i sprawdź ich najnowsze ebooki.
To byłoby to sugerujące po pierwsze w jakiej kolejności wykonać zadanie – wyszukaj a później zawęź te wyszukiwania. A dodatkowo używa fraz, które pojawiają się w nawigacji – czyli „katalog” i „szukaj”. To może sprawić, że zadanie będzie prostsze i jest większa szansa, że użytkownicy zrobią to, o co ich dokładnie poprosiliśmy. A my chcemy sprawdzić czy poradziliby sobie z tym zadaniem, jeśli tych wskazówek nie dostaną. Zadanie może brzmieć wtedy:
Ktoś ze znajomych polecił Ci świeżo wydane ebooki ale nie pamiętasz tytułów, pamiętasz za to nazwę wydawnictwa – Wydawnictwo Czarne. W jaki sposób skorzystasz z aplikacji żeby odnaleźć te ebooki?
Czasami chcemy żeby ktoś przeszedł bardzo konkretną ścieżkę, bo zależy nam na sprawdzeniu wąskiego zakresu produktu. Chcemy przetestować wyszukiwarkę, więc chcemy żeby ktoś tam coś wpisał. Albo zależy nam na tym by sprawdzić funkcję wyszukiwania Paczkomatu dla konkretnej lokalizacji, więc musimy poprosić w zadaniu o to, by użytkownicy wybierali ten sposób dostawy.
Ogólność i poziom swobody jaki mają użytkownicy dobieramy do celu jaki chcemy osiągnąć. To może być swobodna eksploracja sklepu i produktów w nim albo bardzo konkretne polecenia, które pozwolą sprawdzić nam istotne dla nas obszary. Pamiętajcie jednak, że jeśli chcemy ocenić architekturę informacji, nawigację i słownictwo, starajmy się nie używać fraz istniejących w interfejsie, a szukać np. synonimów.
Treść zadań nie może być też zbyt długa i złożona – chodzi o to żeby użytkownicy pamiętali co mają zrobić. Jeżeli procesy, które testujemy są skomplikowane, możemy podzielić takie zadanie na etapy i np. w pierwszym zadaniu skupić się na wyszukiwaniu informacji. A dopiero kolejne zadanie zrobić oparte na transakcji, np. zamówieniu produktu.
Nie tylko zadania
Oprócz zadań powinniśmy mieć wprowadzenie – informujące o celach badania, jak będzie badanie wyglądało i zapewnieniu, że to nie użytkownicy są przedmiotem badania, tylko interfejs, którego będą używać. Że nie ma złych i dobrych dobrych odpowiedzi i że nie oceniacie ich, tylko to oni pomogą wam zrozumieć co działa, a co nie w produkcie, który testują.
Na wstępie dajemy pytania rozgrzewkowe, by trochę przełamać lody, np. pytamy o to czym się zajmują, jakie są ich zainteresowania – i te pytania również można dostosować do przedmiotu badań. Jeśli rozmawiamy ze wspomnianymi księgowymi, możemy podpytać o to jak wygląda ich typowy dzień pracy. Przypominamy też o protokole głośnego myślenia – czyli komentowaniu swoich działań, dzielenia się rozmyśleniami, wątpliwościami, co ich zaskoczyło.
Po zakończeniu zadań, czas na rozmowę podsumowującą – chcemy uzyskać dodatkowe uwagi i wrażenia z korzystania z produktu.
Testowanie użyteczności w tej formie nie powinno trwać dłużej niż 1-1.5 h. Nie chcemy zmęczyć za bardzo naszych odbiorców. Dlatego gdy stworzycie przykładowy scenariusz, składający się z kilku zadań, warto przeprowadzić tak zwany pilotaż. Czyli taki „test naszego testu” żeby sprawdzić czy treści zadań są jasne i zrozumiałe, czy całość nie jest za długa i czy nasz prototyp lub środowisko pozwoli na realizację tych wszystkich zadań?
4: Prototyp lub środowisko testowe
Na czymś test musimy przeprowadzić. Idealnie gdy mamy działający produkt, do którego możemy wysłać link. Czasami chcemy przetestować nową wersję produktu albo produkt, który jest na etapie koncepcji i jeszcze długo nie zostanie wdrożony.
Wtedy korzystamy z prototypów, które tworzymy w programach do UI (Figma, Sketch, ProtoPie, Axure) albo narzędziach no-code/low-code (Webflow, Framer). Prototypy mogą być po prostu połączone kilkoma linkami albo pozwalać na zaawansowane interakcje. To mogą być nieklikalne makiety, a nawet wstępne szkice. Wszystko zależy od tego, co chcemy zbadać.
Warto zadbać o alternatywne ścieżki
Jeśli chcemy sprawdzić różne obszary nawigacji w naszym produkcie, to warto stworzyć ścieżkę, która pozwoli wyszukiwać informacje, korzystać z filtrów lub jakiejś globalnej nawigacji. Bo rzadko kiedy korzystamy ze stron tylko w jeden sposób.
Im mniej mamy interakcji w prototypie, bardziej statyczne projekty, tym większa i istotniejsza będzie rola moderacji i odpowiedniego zadawania pytań we właściwych momentach. Czyli generalnie będzie trochę trudniej prowadzić badanie. Ale jak wspomniałam, można testować nawet statyczne obrazki albo plik w PDF. Na pierwsze testy (ćwiczenia dla początkujących) zalecam testowanie istniejącej strony bądź aplikacji. A w kolejnych testach możecie spróbować zbadać własny prototyp.
Im większy i bardziej złożony prototyp, tym większa szansa, że gdzieś jest błąd. Czy w linkowaniu, czy typie interakcji, czy treści, która pojawia się na ekranie. To ważne żeby zadbać o jakość danych, które znajdują się na ekranie, by były możliwie realne. Żadne lorem ipsum i testtesttest, losowe daty i wartości liczbowe, tylko prawdziwe imiona, miejscowości, nazwy produktów i opisy. Tak by osoby testujące czuły jakby korzystały z prawdziwego produktu.
O tym nie zapomnijcie
Jeśli prowadzimy zdalne testy, musimy pamiętać o tym, że linki, które wyślemy muszą dać się otworzyć. Jeśli mamy zahasłowane prototypy, musimy podać dane do logowania. Najlepiej nie wymagać od testujących zakładania konta żeby zobaczyć projekt. Albo instalowania wtyczek do przeglądarki.
Informacje o obsługiwanym systemie i przeglądarce, oraz prośba by na teście korzystać z komputera, a nie tabletu lub telefonu, powinny znaleźć się w zaproszeniach do testów. To technikalia, ale istotne, bo jeśli na test przygotowaliście prototyp desktopowej strony i ktoś połączy się na spotkanie online z telefonu, no to powodzenia.
Jeśli robicie prototyp w Figmie, ważne jest żeby wyłączyć podświetlanie aktywnych obszarów po kliknięciu żeby nie sugerować, gdzie ludzie powinni klikać żeby przejść dalej.
5: Prowadzenie testu
Pierwsze moderowanie testów użyteczności może być stresujące, dlatego poświęćcie chwilę na przygotowanie się. Upewnijcie się, że narzędzia są zaktualizowane i działają. Jeżeli prowadzicie zdalne testy, musicie się jakoś połączyć z odbiorcami – przetestujcie jak działa współdzielenie ekranu na Zoomie albo Google Meets czy w dowolnej appce, którą wykorzystacie. Przetestujcie prototyp i przygotujcie sobie dokładną treść scenariuszy, by móc przeczytać zadania jeśli nie chcecie ich zapamiętywać.
Ja lubię sobie przeczytać scenariusz kilka razy na głos i przed prowadzeniem testów jeszcze raz przejść przez całość – czuję się dzięki temu bardziej komfortowo.
Moderator vs obserwator w testach użyteczności
W zespołach UX często w trakcie prowadzenia badań są dwie osoby, które dzielą się na moderatora i obserwatora. Moderator to ktoś, kto prowadzi spotkanie, zadaje pytania i czyta polecenia, pogłębia rozmowę.
Obserwator to ktoś, kto uważnie obserwuje ekran i twarz, reakcje osoby testowanej i zapisuje obserwacje. Kiedy się uczymy, rzadko kiedy mamy do pomocy inną osobę.
Jeśli działacie samodzielnie, nie dacie rady jednocześnie moderować i notować obserwacji (a przynajmniej nie polecam tego robić). Dlatego w przypadku zarówno zdalnych jak i stacjonarnych testów, prosimy o zgodę na nagrywanie spotkania. Dzięki temu, zaraz po spotkaniu, możecie wrócić do nagrań i opisać najważniejsze obserwacje. I bardzo zachęcam do tego, żeby robić to od razu po spotkaniu, póki jeszcze pamiętacie co się działo.
Co ciekawe, nie tylko wy będziecie się stresować pierwszymi testami. Osoby, które biorą udział w testach często też trochę się tym faktem denerwują. No bo ktoś ich prosi o robienie rzeczy, patrzy na ręce i zadaje pytania. Rolą moderatorów jest zadbanie o komfort użytkowników, więc powinniśmy być dla nich wsparciem.
Nie robimy zadań za użytkowników
Staramy się w trakcie testów unikać sugerowania odpowiedzi i robić za nich zadania. Czasami użytkownicy nie będą wiedzieli jak coś zrobić. Zanim od razu pokażecie im rozwiązanie, zachęcajcie do tego żeby spróbowali znaleźć funkcję albo podpytajcie gdzie spodziewaliby się coś znaleźć. Co zrobili w tym przypadku? To oprócz informacji, że ktoś w trakcie testu miał w tym miejscu problem, pomoże pogłębić ten temat.
Trzeba przygotować się, że coś zawsze może pójść nie tak. Od tego, że testerzy nie pojawią się na spotkaniu lub odwołają je w ostatniej chwili, przez problemy techniczne i słabe połączenie internetowe, po zbyt późne odkrycie błędów w prototypie. Bądźcie gotowi na improwizację i nie przejmujcie się jeśli coś pójdzie nie tak.
Błędy zdarzają się nawet doświadczonym badaczkom i badaczom.
6: Analiza wyników
To ta trudna i czasochłonna część, ale obiecuję, że im więcej testów przeprowadzicie, tym szybciej będzie wam z nią szło.
Zachęcam do tego żeby po każdej sesji usiąść do podsumowania, póki na świeżo pamiętacie jeszcze co mówiła i robiła testowana osoba. Lepiej poświęcić te 30 minut niż później oglądać od nowa godzinne nagranie i próbować je podsumować. Im więcej sesji, tym bardziej zaczynają się nam mylić.
Przy analizie wyników testów użyteczności najistotniejsze będzie dla nas:
- wyłapanie, gdzie pojawiały się problemy i wątpliwości,
- w których miejscach użytkownicy wybierali inne ścieżki niż te, których się spodziewaliśmy
- co mówili lub proponowali.
Czasami mówią o rzeczach, które im się podobają albo mają pomysły na usprawnienia. Te wszystkie miejsca chcemy zanotować lub oznaczyć.
Narzędzia zrobią częściowo robotę za was
Jeśli korzystacie z zaawansowanych narzędzi do prowadzenia testów i analizy, często znajdziecie tam funkcje, które pozwalają przyspieszyć ten etap. Np. oznaczanie na nagraniu miejsc, kiedy coś ważnego się stało, pojawił się istotny komentarz lub błąd. Albo na podstawie nagrania generuje się transkrypcja i można przeprowadzić automatyczną analizę, która wstępnie pogrupuje wnioski i nazwie grupy. Taką funkcję ma np. Dovetail i UserTesting.
Jeśli prowadziłam takie spotkanie samodzielnie i nie miałam do dyspozycji niczego zaawansowanego, notowałam na kartce dokładną godzinę lub czas spotkania. Po spotkaniu wracałam do nagrania i robiłam screeny plus opisywałam w wybranym narzędziu szczegóły dotyczące tego momentu.
Do pogrupowania wniosków i oznaczenia konkretnych miejsc w interfejsie możecie użyć jakiejkolwiek wirtualnej tablicy jak FigJam, Miro czy Mural lub czegokolwiek co pozwoli wam pracować z tekstem i obrazem. Oprócz opisania obserwacji dobrze bowiem pokazać na ekranie, które elementy wprowadzały zamieszanie. Ja lubię wklejać screeny z ekranu i zaznaczać na nich te obszary.
7: Prezentacja wyników
Na kursach i książkach przeczytacie o tym, że na koniec badań tworzy się raport – tu raport z testów użyteczności, gdzie podsumowuje się najważniejsze informacje. Zachęcam jednak żeby na dobry początek pominąć etap raportu w formie długiego dokumentu, gdzie wszystko opisujecie. A w zamian spróbować skrócić najistotniejsze wnioski do jednej, maks kilku stron A4.
To po pierwsze dobre ćwiczenie żeby nauczyć się kompresować myśli i priorytetyzować informacje. A po drugie oszczędzacie dużo czasu na robienie czegoś, czego większość osób nigdy nie przeczyta. Rzeczywistość jest brutalna i nawet najciekawszy raport, jeśli składa się ze 100 stron, będzie męką do przejścia. A w rzeczywistości biznesowej, gdzie klienci lub członkowie zespołów mają dziesiątki innych zadań do zrobienia, czytanie kolejnej długiej prezentacji, jest na końcu listy priorytetów.
Nauczcie się opowiadać o wynikach i prezentować je w atrakcyjnej do konsumpcji formie. Ściana tekstu jest bardzo demotywująca i jak wspomniałam, rzadko kiedy mamy czas żeby przechodzić przez szczegółowe raporty. W ramach ćwiczeń wyobraźcie sobie, że wyniki trzeba zaprezentować nietechnicznym klientom, którzy zlecili wam testy użyteczności i pomóc im zrozumieć co odkryliście i co można dalej z tym zrobić.
8: Iteracje testów użyteczności
Wspominałam wcześniej o iteracyjnym podejściu do testowania, w którym realizujemy kilka tur badań z mniejszymi liczbami odbiorców. I trzeba o tym pamiętać, że jeśli projektujemy coś nowego albo usprawniamy istniejące rozwiązanie, to jedna tura testów magicznie nie rozwiąże wszystkich problemów. Oczywiście wiele z nich pozwoli odkryć, ale założenie tworzenia produktów opartych o dane jest takie, że te dane staramy się zbierać regularnie.
Wyobraźcie sobie, że w trakcie pierwszej tury testów odkryliście, że są jakieś poważne problemy w strukturze nawigacji. Użytkownicy jasno wam wskazują, że nie mogą się odnaleźć, nie rozumieją nazw zakładek, szukaliby informacji w innych miejscach. Jednocześnie nie macie pewności, które miejsca i nazwy będą właściwie, bo w trakcie testów pojawiły się różne propozycje.
Zamiast wdrażać od razu dużą zmianę jaką jest nowa nawigacja, można zrobić szybki prototyp i przetestować nowe propozycje by upewnić się, że to ta słuszna droga. Bądź znaleźć miejsca do dalszych usprawnień.
O tym jest właśnie iteracyjne podejście – czyli powtarzamy etap testowania i projektowania nowych rozwiązań regularnie. Bo zdarza się tak, że jeśli usuniemy najbardziej rzucające się w oczy błędy i problemy, dopiero wtedy w kolejnych testach nasi użytkownicy zwracają uwagę na inne rzeczy. Tworzenie i usprawnianie produktu to niekończąca się historia, więc warto mieć z tyłu głowy, że nie trzeba testować wszystkiego od razu, a warto skupić się najpierw na najważniejszych obszarach.
Źródła i polecajki
Oczywiście ten materiał to tylko liźnięcie tematu, więc jeśli chcecie pogłębić testy użyteczności, mam do polecenia kilka źródeł.
Niezmiennie polecam najlepszą książkę o badaniach, która wyszła po polsku. To „Badania jako podstawa projektowania User Experience” Igi Mościchowskiej i Barbary Rogoś-Turek. Pisałam o tej książce już na blogu, nie raz ją polecałam, bo znajdziecie tam szczegółowe instrukcje, przykładowe plany badań, dobre praktyki o najpopularniejszych metodach badawczych.
Jeśli nie przeszkadza wam angielski, są dwa ciekawe kursy na platformie IxDF:
- User Research – Methods and Best Practices (ponad 4h materiałów o testach)
- User Experience: The Beginner’s Guide (1h materiału o testach)
Znajdziecie również mnóstwo darmowych materiałów, zadając konkretne pytania, np. co to jest screener i jak go przygotować, jak szukać respondentów do testów i jakich narzędzi użyć do testowania użyteczności. Osobiście uwielbiam materiały, które publikuje u siebie Maze (aż szoczek, że są udostępniane za darmo).
