UX: Testy użyteczności

0:00Kolejny sposób na weryfikację naszych projektów, takich, które są już

0:04gotowymi projektami, gotowymi strukturami, ubranymi w jakieś prototypy

0:08albo nawet projekt UI, są testy użyteczności - testy

0:12zadaniowe, które prowadzimy na przykład z jedną osobą, która

0:16siedzi zaraz obok i wykonuje konkretne zadania na prototypie,

0:20który jej dostarczamy. Testy użyteczności opierają się

0:24raczej na pracy indywidualnej, więc tutaj nie będziemy mieć całej sali osób,

0:28z którymi będziemy pracować, raczej będziemy dobierać jedną osobę, z którą będziemy

0:33rozmawiać, która będzie pokazywała nam, jak wykonuje

0:37pewne zadania. I która będzie odpowiadała nam na pewne pytania, które

0:42zapewne pojawią się w momencie obserwacji wykonywania

0:46takich zadań. Jak zorganizować takie testy zadaniowe, takie

0:50testy użyteczności? No, przede wszystkim musimy zrekrutować sobie kilka osób. W

0:54przypadku testów użyteczności wystarczy nam od trzech do pięciu osób, żeby wyłapać

0:59takie najważniejsze, największe problemy, z którymi będziemy

1:03mieć do czynienia, jeżeli chodzi o naszą strukturę informacji,

1:07naszą nawigację czy w ogóle to, jak nazywamy poszczególne

1:11elementy. Musimy przygotować jakiś scenariusz zadań. No, bo nie możemy

1:15pozwolić sobie na to, że dajemy osobie, z którą pracujemy,

1:20po prostu prototyp i mówimy "to sobie poklikaj". Bo to

1:24tak naprawdę nie da nam za dużego feedbacku. Musimy raczej przygotować

1:28kilka zadań, kilka procesów, żeby mieć pewność, że

1:33będziemy wiedzieć, jak weryfikować czy te testy się powiodły,

1:37czy nie. Bo w momencie kiedy mamy konkretne zadanie i użytkownikowi udało

1:41się określić, osiągnąć ten cel, nie miał z tym żadnych problemów, wiedział,

1:46co i jak po kolei robi, zrobił to w miarę szybko, to wiemy, że to zadanie

1:50zostało wykonane dobrze, że nasze zadanie zostało wykonane dobrze po

1:55stronie projektowej, bo zadbaliśmy o to, żeby to właśnie tak przebiegło. Ale

1:59jeżeli to zadanie nie zostało wykonane, jeżeli gdzieś pomiędzy

2:04tymi krokami użytkownik się pogubił, zaczął klikać w inne elementy, zaczął

2:09zastanawiać się, co tak naprawdę te nazwy oznaczają, to wtedy znak, że

2:13jednak trzeba coś jeszcze poprawić, że ta nasza struktura jeszcze nie do końca jest taka

2:17oczywista i jasna dla tego użytkownika. Oczywiście

2:21oprócz użytkownika, oprócz tej osoby, która będzie przechodzić

2:26przez zadania i scenariusza takich badań, będziemy potrzebować

2:30prototypy lub makiety, na których będziemy te badania przeprowadzać. Raczej

2:35nie testujemy samej struktury. Jeżeli pokazalibyśmy takie drzewko użytkownikowi, no

2:41to nie jest to zbyt proste i oczywiste do przejścia. Oczywiście takie

2:46testy też mogą się odbywać, natomiast jako osoby początkujące, które

2:51prawdopodobnie jeszcze wcześniej nie prowadziły badań i testów, raczej będziemy

2:55robić te prostsze warianty, raczej będziemy skupiać się na tych zadaniach, które

2:59faktycznie łatwo wykonać z użytkownikami. Więc takim najprostszym

3:03sposobem jest przekazanie makiety albo prototypu użytkownikowi. I te

3:07makiety i prototypy muszą pokrywać po prostu te scenariusze zadań, które chcemy

3:12przetestować. Warto również zaprosić drugą osobę - obserwatora

3:16do takiego testu - jeżeli możemy sobie na to pozwolić. Niech to będzie drugi

3:20projektant, niech to będzie osoba, która pomoże nam robić notatki, która

3:24będzie obserwowała reakcje użytkownika. Bo oprócz tego, co użytkownik mówi,

3:28bardzo ważne jest również to, co użytkownik będzie robił na ekranie. I oczywiście

3:34bardzo ważny będzie wyraz jego twarzy. Czasami te drobne zmarszczki, które

3:38sugerują, że użytkownik zastanawia się nad czymś, grymasy niezadowolenia

3:42albo uśmiech wywołany na jego twarzy, to wszystko daje nam też jakiś feedback

3:46do tego, w jaki sposób pracuje się z tym interfejsem i z tą architekturą

3:50informacji, którą zaprojektowaliśmy. I tutaj jak w przypadku card sortingu

3:55również będziemy potrzebowali jakiegoś sprzętu do nagrań. To mogą być telefony. Jeżeli

3:59testujemy makiety na komputerze, jeżeli mamy takie makiety cyfrowe do

4:03przetestowania, możemy pobrać darmowe narzędzia do zgrywania ekranu, żeby

4:07zobaczyć, jak użytkownik ruszał się myszką po tym

4:11ekranie, są również specjalne narzędzia do zbierania heatmap, kliknięć

4:16i tym podobnych. Natomiast im prościej, tym lepiej. Raczej

4:20nie chcemy na początku inwestować w bardzo profesjonalny sprzęt i w bardzo

4:25drogie oprogramowanie, wystarczą zwykłe nagrania

4:29ekranu w połączeniu z obserwacją, z notatkami, z naszą obecnością

4:33w trakcie tego badania - to powinno w zupełności wystarczyć. Jak

4:39wygląda w ogóle takie przykładowe zadanie? Jak wygląda taki scenariusz zadania? To

4:44naprawdę nie musi być nic skomplikowanego. Tutaj mamy przykład strony Eduweb i

4:48jeżeli chciałabym przetestować architekturę informacji tego serwisu, mogłabym

4:52na przykład podać takie zadanie do wykonania przez

4:57użytkownika: chcesz zmienić hasło do logowania w serwisie. Pokaż

5:01kolejne kroki, których się podejmiesz. I teraz to, co będzie ważne,

5:05kiedy użytkownik usłyszy takie zadanie, to obserwacja.

5:10To znaczy od czego zaczyna, gdzie szuka tych informacji. Czy on będzie kierował

5:14się w stronę prawego górnego rogu, gdzie znajduje się avatar tego użytkownika po

5:19zalogowaniu, czy będzie szukał tych informacji gdzieś niżej, czy będzie

5:23krążył między konkretnymi kategoriami podstron, czy

5:29może od razu trafi w to miejsce, w które faktycznie musi trafić. To wszystko, te

5:33najdrobniejsze niuanse są naprawdę bardzo ważne. I tutaj musimy wcielić się w rolę

5:37obserwatorów i wyłapywać te najdrobniejsze rzeczy, bo one dają nam znać

5:41o tym, czy coś tam działa, czy jednak trzeba poprawić. Pamiętajmy

5:46o tym, żeby te zadania, które dajemy użytkownikowi do wykonania, nie były

5:50zbyt długie. Najgorsze co możemy zrobić, to bardzo długą treść zadania, której użytkownik

5:54nie jest w stanie zapamiętać i jakby traci cały cel zadania. Musi

5:58wiedzieć, co ma zrobić, co jest jego celem, natomiast wszystkie dodatkowe

6:02informacje - jeżeli musimy mu jakieś dostarczać informacje - możemy robić

6:07to w trakcie wykonywania tego zadania. Więc konstruujmy krótkie

6:11i proste zadania, przekazujmy po kolei użytkownikowi

6:15i rozmawiajmy. Jeżeli uda się wykonać to zadanie, zapytajmy o

6:19jeszcze jakieś zagadnienia, które nas interesują. Jeżeli tam jest coś, o co

6:23chcieliśmy zapytać, to zapytajmy pod koniec, żeby nie przeszkadzać użytkownikowi. Prowadźmy

6:29takie wywiady pogłębione, bo to jest dobry moment, żeby jeszcze porozmawiać z tym użytkownikiem,

6:33czego on się spodziewał, gdzie szukałby tych informacji, jak nazwałby tę

6:37zakładkę, żeby łatwiej mu się było odnaleźć w tej architekturze informacji. Ile

6:43czasu trwa taki test użyteczności, takie zadanie? No, potrafi

6:47trwać około godzinę. W zależności od tego, jak duży będziecie mieć scenariusz badań, jak

6:52dużo zadań będziecie mieć wybranych do takiego testu, ten test może

6:56trwać od piętnastu minut, pół godziny przez właśnie godzinę. Ale starajmy

7:01się nie robić dłuższych testów. Starajmy się nie męczyć użytkownika, bo im dłuższe

7:05będą testy, tym użytkownik może mniej być

7:09zaangażowany w wykonywanie tych zadań i może się okazać, że te ostatnie minuty,

7:14które są na przykład dla nas kluczowe, bo wtedy robimy jakieś główne scenariusze, będą

7:19robione już tak od niechcenia, tylko po to, żeby zakończyć badania, bo użytkownik

7:23jest po prostu już tym wszystkim zmęczony. Przygotowanie to jeden, dwa

7:28dni pracy. Jeżeli mamy już gotowe makiety, jeżeli mamy gotowe prototypy i ta architektura

7:32informacji jest skończona, to tak naprawdę musimy sprawdzić, czy linkowanie

7:36między poszczególnymi podstronami jest dobrze zrobione, czy tam faktycznie te

7:40ścieżki można przejść tak jakbyśmy tego chcieli, czy nie ma tam

7:44jakichś głupich nazw (lorem ipsum), czy te teksty faktycznie są tymi tekstami

7:48docelowymi, które chcemy przetestować. No i musimy oczywiście wziąć jeszcze pod

7:52uwagę czas analizy takiego zadania. Po takim jednym zadaniu maksymalnie

7:57do trzech godzin powinno wystarczyć na przeanalizowanie tych wszystkich

8:01zadań, wyciągnięcie jakiś wniosków. I pod koniec wszystkich badań, trzech

8:05czy pięciu, możemy wspólnie złożyć te najważniejsze wnioski i przygotować rekomendacje

8:10projektowe, rekomendacje do zmiany architektury informacji czy nawet rekomendacje

8:14do zmian prototypów, jeżeli już na nich pracujemy.