Strona główna » Badania usability

Rodzaje zadań w testach użyteczności

19 kwietnia 2011 napisała Iga [ Brak odpowiedzi ] Drukuj wpis

Tworzenie scenariusza testów użyteczności to jeden z najważniejszych elementów badań, choć bywa często bagatelizowany. Od tego, w jaki sposób zostaną sformułowane zadania, zależy ich sposób wykonania przez użytkowników oraz wnioski, jakie będziemy w stanie wysunąć. Jared Spool opisał przykład zadania na testach użyteczności Ikea.com, którego sformułowanie diametralnie zmieniło działania użytkowników. Początkowo zadanie brzmiało – „Znajdź regał na książki”. Uczestnicy badań, pierwsze co robili, to oczywiście wpisywali hasło „regał na książki” w wyszukiwarce na stronie. Kiedy zmieniono zadanie na: “Masz ponad 200 książek beletrystycznych, obecnie porozrzucanych w pudłach po Twoim salonie. Znajdź sposób, aby je uporządkować.” – żaden z uczestników nie wpisał do wyszukiwarki hasła „regał na książki”. Większość przeglądała różne kategorie produktowe z katalogu, kilka osób użyło wyszukiwarki (np. szukając „półki”).

David Travis zaproponował taksonomię 6 rodzajów zadań testów użyteczności. Każde z nich pozwala zbadać inny rodzaj aktywności i odkryć inne informacje. W jednym scenariuszu powinniśmy użyć kilka typów zadań, a jeśli mamy taką możliwość i jest to uzasadnione, to każdy z nich.

Przeszukiwacz (ang. scavenger hunt)

To zadania, w których użytkownicy muszą odnaleźć konkretne, szczegółowo podane informacje. Wymaga takiego sformułowania, aby zadanie posiadało jedno właściwe rozwiązanie, łatwo identyfikowalne przez zespół badawczy. Zadanie takie sprawdza, na ile użytkownicy potrafią zrealizować konkretne zadania (świetnie nadają się więc do testów z pomiarem wykonania).

Przykładowo, w internetowym sklepie meblowym zadanie może brzmieć:

Odwrócony przeszukiwacz (ang. reversed scavenger hunt)

W tych zadaniach pokazujemy użytkownikowi informację, którą ma znaleźć w serwisie, np. zdjęcie przedmiotu, którego mają poszukać. Jest to szczególnie przydatny rodzaj zadania w sytuacjach, kiedy nie chcemy podpowiadać terminów i nazw, jakich można użyć. Sprawdzamy więc nie tylko sposób realizacji zadania, ale także sformułowania, których używają uczestnicy badań.

Przykładowo, w internetowym sklepie meblowym, możemy sprawdzić, w jaki sposób użytkownicy poszukują mebli systemowych:

Autogeniczne zadania (ang. self-generated tasks)

Zanim uczestnik badania rozpocznie wykonywanie zadań, pytamy go o oczekiwania względem strony. Nawiązując do odpowiedzi użytkownika, prosimy go o wykonanie zadania związanego z celem, jaki sam sobie postawił. Przykładowo, testując sklep internetowy z meblami możemy spytać się użytkownika, co chciałby wykonać na takiej stronie. Gdy odpowie nam, że chciałby zakupić komodę, dopytujemy o szczegóły – czy jakiś konkretny styl? kolor? do jakich celów, jakiego pokoju? Zadaniem moderatora jest wypracowanie poprzez rozmowę z uczestnikiem badania jak najbardziej realistycznego zadania.

Autogeniczne zadania nazywane są przez Jareda Spoola zadaniami opartymi na wywiadzie (ang. interview-based tasks). Moderator poprzez rozmowę z użytkownikami odkrywa wpierw ich zainteresowania i motywacje, a następnie wykorzystuje je do stworzenia treści zadania. Dzięki temu użytkownicy mają dużą motywację do wykonania zadania, a sama sytuacja nabiera dużego realizmu. Minusem jest jednak niepowtarzalność zadań – każdy uczestnik będzie wykonywał polecenie o nieco innej treści i realizował nieco inny cel. Dodatkową korzyścią jest odkrycie potrzeb, z których prawdopodobnie sami nie zdawalibyśmy sobie sprawy. Dlatego takie zadania są szczególnie przydatne, jeśli nie znamy do końca grupy odbiorców, ani ich potrzeb.

Semi-autogeniczne zadania (ang. part self generated tasks)

Są to zadania łączące ze sobą przeszukiwacza i zadanie autogeniczne. Badacz określa ogólny cel zadania jednak prosi użytkownika o samodzielne uzupełnienie szczegółów. Uczestników badań można także poprosić o dostarczenie własnych danych na potrzeby testu, np. testując serwis społeczności owy z przepisami kulinarnymi możemy poprosić uczestników, aby przygotowali sobie własny przepis kulinarny i następnie poprosić o jego wprowadzenie do serwisu.

Zadania inwestycyjne (ang. skin in the game tasks)

Nawet najbardziej realistycznie brzmiące zadania zawsze będą tylko grą. Inaczej zachowujemy się, gdy udajemy kupowanie biletu lotniczego do Acapulco, niż kiedy faktycznie dokonujemy takiego zakupu. Brak konsekwencji w przypadku pomyłki sprawia, że użytkownik nie skupia się tak na zadaniu, nie jest tak samo podejrzliwy, czy nie zwraca uwagi na te same informacje.

Sposobem radzenia sobie z tymi ograniczeniami jest udostępnienie uczestnikowi badań realnych zasobów do realizacji zadania. Najłatwiej jest w przypadku stron e-commerce, gdzie można dostarczyć vouchery na dowolny zakup na stronie i tym samym poprosić użytkownika o dokonanie realnego zakupu.  Zadania inwestycyjne to nie tylko wsparcie finansowe. Mogą to być inne korzyści, np. możliwość zrealizowania własnego projektu kalendarza na stronie z wizardem kalendarzy.

Rozwiązywanie problemów (ang. Troubleshooting tasks)

Zadanie z rozwiązywaniem problemów wymagają zainscenizowania sytuacji problemowej – to może być komunikat informujący o problemie z wysłaniem formularza, o niepoprawności danych w profilu użytkownika czy o braku strony. Gdy problem ten zaistnieje, prosimy użytkownika o jego rozwiązanie, czy to przy użyciu testowanej strony, czy to Google. Korzyścią takiego rodzaju zadań jest możliwość odkrycia terminologii, jakiej używają nasi użytkownicy do opisania problemów, a także przetestowania skuteczności  naszej sekcji pomocy czy FAQ. Najlepiej, aby zadanie rozwiązywania problemów dotyczyło takich sytuacji, z którymi użytkownicy faktycznie mogą się borykać w codziennej pracy z naszych systemem.

Wariacją dla tego typu zadań mogą być również takie polecenia, które wymagają od użytkownika odnalezienia informacji, których brakuje na stronie. Przykładowo, możemy w ten sposób sprawdzić, gdzie użytkownicy poszukują informacji o gwarancji na produkt i jak reagują na brak takich danych.

Diabeł tkwi w szczegółach

Uwzględnienie różnych rodzajów zadań pomaga w stworzeniu pełnego, odpowiadającego na różne problemy badawcze scenariusza. Aby opracować poprawne zadania, trzeba jeszcze wziąć pod uwagę kilka innych czynników, bowiem źle sformułowane zadania mogą negatywnie odbić się na jakości pozyskanych danych i trafności wniosków. Do tematu jeszcze powrócę.

 

Warto poczytać:

Travis, D. (2010) Creating usability test tasks that really motivate users User Focus

Spool, J. (2006) Interview-Based Tasks: Learning from Leonardo DiCaprio UIE

Spool, J. (2005) Seven Common Usability Testing Mistakes UIE

Ikonki autorstwa 177icons

Autorka

Iga Mościchowska

www: http://witflow.com
Managing Partner i UX Director w firmie WitFlow. Z zamiłowania projektant interakcji i badacz użyteczności, z wykształcenia socjolog. Szkoli, wykłada na AGH, występuje na konferencjach branżowych. Pracowała m.in. dla marek: Amica, Agora, eBay Classifieds, Egmont, Maspex Wadowice, MSZ, Polskapresse, PWN.pl, Vattenfall, a także dla licznych startupów. Czytaj więcej
Tagi: , , ,