Heurystyki Nielsena to dziesięć ogólnych zasad użyteczności interfejsu, według których ocenia się aplikacje, systemy i serwisy bez udziału użytkowników. Pozwalają w kilka dni wskazać miejsca, w których produkt utrudnia pracę: brak informacji zwrotnej, niespójne nazwy, komunikaty błędów bez wskazania rozwiązania. Poniżej każda zasada z przykładem z aplikacji B2B i pytaniem kontrolnym do samodzielnego przeglądu.
Skąd pochodzą heurystyki Nielsena
Pierwszą wersję zasad Jakob Nielsen opracował w 1990 roku razem z Rolfem Molichem jako podstawę metody oceny heurystycznej. W 1994 roku dopracował zestaw na podstawie analizy 249 problemów użyteczności i w tej postaci lista obowiązuje do dziś. W 2020 roku Nielsen Norman Group odświeżyła opisy i przykłady, ale jak zaznacza w opisie dziesięciu heurystyk, same zasady nie zmieniły się od 1994 roku.
Słowo „heurystyka” jest tu użyte celowo. To ogólne reguły, a nie szczegółowe wytyczne, więc stosuje się je tak samo do panelu administracyjnego, aplikacji mobilnej i sklepu internetowego.
10 heurystyk Nielsena z przykładami z aplikacji B2B
1. Widoczność stanu systemu
System informuje, co się dzieje, w rozsądnym czasie. Dobrze: po kliknięciu „Generuj raport” przycisk zmienia stan, a przy dłuższej operacji pojawia się pasek postępu. Źle: import pliku CSV trwa minutę i przez ten czas ekran się nie zmienia. O doborze wskaźników piszemy osobno we wpisie o loaderach w aplikacji.
Pytanie kontrolne: czy po każdej akcji trwającej dłużej niż sekundę widać, że system pracuje?
2. Zgodność systemu ze światem rzeczywistym
Interfejs używa słów i pojęć znanych użytkownikowi, a nie nazw z bazy danych. Dobrze: w systemie dla księgowych pole nazywa się „Termin płatności”. Źle: to samo pole ma etykietę „due_date_offset”, a status zamówienia brzmi „STATE_3”. O tym, skąd biorą się takie oczekiwania, piszemy we wpisie o modelach mentalnych użytkowników.
Pytanie kontrolne: czy osoba z branży klienta zrozumie każdą etykietę bez pytania zespołu technicznego?
3. Kontrola i swoboda użytkownika
Użytkownik może wycofać się z pomyłki bez długiej procedury. Dobrze: po usunięciu rekordu pojawia się komunikat z opcją „Cofnij”, a kreator konfiguracji pozwala wrócić do poprzedniego kroku bez utraty danych. Źle: zamknięcie okna modalnego kasuje wypełniony formularz.
Pytanie kontrolne: czy z każdego kroku procesu da się wyjść albo cofnąć bez utraty pracy?
4. Spójność i standardy
Te same rzeczy nazywają się i wyglądają tak samo w całym produkcie oraz zgodnie z konwencjami platformy. Źle: w jednym module przycisk głównej akcji to „Zapisz”, w drugim „Zatwierdź”, w trzecim „OK”, a każdy ma inny kolor. Taki stan jest typowy dla produktu rozwijanego przez kilka zespołów i zwykle prowadzi do decyzji o wspólnej bibliotece komponentów.
Pytanie kontrolne: ile wariantów głównego przycisku, tabeli i pola formularza jest dziś w produkcie?
5. Zapobieganie błędom
Lepszy od dobrego komunikatu o błędzie jest projekt, w którym błąd nie może się zdarzyć. Dobrze: pole daty nie pozwala wybrać terminu z przeszłości, a masowe usunięcie wymaga potwierdzenia z liczbą rekordów. Źle: formularz przyjmuje NIP w dowolnym formacie i zgłasza błąd dopiero po wysłaniu.
Pytanie kontrolne: które akcje są nieodwracalne i czy każda ma zabezpieczenie?
6. Rozpoznawanie zamiast przypominania
Użytkownik nie musi pamiętać informacji z poprzedniego ekranu. Dobrze: w trzecim kroku zamówienia widać podsumowanie wyborów z kroków pierwszego i drugiego, a filtr tabeli pokazuje aktywne warunki. Źle: identyfikator klienta trzeba przepisać ręcznie z innej zakładki.
Pytanie kontrolne: czy na którymkolwiek ekranie użytkownik musi coś zapamiętać albo zanotować?
7. Elastyczność i efektywność użycia
Produkt obsługuje nowicjusza i osobę, która pracuje w nim osiem godzin dziennie. Dobrze: skróty klawiszowe, akcje masowe w tabeli, zapisane widoki i filtry. Źle: zmiana statusu stu zgłoszeń wymaga stu osobnych wejść w szczegóły.
Pytanie kontrolne: jaką czynność użytkownicy wykonują najczęściej i ile kliknięć zajmuje?
8. Estetyka i umiar
Każda zbędna informacja konkuruje o uwagę z potrzebną. Dobrze: dashboard pokazuje kilka wskaźników, od których zależą decyzje, a reszta jest dostępna po rozwinięciu. Źle: tabela ma dwadzieścia kolumn widocznych domyślnie, z których użytkownicy korzystają z pięciu.
Pytanie kontrolne: co z tego ekranu można usunąć bez straty dla głównego zadania?
9. Pomoc w rozpoznawaniu, diagnozowaniu i naprawianiu błędów
Komunikat o błędzie mówi prostym językiem, co się stało i co zrobić. Dobrze: „Plik ma 12 MB, a limit to 10 MB. Zmniejsz plik albo podziel go na dwa”. Źle: „Wystąpił błąd (500)” bez wskazania pola i bez dalszego kroku.
Pytanie kontrolne: czy każdy komunikat o błędzie wskazuje miejsce problemu i sposób naprawy?
10. Pomoc i dokumentacja
Najlepiej, gdy produkt nie wymaga instrukcji, ale w złożonych systemach pomoc jest potrzebna i powinna być dostępna tam, gdzie pojawia się pytanie. Dobrze: krótkie objaśnienie przy polu „Stawka ryczałtu” i link do pełnego opisu. Źle: jeden plik PDF z instrukcją sprzed trzech wersji produktu.
Pytanie kontrolne: czy pomoc jest dostępna z ekranu, na którym użytkownik ma trudność?
Jak przebiega ocena heurystyczna?
Ocena heurystyczna to przegląd interfejsu przez specjalistów, którzy sprawdzają go zasada po zasadzie. Nielsen Norman Group w opisie metody z 2023 roku zaleca następujący przebieg:
- Przygotowanie. Zespół ustala zakres, na przykład jedną ścieżkę albo moduł, i wybiera od trzech do pięciu oceniających.
- Niezależna ocena. Każda osoba pracuje sama przez godzinę do dwóch: najpierw poznaje interfejs, potem zapisuje naruszenia poszczególnych heurystyk. Oceniający nie widzą nawzajem swoich notatek, żeby nie wpływać na siebie.
- Konsolidacja. Zespół zestawia uwagi, łączy powtarzające się problemy i ustala priorytety poprawek.
Do ustalenia priorytetów służy skala wagi problemu zaproponowana przez Nielsena w 1994 roku. Waga zależy od trzech czynników: jak często problem występuje, jak trudno go obejść i czy wraca przy każdym użyciu.
| Ocena | Znaczenie |
|---|---|
| 0 | To nie jest problem użyteczności |
| 1 | Problem kosmetyczny, do poprawy przy okazji |
| 2 | Drobny problem, niski priorytet |
| 3 | Poważny problem, wysoki priorytet |
| 4 | Katastrofa użyteczności, do usunięcia przed wydaniem produktu |
Czego ocena heurystyczna nie wykrywa
Metoda jest szybka i tania, bo nie wymaga rekrutacji uczestników, ale ma granice. Autorki opisu metody w NN/g piszą wprost, że ocena heurystyczna nie zastępuje badań z użytkownikami. Naruszenie zasady nie zawsze jest realnym problemem, a brak naruszeń nie dowodzi, że produkt odpowiada na właściwą potrzebę. Oceniający nie znają też kontekstu pracy użytkowników tak jak oni sami.
Z tego powodu ocenę heurystyczną łączy się z danymi z analityki i z wywiadami z użytkownikami. Pierwsza metoda wskazuje, co w interfejsie łamie zasady, pozostałe pokazują, które z tych miejsc faktycznie kosztują użytkowników czas, a firmę pieniądze. Jak te metody łączy pełny audyt użyteczności, opisujemy w osobnym wpisie.
Kiedy samodzielny przegląd wystarcza, a kiedy potrzebny jest audyt
Przegląd według dziesięciu pytań kontrolnych zespół produktowy przeprowadzi sam w jedno popołudnie i znajdzie w nim oczywiste usterki. Ocena własnego produktu ma jednak słabość: autorzy znają go zbyt dobrze, żeby zauważyć to, co myli nową osobę. Zewnętrzna diagnoza daje też argumenty, których zespół nie ma, gdy ocenia własną pracę, a które są potrzebne przy uzasadnianiu zmian przed zarządem. O wyborze momentu piszemy we wpisie o tym, kiedy zrobić audyt UX.
W audycie UX/UI Squares ocena ekspercka, czyli audyt heurystyczny, jest jednym z elementów diagnozy, a wynikiem jest lista zmian z priorytetami. Pakiet Focus dla jednego obszaru produktu kosztuje od 4 500 zł netto i trwa około tygodnia. Składniki ceny opisujemy we wpisie ile kosztuje audyt użyteczności.
Najczęstsze pytania
Czym są heurystyki Nielsena?
Heurystyki Nielsena to dziesięć ogólnych zasad użyteczności interfejsu, opracowanych przez Jakoba Nielsena i Rolfa Molicha w 1990 roku i dopracowanych w 1994 roku. Służą do oceny aplikacji, systemów i serwisów przez specjalistów, bez udziału użytkowników. Od 1994 roku lista zasad się nie zmieniła.
Ilu oceniających potrzeba do oceny heurystycznej?
Nielsen Norman Group zaleca od trzech do pięciu oceniających. Każda osoba ocenia interfejs samodzielnie przez godzinę do dwóch i nie widzi notatek pozostałych. Dopiero potem zespół zestawia uwagi i ustala priorytety. Jedna osoba znajduje tylko część problemów, dlatego oceny się łączy.
Czy ocena heurystyczna zastępuje testy z użytkownikami?
Nie. Ocena heurystyczna pokazuje, gdzie interfejs łamie ogólne zasady użyteczności, ale nie mówi, czy produkt rozwiązuje właściwy problem ani jak pracują jego użytkownicy. Naruszenie zasady nie zawsze jest realną przeszkodą. Dlatego wyniki oceny zestawia się z danymi z analityki i rozmowami z użytkownikami.
Ile kosztuje audyt z oceną heurystyczną?
Audyt UX/UI w Squares kosztuje od 4 500 zł netto w pakiecie Focus, który obejmuje jeden obszar albo mniejszy produkt i trwa około tygodnia. Pakiet Pełny dla całej aplikacji zaczyna się od 8 000 zł netto, a Strategiczny od 15 000 zł netto albo w wycenie indywidualnej.
