Testowa wyprawa z Nielsenem i Molichem, czyli 10 heurystyk dotyczących projektowania UI, część 2

Sierpień 29, 2018 Marta Woźniak - Semeniuk

Przedstawiamy drugi z trzech tekstów, w którym Marta Woźniak – Semeniuk analizuje heurystyki projektowania i omawia ich przydatność w testowaniu interfejsów. Pierwszą część znajdziecie tutaj.

4. Trzymaj się standardów i zachowaj spójność

Zawsze sprawdzaj, czy testowany system jest spójny, jeśli chodzi o nazewnictwo rzeczy lub działań, projekty przycisków, położenie podobnie działających buttonów i linków w różnych miejscach itp. Różne części systemu powinny być na tyle podobne, aby użytkownik nie musiał zastanawiać się, czy nie znalazł się przypadkiem po drugiej stronie lustra.
Podstrony jednej witryny powinny być spójne pod względem rozmieszczenia i nazewnictwa elementów itp. Prosząc klienta o potwierdzenie lub anulowanie, należałoby pamiętać, aby te dwie funkcje zawsze znajdowały się w tym samym miejscu. Jeśli na jednej z podstron przycisk „OK” znajduje się po prawej stronie, a przycisk „CANCEL” po lewej, a na innej jest odwrotnie, można z dużym prawdopodobieństwem założyć, że użytkownicy klikną coś, czego nie zamierzają.
Z drugiej strony, funkcje nie powinny być zbyt podobne do siebie. Kiedyś widziałam (jako użytkownik, nie jako tester) stronę sklepu internetowego, który w koszyku oferował dwie opcje: „Odrzuć” i „Zapłać”. Jedną symbolizowała ikonka papieru wyrzuconego do kosza, a drugą – koszyk zmierzający do kasy. Przynajmniej tak mi się wydaje, że właśnie to projektant miał na myśli, bo – uwierzcie na słowo – obie ikonki wyglądały prawie tak samo!
Załóżmy, że istnieje aplikacja, w której osoby potrzebujące wsparcia w niektórych obowiązkach domowych składają oferty, a „pomocnicy” mogą skontaktować się z nimi, aby zaoferować swoje usługi. Oferta może być widoczna dla wszystkich lub tylko dla pomocników, z którymi już mieliście kontakt. Jeśli wszyscy ją widzą, tryb oferty jest trybem otwartym. Oferta ma również status: szkic (przed publikacją), otwarta (po publikacji) lub zamknięta (po wybraniu pomocnika). Otwarty może być zarówno tryb oferty, jak i status. Kiedy więc ktoś mówi „oferta otwarta”, ma na myśli status lub tryb? Widzę tu potencjalny problem…
Czwarta heurystyka ma ścisły związek z drugą („Dopasowanie pomiędzy systemem a światem rzeczywistym”), którą omawiałam w pierwszej części tekstu.

Pytania, które warto zadać:

  • Czy przyciski reprezentujące te same akcje są zaprojektowane spójnie dla całego systemu?
  • Czy nazewnictwo funkcji i stanów jest spójne?
  • Czy konwencje i powszechnie używane standardy zostały zastosowane by pomóc użytkownikowi?
  • Czy przyciski, które są do siebie podobne wiążą się z tą samą akcją?
  • Czy link to zawsze np. podkreślony tekst? Czy może podkreślony tekst tylko czasami jest linkiem?

5. Zapobiegaj błędom

Zasada „lepiej dmuchać na zimne” nie jest nowa, ale często trudna w realizacji. Dobry system powinien zapobiegać pojawianiu się błędów, ale powinien również wysyłać prawidłowe komunikaty o błędach i działać tak, by nie wprawiać użytkowników w osłupienie.
Czy projektanci przewidzieli każdą sytuację? Czy zajęli się skrajnymi przypadkami? Przyznaję, że lubię sprawdzać wszystkie drobiazgi, które być może ktoś pominął podczas planowania i kodowania.
Jeśli kiedykolwiek używaliście podobnego systemu, czy było w nim coś, co nie działało prawidłowo? Sprawdźcie to. Co się stanie, jeśli użytkownik skorzysta z pola wyszukiwania? Co się stanie, jeśli szybko trzykrotnie kliknie ten sam przycisk? Co się stanie, jeśli…? Metoda testowania „na małpę” może ujawnić problemy, które należy naprawić, zanim odkryje je niedoświadczony użytkownik posiadający wolne łącze internetowe.
Poza tym, próba złamania systemu to coś, co testerzy lubią najbardziej, nieprawdaż?
Prawidłowo sformułowane komunikaty o błędach są także bardzo istotne. Użytkownikowi należy się znacznie więcej niż mgliste wrażenie, że coś tu nie gra. Jeśli w polach formularza występują błędy, system powinien pokazywać, co jest nie tak (za długie dane wejściowe, nieprawidłowy format itp.) i podpowiedzieć użytkownikowi, jak może wrócić do poprzedniego stanu lub jak wykonać dane działanie inaczej itp. Sprawdzajcie, czy użytkownik jest dobrze poinformowany i czy informacja zwrotna, którą otrzymuje, jest zrozumiała.

Pytania, które warto zadać:

  • Czy projektanci zajęli się skrajnymi przypadkami?
  • Co się stanie, jeśli użytkownik użyje/ wprowadzi maximum albo minimum danych, na które pozwala system?
  • Czy komunikaty o błędach są wyświetlane?
  • Czy komunikaty o błędach są zrozumiałe dla użytkownika?
  • Czy pozytywne i negatywne odpowiedzi systemu są dobrze przekazywane użytkownikowi?

6. Pozwalaj wybierać zamiast zmuszać do pamiętania

Typowy użytkownik ma pamięć dobrą, ale krótką i po kilku sekundach już niewiele pamięta. Aby pomóc mu w tej trudnej sytuacji, system powinien pozwalać mu wybierać spośród dostępnych opcji zamiast kazać zapamiętywać, co należy robić czy gdzie czegoś szukać.
Procesy należy testować po to, aby sprawdzić, czy użytkownik jest informowany o krokach, jakie musi podjąć, o tym, gdzie się znajduje, co może zrobić i jakie działania podjąć dalej. Jeśli system nie działa prawidłowo, użytkownik powinien otrzymać informację o tym, gdzie wystąpił błąd i jak go poprawić.
Jeśli niektóre komunikaty dotyczą nie tylko tego ekranu, na którym są wyświetlane, powinny być widoczne we wszystkich tych miejscach lub łatwo dostępne z tych miejsc.
Ma to związek z nawigacją i przemieszczaniem się w systemie: użytkownik powinien zawsze poruszać się, używając tego, co widzi, a nie tego, co pamięta.

Pytania, które warto zadać:

  • Jeśli użytkownik „przechodzi” kroki w procesie – czy na każdym kroku wie, gdzie jest?
  • Czy użytkownik może łatwo wrócić w poprzednie miejsce?
  • Czy jeżeli potrzebne są instrukcje to są one widoczne wszędzie tam, gdzie są potrzebne, czy użytkownik musi zapamiętać część informacji pomiędzy ekranami?
  • Czy instrukcje/ podpowiedzi są widoczne?
  • Czy pola, które należy wypełnić mają odpowiednie opisy, lub są wypełnione przykładowym tekstem, który zniknie gdy użytkownik zacznie pisać?

7. Zapewnij elastyczność i efektywność użycia

Bądźmy szczerzy: jeśli chodzi o komputery i urządzenia mobilne, każdy ułamek sekundy wydaje się wiecznością, zwłaszcza gdy czekamy, aż załaduje się strona internetowa czy aplikacja.

Większość użytkowników po kilku sekundach wpada w irytację i gdzieś indziej szuka tego, czego potrzebuje. Dlatego testowanie czasów ładowania jest ważne i może być dobrym punktem wyjścia do przeprowadzenia optymalizacji przez programistów w zespole. Jeśli to konieczne, sprawdzajcie, jak szybko dane rozwiązanie działa na różnych urządzeniach i systemach operacyjnych. Zmieńcie szybkość połączenia z Internetem. Zabierzcie urządzenia mobilne w drogę.
Elastyczność oznacza przyznanie użytkownikowi pewnej swobody w tym, co i w jaki sposób robi. Może to oznaczać możliwość wyboru między standardowymi a zaawansowanymi opcjami użytkownika. W takim przypadku należy sprawdzić, czy ich uruchamianie i wyłączanie jest łatwe, czy korzystanie z opcji zaawansowanych nie pozwala użytkownikowi na zbyt wiele i nie sprawi, że system będzie podatny na błędy. Użytkownik może pokazać lub ukryć jakieś elementy. Jeśli tak, przetestujcie to na różnych rozdzielczościach i urządzeniach. Zobaczcie, co się dzieje, gdy szybko kilkukrotnie klikniecie w jakiś przycisk.
Elastyczność wiąże się z dostępem (przynajmniej moim skromnym zdaniem). Ciemnoszary tekst na czarnym tle jest trudny do odczytania dla większości użytkowników i prawie niewidoczny dla osób z wadami wzroku. Tester ma obowiązek (i przywilej) pomóc zespołowi opracować produkt dostępny dla wszystkich użytkowników. Przetestujcie kontrasty i hierarchię nagłówków, używajcie klawiatury zamiast myszy. Spostrzeżenia testerów mogą być tym, co zbliża zespół do stworzenia produktu idealnego.

Pytania, które warto zadać

  • Czy system jest wydajny w kwestii ładowania/czasów odpowiedzi?
  • Czy/jak bardzo wydajność zależy od urządzenia i/lub systemu?
  • Czy system jest elastyczny?
  • Czy elastyczność systemu działa na korzyść użytkowania?
  • Czy zmiany wprowadzone przez użytkownika mogą powodować błędy?
  • Czy użytkownik może łatwo zmieniać ustawienia i przywracać je?

Koniec części 2! Już wkrótce pojawi się część 3!

Najnowsze wpisy