Strona główna » Projektowanie interakcji

Komunikaty błędów. Dobre praktyki komunikacji z użytkownikiem

29 listopada 2011 napisała Ewa [ 1 odpowiedź ] Drukuj wpis

Sensowne i zrozumiałe komunikaty błędów są bardzo istotnym składnikiem dobrego user experience. Źle opracowane irytują, frustrują i zniechęcają do korzystania z danego produktu, aplikacji czy strony www. Z kolei te uczucia rzucają się cieniem na reputacji systemu. Nierzadko, mogą pociągać za sobą znaczące koszty obsługi technicznej i telefonów od zdezorientowanych klientów – koszty, których można uniknąć.

Generalna zasada mówi: lepiej zapobiegać niż leczyć. Oznacza to, że wszędzie tam, gdzie to możliwe należy przewidywać potencjalne błędy i projektować tak, aby można było ich uniknąć. Jeśli jednak są nieuniknione, należy zadbać o ich przyjazność i użyteczność.

Kiedy używać?

Komunikaty błędów służą poinformowaniu użytkownika o problemie, który wystąpił, czyli o wydarzeniu przeszłym. W każdej innej sytuacji nie mamy do czynienia z błędem. Jeśli na przykład chcemy uprzedzić użytkownika o potencjalnym problemie, który dopiero może wystąpić w przyszłości, nie będziemy mówić o błędzie, ale o ostrzeżeniu (ale to już materiał na osobny artykuł).

Formy komunikatów błędów

Okno modalne (a. k. a. modal)

Stosujemy je wówczas, gdy wymagana jest bezzwłoczna reakcja na błąd i od niej uzależniona jest dalsze działanie. Jest to najlepszy wybór, jeśli potrzebne jest natychmiastowe przykucie ludzkiej uwagi. Zdecydowanie jednak nie należy nadużywać modali, jeśli można uniknąć wzywania użytkownika do tablicy.

Typowy modal z błędem (Windows 7)

Typowy modal z błędem (Windows 7)

Modal z błędem w aplikacji internetowej

Modal z błędem w aplikacji internetowej

Komunikaty kontekstowe (w treści lub w postaci chmurek)

Najczęściej są wykorzystywane przy formularzach czy wszędzie tam, gdzie użytkownik wprowadza jakieś informacje. Mogą być wywoływane w momencie próby przesłania formularza lub też na bieżąco wraz z przechodzeniem przez jego pola. Charakterystyczne jest to, że jednocześnie możemy pokazać kilka komunikatów.

Przykład kontekstowych komunikatów błędów w formularzu rejestracji na Twitter.com

Przykład kontekstowych komunikatów błędów w formularzu rejestracji na Twitter.com

Przykład kontekstowych komunikatów błędów w formularzu rejestracji na MailChimp.com

Przykład kontekstowych komunikatów błędów w formularzu rejestracji na MailChimp.com

Komunikat błędu w chmurce (Windows 7)

Komunikat błędu w chmurce (Windows 7)

Komunikat błędu w chmurce w serwisie WWW

Komunikat błędu w chmurce w serwisie WWW

Strony błędu

Służą do komunikowania błędów w działaniu serwisu www, np. nieistniejąca strona lub przeciążony serwer. Zainteresowanych odsyłam do artykułu Basi o stronach błędów.

Strona błędu w jednym z serwisów Ikea

Strona błędu w jednym z serwisów Ikea

Elementy konieczne dobrego komunikatu błędu

Odpowiedni komunikat błędu powinien zawierać następujące elementy:

  • powiadomienie o wystąpieniu problemu,
  • wyjaśnienie, co go spowodowało (językiem przystępnym dla użytkownika i zrozumiałym z jego perspektywy),
  • wskazówki, jak się zachować i jak ów błąd naprawić.

Jednym z grzechów głównych komunikatów błędów jest ich programistyczny język i perspektywa systemu. Dobry komunikat musi mówić ludzkim językiem. Zaistniały problem należy przedstawić z punktu widzenia celów i potrzeb użytkownika, a nie działania systemu.

Ponadto powinniśmy unikać używania negatywnych, nacechowanych emocjonalnie określeń i przede wszystkim pod żadnym pozorem nie próbować zrzucać winy na użytkownika. „Podałeś błędne hasło” lepiej przeformułować na „Podane hasło jest nieprawidłowe”.

Krótkie rady na wynos

Przemyślane i sensowne komunikowanie błędów jest integralnym elementem budowania dobrego user experience. Jak to zrobić?

  • Używać komunikatów błędów stosownie z ich przeznaczeniem (czyli do informowania o zaistniałym, faktycznym problemie).
  • Zadbać o to, by występowały rzadko. Jeśli tylko to możliwe, dążyć do uniknięcia błędu.
  • Upewnić się, że komunikat wyjaśnia problem, jego genezę oraz poddaje drogę jego rozwiązania.
  • Tworzyć odpowiednie komunikaty, krótkie, konkretne i zrozumiałe.
  • Formułować je z perspektywy użytkownika, nie systemu.
  • Wybierać taką ich formę, aby jak najmniej przeszkadzały użytkownikowi w realizacji jego celów.

 

Autorka

Ewa Sobula

www: http://www.linkedin.com/pub/ewa-sobula/30/407/694
UX designer w Sabre Airline Solutions. Umiejętności badawcze i analityczne rozwijała na socjologii, by lepiej rozumieć użytkowników. Równolegle uczyła się tworzenia serwisów internetowych, by poznać technologiczne możliwości i ograniczenia. Teraz z przyjemnością łączy te kompetencje projektując i badając serwisy. Czytaj więcej
Tagi: , , ,
  • Wojtek

    modal? poprawnie powinno byc „modal box” badz „modal window”, patrzac od strony programistycznej jak i technicznej