Heurystyka, to według Słownika Języka Polskiego między innymi umiejętność wykrywania nowych faktów i związków między faktami (a zwłaszcza stawiania hipotez), prowadzącego do poznania nowych prawd. Nielsen - jeden z najbardziej znanych specjalistów w dziedzinie użyteczności pisze o heurystykach w kontekście użyteczności, podając zbiór uniwersalnych jego zdaniem zasad, którymi rządzi się projektowanie użytecznych interfejsów.
Czytelność stanu systemu.
Co aktualnie dzieje się w systemie? Na bieżąco należy informować użytkownika poprzez odpowiednią informację zwrotną, przesyłaną w rozsądnym czasie. W jakiej części aplikacji czy fotografii znalazł się użytkownik? Jeśli po przyciśnięciu “wyślij dokument” pojawia się klepsydra z piaskiem, wiemy już, że system pracuje. Umieszczenie preloadera na stronie www informuje użytkownika o tym, że animacja flash właśnie jest ładowana z sieci.
Adekwatność systemu do świata rzeczywistego.
Należy mówić naturalnym językiem użytkownika. Użycie konwencji językowych świata rzeczywistego jest bardziej zrozumiałe, niż komunikaty zorientowane systemowo. Interfejs użytkownika został stworzony po to, żeby tłumaczyć zero-jedynkowe ciągi na przyswajalne dla przeciętnego odbiorcy komunikaty. Tymczasem, użycie żargonu znanego tylko programistom czy projektantom systemu nie jest dla zwykłego użytkownika bardziej zrozumiałe niż zera i jedynki w tajemniczych “czarnych oknach”. Bezwzględnie należy używać prostego języka, bez specjalistycznych określeń.
Kontrola i wolność wyboru dla użytkowników.
Należy zapewnić możliwość cofnięcia i powtórzenia, a także przerwanie wykonywania wykonanych operacji – użytkownicy często wybierają określone funkcje nieświadomie bądź przez pomyłkę. Aplikacja bądź serwis WWW realizują rozmaite funkcje, np. polegające na wprowadzaniu i modyfikacji danych, wykonywaniu kalkulacji. Użytkownik często przypadkiem wybiera tę a nie inną operację, należy więc umożliwić mu modyfikację raz wprowadzonych informacji, a także rezygnację wykonywania dalszych kroków. Nie powinno się kazać internaucie korzystać z przycisku wstecz w przeglądarce.
Spójność i standaryzacja.
Należy dbać o jednolitość konwencji – nie powinno się zmuszać użytkowników do zastanawiania się nad tym, czy podobne określenia na pewno oznaczają to samo. Warto sięgać po sprawdzone wzorce i konsekwentnie stosować w całym projekcie. Jeżeli trudno o oryginalny czytelny symbol danej funkcji, należy wykorzystać najczęściej stosowany w danej branży.
Zapobieganie powstawaniu błędów.
Czytelny komunikat o błędzie jest dobry, ale projektowanie z myślą o przeciwdziałaniu powstaniu błędu - jeszcze lepsze. Generalnie zamiast tworzyć obszerne komunikaty o błędach, lepiej stworzyć takie warunki, by błędy te występowały jak najrzadziej. W przypadku stron internetowych należy opracować automatyczne narzędzia do wyszukiwania niedziałających linków. Komunikat o błędzie typu „terror 404” potrafi skutecznie zniechęcić każdego użytkownika.
Rozpoznawanie, a nie przypominanie.
Nie należy kazać użytkownikowi zapamiętywać wprowadzonych wcześniej informacji, czy wybranych opcji. Powinny być pokazywane na bieżąco, albo wyraźnie oznaczony dostęp do nich. Nie należy obarczać użytkownika pamięci danymi, które wprowadził, czy też wybranymi parametrami. Jeżeli ilość wprowadzonych danych to umożliwia, powinny być wyświetlone na ekranie przez cały czas ich wykorzystywania. Jeżeli mogą przydać się później, albo jest ich zbyt wiele, wyraźnie powinien być oznaczony (przycisk, odnośnik hipertekstowy) dostęp do wprowadzonych informacji i wybranych parametrów.
Elastyczność i efektywność użycia.
System powinien być wyposażony w dyskretne wspomaganie interakcji, umożliwiające doświadczonym użytkownikom przyspieszanie często powtarzanych operacji. Nawet mało obyci użytkownicy w miarę nabierania doświadczeń będą chcieli skrócić sobie wykonywanie często powtarzanych operacji. Można umożliwić im to poprzez stosowanie skrótów czy konfigurowalnych stron typu “moje konta”, “moja strona startowa”.
Należy pozbyć się tendencji do wyposażania okien dialogowych interfejsu w elementy nie komunikujące adekwatnej i potrzebnej informacji. Odciągają uwagę użytkownika od istotnego przekazu i pogarszają jego widoczność. Już pierwsza wizyta na witrynie Jakoba Nielsena utwierdza o głębokiej wierze autora heurystyk w powyższą zasadę. Należy przyznać, że oszczędność formy świetnie sprawdza się w systemach typowo informacyjnych, natomiast biorąc pod uwagę cel komunikacji marketingowej, trudno wyobrazić sobie współczesną witrynę promocyjną bez zawartości typu rich content.
Pomoc użytkownikom w rozpoznawaniu, diagnozowaniu i naprawie błędów.
Komunikaty o błędach powinny być wyrażone językiem naturalnym, bez zamieszczania kodów systemowych. Precyzyjnie należy wskazać problem i sugerować rozwiązanie.Wystąpił błąd nr 723. Aplikacja zostanie zamknięta. Co to znaczy? Obsługa błędów powinna być czytelna dla zwykłego użytkownika - nie może zawierać komunikatów zrozumiałych wyłącznie dla programisty. Jeżeli błąd został spowodowany działaniem użytkownika (np. niewłaściwa dla danej aplikacji konfiguracja systemu) – należy napisać o tym wyraźnie. Trzeba zasugerować, jakie konkretnie kroki może podjąć użytkownik, żeby usunąć problem we własnym zakresie – jeśli to możliwe.
Warto przemyśleć sposób informowania o awarii jako nietypowym (niepożądanym) stanie aplikacji. Czy na pewno politycznie jest powiedzieć, że wystąpił błąd, albo - jeszcze gorzej - jest on spowodowany działaniem Twojego klienta? Należy unikać sformułowań w tonie kategorycznym, raczej trzeba sugerować działanie. Jeżeli umożliwia to konstrukcja aplikacji, za zgodą użytkownika powinno się przeprowadzić pełną diagnozę ustawień które mogą powodować kłopoty, a następnie – skierować do odpowiedniego miejsca w systemie. Wzorem mogą być komunikaty systemu pomocy Max OS X - pod informacją, jakie czynności należy podjąć zwykle umieszczony jest odnośnik „otwórz dla mnie ustawienia”. Ważne jest, żeby komunikat o błędzie nie pozostawiał żadnych wątpliwości, że to od działania użytkownika zależy przywrócenie normalnego stanu rzeczy - np. poprzez wprowadzenie poprawnych danych do formularza. W przypadku rozbudowanych formularzy najlepiej już w trakcie wypełniania poinformować o zaobserwowanych błędach - jeszcze przed naciśnięciem przycisku typu „wyślij”. Ułatwia to wypełniającemu korektę danych. Ważne jest także komunikowanie od razu wszystkich błędów - często spotykanym błędem w sztuce jest informowanie tylko o pierwszym z serii. W takiej sytuacji użytkownik dowiaduje się o kolejnych już po wysłaniu wypełnionego formularza do systemu, kiedy to aplikacja ponownie przeładowuje dane i wyświetla następne komunikaty o problemach.
Pomoc i dokumentacja.
Najlepszy system to taki, który nie potrzebuje dokumentacji, ale dostarczenie systemu pomocy i właściwe udokumentowanie może okazać się niezbędne. Każda informacja tego rodzaju winna być łatwa w przeglądaniu i przeszukiwaniu, skupiona na zadaniach wykonywanych przez użytkownika, zawierać konkretne rozwiązania. A także - być zwarta w formie. Użytkownicy rzadko poświęcają czas na czytanie pomocy systemowej, czy dokumentacji. Jeżeli jednak - zmuszeni do tego - skorzystają z dostępnych podpowiedzi, wskazane jest, żeby mieli możliwość szybkiego odnalezienia interesującego ich tematu. Dlatego też centrum pomocy powinno być zorientowane kontekstowo, czyli wyświetlać informacje na temat aktualnie wykonywanych zadań. Spis treści i ewentualnie index pomocy muszą być rzecz jasna dostępne na życzenie.
Brak komentarzy:
Prześlij komentarz