Testowa wyprawa z Nielsenem i Molichem, czyli 10 heurystyk dotyczących projektowania interfejsu użytkownika – część I

Lipiec 30, 2018 Marta Woźniak-Semeniuk

Kilka słów wstępu: jako tester bardzo lubię heurystyki. Odpowiednio wykorzystane mogą okazać się bardzo pomocne. Niezależnie od tego, czy testujecie eksploracyjnie, postępujecie krok po kroku zgodnie ze scenariuszem, czy też od dłuższego czasu robicie to samo w taki sam sposób (i dlatego szukacie „świeżego spojrzenia”), heurystyki mogą pomóc Wam zrobić to lepiej. Dobrze wykorzystana heurystyka może być jak droga na skróty, która pozwoli Wam szybciej i łatwiej dostać się tam, gdzie chcecie.

W tym poście chciałabym opowiedzieć Wam o dziesięciu heurystykach dotyczących projektowania interfejsu użytkownika, opracowanych przez Jakoba Nielsena i Rolfa Molicha. Stworzono je z myślą o projektantach interfejsu, ale testerzy mogą z nich korzystać, aby sprawdzić, czy przygotowane dla klienta projekty są nie tylko estetyczne, ale także funkcjonalne i spełnią swoją rolę w procesie biznesowym klienta. Jeśli testujemy projekt już wdrożony, możemy zaproponować poprawki, które sprawią, że będzie on lepszy i bardziej wartościowy. Heurystyki Nielsena i Molicha mają ścisły związek z doświadczeniem użytkownika (User Experience).

Dodajmy także, że zawsze warto przyglądać się heurystykom lub regułom/wytycznym przygotowanym dla programistów: im więcej wiemy o tym, jak działają, tym więcej metod testowania możemy wymyślić.

A zatem do dzieła!

1. Pokazuj status systemu

Rozglądacie się i nie wiecie, gdzie jesteście, ani jak dotrzeć do miejsca, do którego zmierzaliście. Być może w ogóle nie jesteście pewni, dokąd zamierzaliście trafić.

Tak może się poczuć użytkownik, jeśli nie zostanie dobrze poinformowany, w jakim miejscu w systemie się znajduje ani co się właściwie wydarzyło.
Podczas testowania zwracajcie uwagę na informacje, które otrzymuje użytkownik na temat aktualnego statusu systemu i swojego własnego położenia. User powinien być zawsze poinformowany o tym, w jaki sposób może wrócić do poprzedniego miejsca/statusu (jeśli system na to pozwala) i jak przejść do innego miejsca lub zmienić status.

Co do zasady, każde działanie, które wywołuje jakiś skutek, powinno nieść informację na temat tego skutku. Jeśli użytkownik zrobił coś dobrze, będzie oczekiwał jakiejś formy potwierdzenia – najczęściej kolor zielony będzie oznaczał, że wszystko jest ok, a czerwony poinformuje o wystąpieniu błędu. (Pamiętajmy tutaj o możliwych różnicach kulturowych. Kontekst kulturowy i jego wpływ powinny zostać wzięte pod uwagę już na etapie projektowania systemu przez UI designera przy wsparciu BA, szczególnie w przypadku systemów dedykowanych do użytkowników z innych kręgów kulturowych niż ten, w którym funkcjonujemy na co dzień).

Jeśli nie możecie łatwo określić, w którym miejscu w systemie się znajdujecie lub jak powrócić na wyższy poziom, od razu widać, że przydałyby się tutaj ulepszenia (ułatwienia dla użytkownika).

Miejcie na uwadze fakt, że to, co dobrze działa/wygląda na ekranie komputera, może stanowić problem w telefonie komórkowym – jeśli menu nawigacyjne (lub breadcrumbs) zajmuje połowę ekranu urządzenia mobilnego, użytkownik prawdopodobnie uzna to za bardziej irytujące niż użyteczne. Dobrym pomysłem jest także przeprowadzenie testów zarówno na laptopie, jak i na ekranie monitora, bowiem rozdzielczość może być zaskakująco zdradliwa, jeśli chodzi o menu. Pomagając sobie w pracy emulatorami warto pamiętać, że chociaż często są pomocne, nie są 100% odzwierciedleniem wyglądu i zachowań aplikacji na prawdziwym urządzeniu.

Pytania, które warto zadać:

  • Czy w systemie są breadcrumbsy? Czy może aktualna pozycja użytownika jest zaznaczona np. poprzez podświetlenie pozycji w menu?
  • Czy użytkownik może łatwo okreslić swoją pozycję w systemie/aplikacji?
  • Czy łatwo poruszać się po aplikacji/systemie?
  • Czy użytkownik może się dostać wszędzie tam, gdzie powinien w prosty sposób? Może niektóre części systemu są dostępne tylko po przejściu konkretnej, trudnej do odkrycia, ścieżki?
  • Czy istnieją specjalne wymagania dotyczące dostępności? (Prawne lub np. związane z misją firmy)

2. Zachowaj zgodność między systemem a rzeczywistością

Chociaż kreatywność i innowacyjność to generalnie pożądane umiejętności, czasami nie ma potrzeby wymyślania koła od nowa. Niezależnie od tego, czy testujemy aplikację mobilną do rezerwacji wizyt w salonie kosmetycznym, system do zakupu ton kamieni czy też prostą grę przeglądarkową, zawsze w jakiś sposób wiąże się to z rzeczywistością.

Przyciski, linki oraz elementy systemu powinny znajdować się w miejscach, w których użytkownik będzie ich szukał (ponieważ przywykł do tego, że właśnie tam są). Umieszczenie ważnego przycisku w najmniej oczywistym miejscu może być dobre przy rozwiązywaniu zagadek, ale nie sprawdzi się w pozostałych przypadkach.

Jeśli testujecie system księgowy, nie powinien on zawierać nieistniejących operacji (np. „Księgowanie faktury z minusowym VAT-em”). Klienci raczej nie pokochają e-sklepu z nieistniejącymi kategoriami produktów (chyba że ktoś prowadzi sklep ze śmiesznymi prezentami – wówczas może to być interesująca propozycja).

Użytkownicy są przyzwyczajeni do oglądania i używania pewnych rzeczy w określony sposób. Dla przykładu – większość z nich uzna podkreślony tekst za link, jeśli nim nie będzie, mogą pomyśleć, że coś nie działa.

Użytkownik musi rozumieć, co system do niego „mówi”. „Kup” wygląda lepiej niż „pozyskaj przedmiot w procesie wymiany aktywów finansowych na pożądaną rzecz”. Wiadomości skierowane do użytkownika muszą być tak zwięzłe, jednoznaczne i zrozumiałe, jak to tylko możliwe. Wprawdzie testerzy „są tylko od testowania”, ale lepiej jest zaproponować rozwiązanie i liczyć się z jego odrzuceniem, niż nic nie powiedzieć, wiedząc, że tracimy sposobność, by poprawić coś, co nie działa.

Jeśli słowa lub język, których używamy, są mylące dla użytkownika, nie będzie zadowolony. A my przecież chcemy, żeby był zadowolony!

Pytania, które warto zadać:

  • Czy podstawowe elementy (np. menu, przycisk „kup” i koszyk w sklepie internetowym) łatwo znaleźć na stronie?
  • Czy ktoś, kto po raz pierwszy odwiedzi stronę będzie mógł łatwo poruszać się po systemie?
  • Czy wiadomości są zrozumiałe dla użytkownika?
  • Czy język używany w programie/aplikacji jest dostosowany do użytkownika?
  • Czy jako użytkownik rozumiem proces na stronie (np. proces zakupu) i wiem, jak dotrzeć w systemie tam, gdzie chcę? [To oczywiście bardziej pytanie dotyczące procesów, ale i tak warto je zadać]

3. Daj użytkownikowi pełną kontrolę

Każdy z nas przynajmniej raz kliknął nie tam, gdzie trzeba i mniej więcej 0.2 sekundy później pomyślał: „O Boże, jak mogę to cofnąć?!”

Sprawdzajcie, czy system prosi o potwierdzenie przed usunięciem lub aktualizacją danych. Czy użytkownik może cofnąć określone działania? Są to oczywiście kwestie ściśle powiązane z przebiegiem procesów biznesowych wewnątrz systemu, ale błądzić jest rzeczą ludzką – zawsze lepiej dmuchać na zimne.

Weźmy na przykład aplikację mobilną do zamawiania jedzenia w Internecie. Jeśli w projekcie strony poświęconej jedzeniu nie ma menu lub linku do listy produktów i nie ma możliwości powrotu do wyższej kategorii niż przycisk powrotu na urządzeniu, to taki projekt pozostawia wiele do życzenia. Brak możliwości powrotu jest poważną wadą w zakresie użyteczności takiej aplikacji.


Pytania, które warto zadać:

  • Czy akcje usuwania/zmiany danych wymagają dodatkowego potwierdzenia?
  • Czy użytkownik może zrobić coś, czego nie powinien robić (do czego nie powinien mieć dostępu?)
  • Czy użytkownik może zrobić coś, co może mu zaszkodzić?
  • Czy użytkownik jest proszony o dokonanie wyboru w sytuacji, kiedy tak na prawdę go nie ma?

Ciąg dalszy nastąpi.

Najnowsze wpisy