Prototyp aplikacji może wyglądać bardzo przekonująco, gdy prowadzi po nim osoba, która go zaprojektowała. Wie, który przycisk nacisnąć, co pominąć i kiedy powiedzieć: „tu później będzie pełna lista”. Prawdziwy użytkownik tej wiedzy nie ma. Dlatego prototyp warto oddać do ręki komuś, kto zna zadanie, ale nie zna zaplanowanej ścieżki. Wtedy projekt zaczyna odpowiadać na pytania, których prezentacja zwykle nie zadaje.
Nie trzeba od razu odwzorowywać całej aplikacji. Wystarczy kilka połączonych widoków i dane zrozumiałe dla uczestnika. Jeśli test dotyczy zmiany terminu wizyty, prototyp musi pokazać istniejącą rezerwację, dostępne terminy i rezultat zmiany. Pozostałe moduły mogą być poza zakresem. Ważne, żeby badana czynność miała początek oraz koniec, a nie urywała się tuż przed miejscem, w którym zwykle powstaje problem.
Uczestnik ma wykonać zadanie, a nie podziwiać ekrany
Zamiast pytać „czy ten panel jest intuicyjny?”, przedstaw krótką sytuację. Klient zadzwonił z prośbą o przełożenie usługi, a nowy termin musi pasować do dostępności wykonawcy. Poproś o wprowadzenie zmiany. Obserwuj, gdzie uczestnik szuka informacji, co czyta i którego skutku nie potrafi przewidzieć. Pytanie o intuicyjność zazwyczaj przynosi uprzejmą opinię. Zadanie pokazuje, czy da się rzeczywiście działać bez pomocy autora.
Dobór sytuacji wynika z tego, jak opisaliście pracę przed zamówieniem aplikacji. Warto zaprosić osoby z różnych ról: pracownika wykonującego zadanie, koordynatora i kogoś, kto odbiera wynik. Nie muszą wspólnie oglądać jednego ekranu. Rozbieżności między ich potrzebami pomagają ustalić, które dane powinny być wspólne, a które widoczne tylko w odpowiednim miejscu. Spotkanie nie służy głosowaniu nad każdym kolorem.
Nie ratuj projektu podpowiedzią
Jeżeli uczestnik zatrzyma się przed przyciskiem, daj mu chwilę. Zapytaj, czego oczekuje albo jak rozumie nazwę pola. Nie tłumacz od razu prawidłowej ścieżki, bo w ten sposób odbierasz sobie informację o projekcie. Możesz zanotować, że nazwa była niezrozumiała, że zabrakło statusu albo że dwie podobne funkcje prowadziły do różnych skutków. Takie obserwacje da się później przełożyć na konkretną zmianę widoku lub reguły.
Opinie również bywają cenne, ale warto oddzielić je od trudności w wykonaniu zadania. „Wolałabym niebieski przycisk” nie ma tej samej wagi co „nie wiem, czy usunęłam rezerwację, czy tylko zamknęłam okno”. Pierwsza uwaga dotyczy preferencji. Druga sygnalizuje ryzyko błędu. Zespół może oczywiście zmienić oba elementy, jednak powinien wiedzieć, dlaczego poświęca na to czas. Prototyp nie jest konkursem na największą liczbę zaakceptowanych komentarzy.
Sprawdź także informację po wykonaniu czynności
Wiele problemów pojawia się dopiero po kliknięciu „zapisz”. Czy użytkownik wie, że zmiana została przyjęta? Czy widzi aktualny termin? Czy potrafi wrócić do sprawy bez ponownego wyszukiwania? Przy projektowaniu aplikacji dla pracowników i klientów te drobne komunikaty są częścią zadania. Brak informacji zwrotnej łatwo zamienia jedną czynność w kilka kliknięć oraz telefon z pytaniem, czy system na pewno działa.
Trzeba też pamiętać o dostępności obsługi. Możliwość odczytania etykiety, wyraźny stan przycisku czy logiczna kolejność przechodzenia między polami nie są dodatkiem dla wybranej grupy. W3C opisuje dostępność i użyteczność jako powiązane obszary. Prototyp nie zastąpi późniejszych testów gotowego kodu, ale pozwala wcześnie zauważyć niejasne komunikaty i układ wymagający zbędnego wysiłku. Sposób przygotowania zadań i zaproszenia uczestników omawiamy szerzej w artykule o testach dostępności z użytkownikami.
Zamknij test decyzjami, które ktoś potrafi odtworzyć
Dobierz też urządzenie do miejsca pracy. Różnice między aplikacją webową, PWA i mobilną stają się konkretne, gdy uczestnik próbuje obsłużyć formularz jedną ręką albo wrócić do rozpoczętego zadania. W małej firmie ten sam pracownik bywa jednocześnie operatorem, koordynatorem i osobą odpowiadającą klientowi. Prototyp powinien uwzględnić takie łączenie obowiązków, zamiast wymagać fikcyjnej struktury działów.
Po sesji zbierz problemy według ich skutku, nie według tego, kto zgłosił je głośniej. Zapisz zmianę, powód i sposób ponownego sprawdzenia. Jeśli poprawiacie nazwę statusu, wróćcie z tym samym zadaniem do kolejnej osoby. Jeśli korygujecie cały przebieg, ustalcie, czy nadal mieści się w zakresie pierwszej wersji. Dobrze przeprowadzony test może uprościć produkt; nie musi kończyć się dopisaniem nowego modułu.
Wyniki powinny również zasilić późniejsze testy odbiorowe. Wtedy projektant, programista i osoba zamawiająca sprawdzają to samo zachowanie, zamiast wracać do ogólnego wspomnienia z warsztatu. Jeśli chcesz przygotować taką próbę z Archifutura, pokaż nam jedno zadanie i osoby, które je wykonują. To wystarczy, żeby ustalić, co prototyp ma wyjaśnić, zanim zaczniemy budować działającą aplikację.
Źródła i dokumentacja
Materiały sprawdzone przy opracowaniu tekstu. Przy wyborze usługi lub technologii potwierdzamy warunki dla konkretnego projektu.
