Komunikaty dla użytkownika
Powstało już wiele artykułów mówiących o tym jak komunikować błędy by były przyjaźniejsze dla użytkownika. Większość wytycznych do konstruowania komunikatów błędów odnosi się do zasad:
- opisania błędu jako wyniku nieprawidłowości systemu, nie użytkownika,
- używania naturalnego języka,
- komunikowania błędów za pomocą czerwonego koloru,
- komunikowania błędów w jednolity sposób za pomocą jednego koloru oraz miejsca wyświetlania,
- podpowiadania rozwiązania błędu, kierowania użytkownika na akcje, które może wykonać,
- unikania przedstawiania błędów na wyskakujących popupach.
Są to powszechne zasady i każdy początkujący projektant powinien się z nimi zapoznać. Coraz więcej stron stosuje dobre praktyki komunikacji błędów, choć zdarzają się jeszcze takie przypadki:
Jednak komunikacja systemu z użytkownikiem nie kończy się na wyświetlaniu błędów. Odbywa się na wielu innych płaszczyznach, o których należy pamiętać oddając prototyp do działu wdrożenia. Informacje jakie przekazujemy użytkownikowi to np. wiadomości e-mail potwierdzające założenie konta, wiadomości o zrealizowanej przesyłce, potwierdzenie zapłaty, wiadomości potwierdzające wykonanie akcji, zapytania o potwierdzenie akcji oraz wiele innych specyficznych dla danej strony.
Projektując stronę www, sklep czy inny system należy zidentyfikować punkty styku komunikacji między systemem, a użytkownikiem. Dlaczego to takie ważne? Można wyobrazić sobie pracę programisty, który musi przenieść zaprojektowane funkcjonalności na działający produkt. Ma mnóstwo pracy i jeszcze więcej problemów programistycznych do rozwiązania. Dlatego nie jest jego zadaniem definiowanie wiadomości dla użytkownika. Jeśli my projektanci nie przekażemy konkretnych treści, programista może wstawić przykładowe. Takie treści mogą być niedostosowane do stylu naszego produktu, trudne do zrozumienia lub po prostu typowo systemowe, często powodując frustrację i niezrozumienie. Na przykład, projektując system dla młodszych użytkowników musimy pamiętać, aby treści wyświetlane dla nich były proste oraz żeby były dopasowane do ich systemu mentalnego.
Jak odkrywamy miejsca komunikacji z użytkownikiem? Kiedy mamy już persony, mapy empatii, cel i funkcjonalności naszego produktu zaczynamy określać przykładowe scenariusze. Podczas projektowania struktury, scenariuszy, diagramów przepływów możemy mapować momenty naszej komunikacji z użytkownikiem. Zdarza się, że już na poziomie tworzenia customer journey jesteśmy w stanie zaznaczyć niektóre miejsca, gdzie będziemy musieli komunikować się z użytkownikiem. Takie miejsca notujemy i wracamy do nich w fazie projektowania.
Reasumując, przemyślenie i stworzenie komunikatów przez projektanta niweluje nieporozumienia oraz przyspiesza pracę programistów. W rezultacie nasz produkt jest dopracowany na każdym poziomie, a korzystanie z niego jest przyjemne dla jego użytkowników.
Źródła:
http://uxwatch.pl/jak-komunikowac-bledy/
Szernę u Siebie ale mam też prośbę – powiększcie czcionkę bo źle się to czyta na desktopach 🙁
Według mnie kluczowe jest dopasowanie takiego komunikatu do stylu strony. Wtedy nawet dzięki niemu możemy zostawić pozytywne wspomnienia u odbiorcy 😉 Swoją drogą pamiętam, że kiedyś ciekawą stronę z błędem 404 miał serwis demotywatory.pl.