Makieta ma odpowiedzieć na pytanie, nie zachwycić
Prototyp jest roboczym modelem zachowania strony. Może mieć szare pola i tymczasową typografię, jeżeli pozwala sprawdzić, czy odbiorca rozumie ofertę, znajduje informacje i kończy zadanie. Jego celem nie jest uzyskanie deklaracji „ładne”. Chodzi o zauważenie błędnych założeń, zanim utrwalą się w kodzie i rozbudowanej grafice. Wczesne włączanie użytkowników do projektowania zaleca również W3C.
Wyobraź sobie przykładową szkołę językową. Zespół chce wyeksponować wszystkie kursy, ale rodzic szuka zajęć dla konkretnego wieku w określone dni. Makieta pozwala ustalić, czy strona zaczyna od struktury organizacyjnej szkoły, czy od decyzji rodzica. To odmienne modele informacji, których nie rozstrzygnie wybór atrakcyjniejszego zdjęcia.
Dobierz szczegółowość do sprawdzanego ryzyka
Do porównania kolejności sekcji wystarczy prosty rysunek. Do sprawdzenia przejścia formularza potrzebny jest model z działającymi polami, przyciskiem powrotu i komunikatem błędu. Nie każda makieta musi udawać gotową aplikację. Ważne, aby nie sugerowała możliwości, których nie da się przetestować, oraz nie ukrywała miejsc wymagających decyzji.
Zaznacz ograniczenia badania. Statyczny obraz nie potwierdzi obsługi klawiatury ani odczytu przez technologie asystujące. Klikalny model może nie odtwarzać czasu oczekiwania na serwer. Gdy test dotyczy tych zachowań, przygotuj niewielki prototyp HTML. Rozdzielenie pytań zapobiega traktowaniu udanego spotkania jako dowodu, że gotowa strona będzie technicznie poprawna.
Pisz zadania językiem odbiorcy
Polecenie „kliknij zakładkę Harmonogram” zdradza odpowiedź. Lepsze brzmi: znajdź zajęcia dla osoby początkującej, która może przyjść tylko po pracy. Uczestnik sam decyduje, gdzie zacznie i jak sprawdzi warunki. Obserwator notuje pierwszy wybór, zatrzymania, powroty oraz informacje, których zabrakło. Nie poprawia użytkownika po pierwszym wahaniu, bo właśnie takie momenty są materiałem do analizy.
Warto zebrać zarówno osoby znające branżę, jak i te, które kontaktują się z nią pierwszy raz. Nie buduj jednak fikcyjnej reprezentatywności z kilku rozmów. W3C podkreśla, że doświadczenie jednej osoby z niepełnosprawnością nie reprezentuje wszystkich potrzeb. Obserwacje traktuj jako dowody konkretnych problemów, a nie procentowy opis całej populacji.
Oddziel to, co widać, od interpretacji
Zapis „uczestnik wrócił trzy razy do ceny” jest obserwacją. Zdanie „cena jest za wysoka” to już interpretacja, która wymaga dodatkowego pytania. Przyczyną mogła być niejasna jednostka rozliczenia, brak informacji o materiale albo niezrozumiały dopisek. Notatki powinny zawierać przebieg i wypowiedź uczestnika, a dopiero potem hipotezę zespołu.
Prototyp można omówić z MyTworzymy.pl przy planowaniu strony dla firmy działającej w dowolnym regionie Polski. Wspólny punkt odniesienia tworzą konkretne zadania klientów, nie głosowanie nad gustem. Warto przynieść nawet niedoskonałą makietę z listą wątpliwości: pozwala ona szybciej wskazać, co należy sprawdzić przed programowaniem.
Nie pytaj wyłącznie o preferencje
Deklaracja, że uczestnik używałby konfiguratora, nie jest równoważna wykonaniu zadania. Poproś o wybór wariantu, wyjaśnienie wyniku i odnalezienie sposobu zmiany odpowiedzi. Wtedy zobaczysz, czy interfejs wspiera decyzję. Podsumowanie danych przed wysłaniem może pomóc wychwycić pomyłkę, ale powinno pozwalać na poprawienie konkretnej odpowiedzi bez ponownego przechodzenia całej ścieżki.
Wprowadź też scenariusz niepowodzenia: niedostępny termin, niepełne dane lub brak pasującej oferty. Nie trzeba celowo frustrować uczestnika. Wystarczy sprawdzić, czy rozumie komunikat i potrafi odzyskać kontrolę. Witryna oceniana tylko na idealnym przebiegu może działać dobrze do pierwszego zwyczajnego błędu, który wydarzy się po publikacji.
Wybierz poprawki według skutku dla zadania
Porządkuj problemy przez odpowiedź na trzy pytania: czy zatrzymują zakończenie zadania, jak często pojawiły się w obserwacjach i czy istnieje prosta droga obejścia. Nie sumuj bezrefleksyjnie punktów w efektowny ranking. Jedna blokada dostępu do ważnej funkcji może wymagać pilniejszej zmiany niż kilka uwag o długości nagłówka. Zapisz także niepewność, gdy obserwacji jest mało.
W rozmowie o wykonaniu strony przez MyTworzymy.pl przydatna będzie lista problemów wraz z nagranym lub opisanym przebiegiem, a nie tylko zestaw ekranów „do poprawy”. Obsługa projektu na odległość w całej Polsce nie przeszkadza w takich testach: ważne jest wspólne obejrzenie zachowania, ustalenie przyczyny i dopiero później wybór rozwiązania.
Powtórz zadanie po zmianie
Po poprawieniu prototypu wróć do tego samego celu, ale nie ucz uczestnika oczekiwanej ścieżki. Gdy to możliwe, pokaż nową wersję osobie, która nie zna poprzedniej. Porównuj sposób rozumienia informacji i możliwość zakończenia zadania, nie sam czas. Szybki rezultat może oznaczać trafny wybór albo pochopną decyzję opartą na nieporozumieniu.
Na koniec zapisz, czego test nie rozstrzygnął. Mogą to być zachowanie prawdziwego formularza, wydajność na słabszym telefonie albo współpraca z panelem pracownika. Taka lista nie obniża wartości prototypu. Określa następny etap odbioru i zapobiega przenoszeniu wniosków z prostego modelu na funkcje, których nikt jeszcze nie sprawdził.
Osobno przechowuj materiały robocze i zgodę uczestnika na zakres rejestracji spotkania. Do przekazania wykonawcy wystarczy często zanonimizowany opis problemu. Nie trzeba rozpowszechniać nagrania twarzy, nazwiska ani prywatnej historii osoby, aby uzasadnić poprawkę nawigacji. To pozwala skupić analizę na interfejsie, a nie na danych uczestnika.