Użyteczność nie jest czymś, co można gotować w każdej fazie projektowania, ale musi być rozwijana i udoskonalana w trakcie całego procesu. Jeśli chcesz najlepszego produktu końcowego, musisz przewidzieć rzeczywiste scenariusze użytkowników z fazy prototypowania. Testowanie użyteczności powinno być ostatnim miejscem, w którym można zacząć myśleć o użyteczności.
Po co martwić się testowaniem użyteczności na tak wczesnym etapie, kiedy prototypowanie ma już wystarczająco dużą listę rzeczy do zrobienia? Ponieważ dopóki twój prototyp nie będzie nadawał się do użytku, wszystkie twoje testy powiedzą ci, że ludzie nie lubią strasznych produktów.
chyba że twój prototyp będzie użyteczny, wszystkie twoje testy powiedzą ci, że ludzie nie lubią strasznych produktów
To prawie oczywiste, ale projektujesz produkt, z którego będą korzystać prawdziwi ludzie. Aby przygotować go dla prawdziwych ludzi, powinien zostać przetestowany na prawdziwych ludziach. Prototypy są tworzone do eksperymentów, więc sensowne jest testowanie ich na prawdziwych użytkownikach.
Mając to na uwadze, przyjrzyjmy się, jak zachować użyteczność podczas budowania prototypu, testowania użyteczności przed prototypem oraz porady dotyczące testowania prototypów ...
Testy użyteczności przed prototypem
Testy użyteczności nie muszą rozpoczynać się od prototypowania - w rzeczywistości, jeśli masz zasoby, by zacząć wcześniej, powinieneś. Testy te, choć w większości konceptualne, mogą wskazać najlepszy sposób na ukształtowanie architektury i architektury prototypu. Najczęstsze testy poprzedzające prototypowanie obejmują:
- Sortowanie kart: prosty i niezłomny, ten test pokazuje, jak użytkownicy woleliby architekturę informacji o produkcie. Wszystkie elementy twojego produktu są zapisane na kartach, a osoby badane są proszone o zorganizowanie ich według predefiniowanych kategorii ("zamknięte") lub pod tymi, które wymyśliły ("otwarte"). Aby uzyskać szczegółowe informacje, zobacz Donna Spencer's Sortowanie kart: ostateczny przewodnik.
- Testowanie drzewa: "test siostrzany" do sortowania kart, testowanie drzewa ocenia efektywność istniejących architektur informacji. Użytkownicy otrzymują podstawową, uproszczoną mapę witryny / aplikacji / itd. i poproszony o kliknięcie, aby wykonać określone zadania. Test monitoruje, czy wybrał właściwą trasę, a jeśli nie, to, co ją zgubiło. Założyciel MeasuringU Jeff Sauro wyjaśnia szczegóły.
- Wywiady: czasami najlepszym sposobem zrozumienia użytkowników jest po prostu zapytanie. Brzmi to dość prosto, ale niuanse i strategie rozmów z użytkownikami są nieograniczone. Kate Lawrence, UX Researcher w EBSCO Publishing daje kilka wskazówek o tym, jak uruchomić je specjalnie w celu testowania użyteczności.
Naprawa problemów wcześniej jest zawsze lepsza, a te wstępne testy zapewnią, że koncepcyjny fundament prototypu będzie w dobrej formie przed wylosowaniem jednej linii.
Właściwi użytkownicy i właściwe zadania
Chociaż testy użyteczności są różne, wszystkie wymagają użytkowników, a większość z nich wiąże się z zadaniami. Ponieważ te dwa elementy są widoczne we wszystkich testach użyteczności, krótko wyjaśniamy, jak najlepiej sobie z nimi radzić.
- Rekrutacja użytkowników: po pracy z personami, powinieneś już mieć jasny obraz swoich docelowych użytkowników. Pomaga również segmentować użytkowników na podstawie zachowań. W rzeczywistości nie należy obsesyjnie analizować danych demograficznych. Największym wyróżnikiem będzie prawdopodobnie to, czy użytkownicy mają wcześniejsze doświadczenie lub posiadają wiedzę na temat swojej domeny lub branży - nie płeć, wiek ani geografia.
Wiedza o tym, kto rekrutować, to tylko pierwszy krok. Im bardziej zaangażowana część, tym je znajduj i rekrutuj. Jeff Sauro przedstawia 7 najlepszych sposobów znajdź idealnych użytkowników do testów. - Pisanie zadań: zadania określają, co faktycznie robi użytkownik podczas testu, a zatem określają, jakie czynniki są sprawdzane. Tingting Zhao, specjalista ds. Użyteczności dla Ubuntu , opisuje niektóre rozróżnienia o czym należy pamiętać przy projektowaniu zadania. Istnieją dwie główne decyzje:
za. Scenariusz bezpośredni kontra scenariusz: zadanie bezpośrednie to takie, które jest ściśle instruktażowe (np. "Przeszukaj stronę pod kątem przepisu kurczaka z Tandoori"), podczas gdy zadanie związane z scenariuszem pochodzi z kontekstu ("Organizujesz przyjęcie dla starych znajomych i potrzebujesz przepisu z kurczaka Tandoori "). Zadania bezpośrednie działają najlepiej, jeśli testujesz dane techniczne, a zadania scenariuszy są lepsze we wszystkich innych przypadkach.
b. Closed vs. open-ended: zamknięte zadanie ma jasno zdefiniowane kryteria sukcesu, a otwarte zadanie może być zakończone na wiele sposobów. Zamknięte zadania sprawdzają określone funkcjonalności, podczas gdy otwarte zadania są lepsze, aby lepiej zrozumieć, jak działają umysły Twoich użytkowników. Zamknięte zadanie będzie: "Twój przyjaciel ma urodziny w ten weekend. Znajdź fajne miejsce dla maksymalnie 15 osób. "Otwarte zadanie brzmi:" Słyszałeś, jak współpracownicy mówią o urządzeniu iWatch. Chcesz się dowiedzieć, jak to działa. "
Ogólne porady dotyczące testowania użyteczności prototypu
Biorąc pod uwagę "niekompletny" charakter prototypów ... użytkownicy będą mieli pytania ... na które moderator będzie musiał odpowiedzieć
Jednym z pierwszych pytań pytających o użyteczność jest to, czy powinno być moderowane. Chociaż istnieje wiele dobrych powodów dla niemoderowanych testów, dla testów prototypowych zalecamy moderację. Biorąc pod uwagę "niekompletny" charakter prototypów, istnieje duże prawdopodobieństwo, że użytkownicy będą mieli pytania dotyczące interfejsu użytkownika, na który moderator będzie musiał odpowiedzieć.
Innym częstym błędem w testowaniu jest zatrzymanie lub zmiana testu, jeśli użytkownik ma trudności. Ponieważ celem testów użyteczności jest znalezienie i rozwiązanie trudności, sytuacja ta może rzeczywiście sprawić, że test zakończy się sukcesem. Jeśli na przykład użytkownik odejdzie od ścieżek, które nie zostały jeszcze opracowane w prototypie, można zapytać ich, dlaczego tam się udali i co chcieliby osiągnąć. Kilka pytań uzupełniających o przeszkodach może dostarczyć cenniejszych informacji zwrotnych niż użytkownik o "perfekcyjnym przebiegu".
Różne wierności do testowania prototypów
Chociaż niektórzy wierzą w wczesne testowanie przy użyciu szorstkich prototypów, a inni opowiadają się za testowaniem prototypów o wyższej wierności, uważamy, że najlepszym podejściem jest testowanie przy każdej możliwej wierności - i tak często, jak to możliwe. Chris Farnum, starszy architekt informacji w firmie Enlighten, wyjaśnia plusy i minusy każdego rodzaju. Jak opisujemy poniżej, testy niższej dokładności są lepsze dla testowania koncepcji, podczas gdy testy wyższej dokładności są bardziej odpowiednie do testowania zaawansowanych interakcji.
najlepszym podejściem jest testowanie przy każdej wierności
- Niska wierność: testy użyteczności prototypów lo-fi, w tym prototypy papieru, mogą działać na wczesnym etapie rozwoju, ale później stają się niepraktyczne. Prototypy Lo-Fi zachęcają również do bardziej szczerej krytyki, ponieważ od razu wiadomo, że to tylko praca w toku.
Jednak na późniejszych etapach, kiedy testy użyteczności sprawdzają zaawansowane funkcje, prototypy lo-fi przestają być pomocne, ponieważ osiągnąłeś limit wierności. Jest to szczególnie ważne w przypadku prototypów papieru, ponieważ do manipulowania wszystkimi częściami potrzebny jest "komputer ludzki", co może być niezwykle trudne w przypadku dodawania menu, interakcji, stron i elementów. - Wysoka wierność: testowanie prototypów hi-fi daje użytkownikowi niemal realistyczne wrażenie, jak będzie wyglądał końcowy produkt. Prototypy Hi-Fi są idealne do testowania złożonych interakcji i twoich rozwiązań dla problemów z użytecznością odkrytych we wcześniejszych rundach testowania. Jednak w przeciwieństwie do prototypów lo-fi są one bardziej kosztowne.
- Średnia wierność: nie można wybrać między wysoką lub niską wiernością? Prototypy Mid-Fi działają najlepiej, gdy potrzebna jest równowaga między wiernością a kosztami. Jeśli zamierzasz przeprowadzić tylko jedną rundę testów użyteczności, przejdź do średniej wierności.
Cztery wytyczne dotyczące treści do testowania dowolnego prototypu
Kiedy zaczynasz budować prototyp, nie tylko dopuszczalne jest nadszarpywanie drobnych szczegółów zamiast podstawowych, czasem jest to zalecane. Ale kiedy przyjdzie czas na przetestowanie twojego prototypu, upewnij się, że wypełniłeś niektóre z tych szczegółów, które mogą zostać przeoczone z mniejszą wiernością. Z naszych doświadczeń wynika, że są to najbardziej pomocne wskazówki dotyczące przygotowania prototypu do testów:
- Unikaj lorem ipsum: rozpraszający, mylący i pozbawiony znaczenia, tekst lorem ipsum nie w pełni uchwyca przesłanie twojego produktu.
- Używaj nazw generycznych: testy mogą być bardziej zabawne przy użyciu głupich lub sławnych nazw, ale zabawa nie jest celem. Wszelkie rozproszenia będą wpływać na wyniki, więc zachowuj nazwy ogólne i realistyczne.
- Brak obrazów lub ikon zastępczych: pola z X mogą działać podczas wireframingu, ale nie w testowaniu. Obrazy i ikony odgrywają dużą rolę w UX, więc powinny być implementowane przez czas testowania, nawet jeśli są to tylko tymczasowe szkice. Wyjątek stanowi sytuacja, w której obrazy te są wyłącznie dekoracyjne i nie pomagają zrozumieć interfejsu użytkownika.
- Używaj realistycznych danych - nie wypełniaj danych, takich jak numery telefonów lub adresy za pomocą X lub dowcipów - są one rozpraszające. Realistyczne i wiarygodne dane w tym miejscu sprawią, że użytkownik przetestuje najdokładniejsze wyniki.
Uczestnicy testów mogą utrwalić się na szczegółach, które uważali za nieistotne, więc uważaj, czego nie mówisz. Te małe kroki, aby zmniejszyć dystrakcję i zamieszanie, mogą znacznie przyczynić się do czystszych danych testowych.
Przedstawiony obraz, test użyteczności przez K2_UX przez Flickr.