„System ma być intuicyjny” wyraża uzasadnioną potrzebę, ale nie jest wymaganiem gotowym do realizacji ani odbioru. Intuicyjność zależy od doświadczenia użytkownika, częstotliwości zadania, języka, urządzenia i konsekwencji błędu. Bez tych danych wykonawca oraz zamawiający mogą uczciwie rozumieć hasło zupełnie inaczej.
Najpierw odkryj, jaki problem ukrywa hasło
- Nowy użytkownik nie potrafi rozpocząć najważniejszego zadania?
- Ekspert wykonuje powtarzalną czynność zbyt długo?
- Ludzie popełniają kosztowne błędy lub nie rozumieją ich skutku?
- Interfejs wymaga pamiętania kodów i procedur?
- Osoby korzystające z klawiatury lub czytnika ekranu nie mogą ukończyć procesu?
Każda odpowiedź prowadzi do innego rozwiązania. Samouczek może pomóc nowicjuszowi, ale spowalniać eksperta. Skrót klawiaturowy zwiększa wydajność, lecz nie rozwiązuje niejasnego komunikatu błędu. Dlatego potrzebne są persony oparte na rzeczywistych rolach i krytyczne scenariusze, nie abstrakcyjny „użytkownik”.
Przypadek: rejestracja reklamacji w call center
Pierwotny zapis brzmiał: „Formularz reklamacji ma być prosty i intuicyjny”. Podczas obserwacji konsultantów okazało się, że problemem nie była liczba pól. Tracili czas na wybór kodu przyczyny z 80 pozycji, a brak numeru zamówienia odkrywali dopiero przy zapisie. Nowi pracownicy mylili datę zgłoszenia z datą zdarzenia.
Zespół określił trzy zadania: rejestracja standardowej reklamacji, zgłoszenie bez numeru zamówienia i korekta błędnej kategorii. Prototyp przetestowano z sześcioma nowymi i sześcioma doświadczonymi konsultantami. Wymagania powstały z obserwowanych barier, a nie z preferencji dotyczących wyglądu.
| Hasło | Operacjonalizacja | Sposób pomiaru |
|---|---|---|
| Łatwo rozpocząć | Nowy konsultant znajduje akcję bez instrukcji | Min. 90% rozpoczyna w 30 s |
| Szybka obsługa | Ekspert rejestruje standardową reklamację | Mediana poniżej 2 min bez czasu rozmowy |
| Mało błędów | Walidacja przed wysłaniem wskazuje pole i naprawę | Mniej niż 3% zwrotów z powodu danych |
| Zrozumiałe kategorie | Użytkownik wybiera poprawną przyczynę w scenariuszu | Min. 85% trafnych wyborów w teście |
| Dostępność | Cały scenariusz działa klawiaturą i czytnikiem | Test zgodny z przyjętym standardem WCAG |
Przykładowy zestaw wymagań
- System pokazuje maksymalnie pięć sugerowanych kategorii na podstawie opisu, ale pozwala przeszukać pełny słownik; konsultant zatwierdza wybór.
- Przed wysłaniem system grupuje błędy przy polach, przenosi fokus do pierwszego błędu i zachowuje wprowadzone dane.
- Daty „zgłoszenia” i „zdarzenia” mają osobne etykiety oraz krótkie objaśnienie dostępne bez opuszczania formularza.
- Dla braku numeru zamówienia dostępna jest jawna ścieżka alternatywna z wymaganym uzasadnieniem.
Jak zaprojektować badanie użyteczności
Przygotuj realistyczne dane i zadanie opisujące cel, nie instrukcję kliknięć. Moderator nie podpowiada, a obserwator zapisuje ukończenie, czas, błędy, miejsca zawahania i pytania uczestnika. Po scenariuszu zapytaj, czego osoba oczekiwała i jak rozumie rezultat. Rozmowa wyjaśnia przyczynę zachowania, której sam pomiar czasu nie pokaże.
Próba nie musi być ogromna, aby wykryć bariery jakościowe, lecz nie wolno przedstawiać małego testu jako precyzyjnego wyniku dla całej populacji. Dobierz osoby z grup rzeczywiście korzystających z produktu: nowych i doświadczonych, sporadycznych i intensywnych, korzystających z technologii asystujących. Krytyczne przepływy finansowe albo medyczne wymagają szerszej walidacji i ostrożniejszych progów błędu.
Nie zamieniaj antywzorca na arbitralną liczbę kliknięć
Wymóg „maksymalnie trzy kliknięcia” może pogorszyć bezpieczeństwo albo ukryć złożoność w jednym ekranie. Mierz ukończenie zadania, czas, błędy, potrzebę pomocy i zrozumienie rezultatu. Ustal warunki badania: profil osób, urządzenie, próbkę danych i to, czy uczestnik zna proces. Inaczej liczby nie są porównywalne.
Skuteczność, wydajność i satysfakcja to różne miary
Skuteczność mówi, czy zadanie ukończono poprawnie. Wydajność opisuje czas i wysiłek. Satysfakcja jest subiektywną oceną po użyciu. Szybkie zadanie może być stresujące, a lubiany ekran może generować błędy. Ustal hierarchię miar według skutku: przy zmianie rachunku ważniejsze może być uniknięcie błędu i świadome potwierdzenie niż minimalny czas.
| Scenariusz | Najważniejsza miara | Guardrail |
|---|---|---|
| Pierwsze logowanie | Ukończenie bez pomocy | Brak blokady dla czytnika ekranu |
| Codzienna rejestracja sprawy | Mediana czasu eksperta | Odsetek błędów nie rośnie |
| Zmiana danych wypłaty | Poprawność i zrozumienie skutku | Nie usuwać potwierdzenia dla szybkości |
| Obsługa błędu | Odsetek samodzielnych napraw | Komunikat nie ujawnia danych |
Dostępność nie jest dodatkiem do intuicyjności
Interfejs może być oczywisty wzrokowo i niedostępny z klawiatury. Kryteria obejmują kolejność fokusu, nazwy kontrolek, semantykę nagłówków, komunikowanie błędów i kontrast, ale także test pełnego scenariusza z technologią asystującą. Zgodność techniczna jest podstawą; obserwacja użytkownika pokazuje, czy rozwiązanie rzeczywiście pozwala osiągnąć cel.
Od wyniku badania do decyzji
Po teście rozdziel defekt, hipotezę i preferencję. Defekt blokuje lub prowadzi do błędu w uzgodnionym scenariuszu. Hipoteza wymaga kolejnego sprawdzenia. Preferencja uczestnika nie jest automatycznie wymaganiem, ale może wskazać wzorzec. Każda poprawka otrzymuje właściciela, priorytet i scenariusz regresyjny; po zmianie zespół ponawia zadanie, zamiast uznawać, że nowy ekran „wygląda czytelniej”.
Jeśli nie ma wyniku bazowego, pierwszy test służy do jego ustalenia, a nie do obiecywania arbitralnej poprawy. Kryterium może być progiem bezpieczeństwa lub celem iteracyjnym. W obu przypadkach zapisz, co stanie się po niespełnieniu: blokada wydania, poprawka przed pilotażem albo plan dalszego badania.
Checklista doprecyzowania
- Wskazano konkretną grupę użytkowników i jej doświadczenie.
- Wybrano najważniejsze oraz ryzykowne scenariusze.
- Kryteria obejmują skuteczność, czas, błędy, satysfakcję i dostępność adekwatnie do celu.
- Zdefiniowano metodę testu, próbkę i wynik bazowy.
- Rozwiązanie przechodzi badanie z użytkownikami, a nie tylko przegląd zespołu.
Dobre wymaganie jest sprawdzalne, lecz nie udaje, że jedna metryka opisuje całe doświadczenie. Zasady redakcji znajdziesz w jak napisać dobre wymaganie, a miejsce tego typu kryteriów wyjaśnia materiał o wymaganiach funkcjonalnych i niefunkcjonalnych.
