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

Październik 3, 2018 Marta Woźniak-Semeniuk

Przed Wami ostatnia część analizy heurystyk Nielsena i Molicha pod kątem przydatności dla testera oprogramowania.
Poprzednie wpisy Marty dotyczace heurystyk: część 1, część 2. Zapraszamy do lektury!

8. Dbaj o estetykę i umiar

Zespół programistów i grafików może zrobić wiele fajnych rzeczy, ale czasami zbyt wiele takich rzeczy to w sumie nic fajnego: wszystkie kolory tęczy wymieszane na stronie będą wyglądać nieprofesjonalnie, a nadmiar informacji wprowadzi użytkownika w błąd.

Im więcej informacji znajduje się w jednym miejscu, tym mniej ważne się wydają, dlatego sprawdzajcie, czy w morzu treści łatwo wyłowić to, co najważniejsze.
Dobrym pomysłem jest również rozważenie kodowania za pomocą kolorów. Np. zielony zwykle budzi dobre skojarzenia, a czerwony – złe. To dlatego wiadomość w kolorze czerwonym, nawet jeśli ma neutralne znaczenie, może być postrzegana jako zła wiadomość.

Jeśli ikonka/zdjęcie ma być klikalne, przetestujcie, czy tak jest w istocie, także w lewym dolnym rogu, ale nie tuż pod nim. Jeśli przy zdjęciu znajduje się suwak, zobaczcie, co się stanie, gdy szybko zmieniacie zdjęcia, jak długo trwa ich automatyczna zmiana i czy użytkownik ma wystarczająco dużo czasu, by przeczytać informacje. Sprawdźcie różne urządzenia, rozdzielczości i systemy. Coś, co wygląda czysto i schludnie na monitorze komputera, może wyglądać zgoła inaczej na małym ekranie urządzenia mobilnego.

Pytania, które warto zadać:

  • Czy informacje w pop-upach informują czy raczej przeszkadzają?
  • Czy łatwo poruszać się w systemie, czy ikony są łatwo zrozumiałe?
  • Czy elementy animowane przyciągają uwagę użytkownika tam, gdzie to ważne, czy go rozpraszają?

9. Zapewnij skuteczną obsługę błędów

W procesie tworzenia oprogramowania można śmiało używać kodów odpowiedzi (błędów). Dzięki temu zespół programistów może dowiedzieć się, co się dzieje. Gdy system jest wyłączony, kody już nie wystarczają.

Ponieważ błędy 404 i 500 są najbardziej powszechne, powinny być ostylowane i dawać użytkownikowi informację, że coś nie gra oraz możliwość powrotu na poprzednią stronę (za pomocą linka do strony głównej lub formularza kontaktowego). W przypadku innych błędów, użytkownik nie powinien widzieć pustej strony z informacją „przepraszamy, coś poszło nie tak” lub z kodem danego błędu. Tyle to on już wie. Użytkownik powinien otrzymać konkretne informacje: link, obietnicę, że zespół już się zajął problemem czy prośbę o przeładowanie lub ponowienie próby później.

Jeśli coś jest nie w porządku w formularzu, system powinien podpowiadać, które pole należy poprawić. Jeśli nie można ukończyć operacji, użytkownik musi otrzymać informację, dlaczego tak się dzieje. Jeśli coś pójdzie nie tak, powiedzcie o tym użytkownikowi i zaproponujcie rozwiązanie.

Ponadto, jeśli ktoś prowadzi stronę internetową na przykład w języku polskim, błędy w języku angielskim będą wyglądać dziwacznie. Użytkownik powinien uzyskać te informacje w prostej i estetycznej formie lub ewentualnie pod postacią gry (np. dinozaur w Google).

Pytania, które warto zadać:

  • Czy system radzi sobie z błędami?
  • Czy strony błędów 500 i 404 zawierają informacje przyjazne użytkownikowi?
  • Czy użytkownik widzi konstruktywne komunikaty o błędach?
  • Czy wiadomości o błędach są widoczne wystarczają długo, by użytkownk mógł się z nimi zapoznać?

10. Zadbaj o pomoc i dokumentację

Szczerze mówiąc, bez podstrony poświęconej najczęściej zadawanym pytaniom, użytkownik może odczuwać frustrację. Nie należy wymagać od niego, by czytał całą dokumentację, chcąc skorzystać z systemu czy aplikacji, ale powinien mieć dostęp do podstrony, na której znajdzie wszystkie dodatkowe informacje i objaśnienia – na wszelki wypadek.

Sprawdzajcie, czy łatwo można uzyskać wskazówki, czy użytkownik, który nie zna systemu, będzie potrzebował dużo czasu, aby się w nim odnaleźć bądź czy zacznie z niego korzystać przy pomocy komunikatów wyświetlanych w wyskakującym oknie. Taka doraźna pomoc powinna zawsze być kontekstowa i dostarczać informacje potrzebne jedynie w tej konkretnej sytuacji.

Upewnijcie się, czy wszystkie ikonki pomocy prowadzą tam, gdzie powinny i czy pojawia się w nich tekst wtedy, gdy powinien. Przekonajcie się – jako pierwsi użytkownicy – czy możecie korzystać z systemu dzięki temu, że Was nawiguje oraz czy w razie kłopotów znajdziecie wsparcie w zakładce Wyszukiwanie oraz/lub FAQ czy Pomoc. Jeśli korzystanie z systemu wymaga, by te podstrony były stale otwarte, to znaczy, że coś nie gra.

Pytania, które warto zadać:

  • Jak długo zajmuje użytkownik nauka tego, jak korzystać z systemu?
  • Jak trudno/łatwo znaleźć pomoc?
  • Czy jakieś procesy wymagają dodatkowej pomocy?
  • Czy FAQ/ Często zadawane pytania są pomocne i zrozumiałe?

Na koniec…

W moim przekonaniu my, testerzy, mamy zobowiązania wobec użytkownika (i naszych klientów, bo to dla nich dbamy o wysoką jakość naszego produktu). Testowanie nie polega tylko na upewnieniu się, czy wszystko co do piksela zgadza się z projektem i sprawdzeniu – krok po kroku – czy działa tak, jak na schematach. To jest niewątpliwie najważniejsze, ale zwykle projekty, makiety i wymagania nie obejmują 100% systemu. Jeśli to możliwe, dlaczego nie poświęcić czasu na upewnienie się, że użytkownik będzie miał dobre doświadczenia z systemem przy użyciu 10 wymienionych wyżej heurystyk?

Czy zawsze zostaniecie wysłuchani i czy Wasze sugestie zostaną wdrożone? Nie, ale mogą stać się impulsem do omówienia pewnych elementów i być może wprowadzenia zmian. Nie na wszystko znajdziecie czas i nie osiągniecie doskonałości, ale warto próbować. To też się liczy! Każda dyskusja i pomysł czegoś nas uczą i pozwalają nam następnym razem lepiej wykonać dane zadanie.

Najnowsze wpisy