W świecie produktów cyfrowych komunikaty o błędach i niepowodzeniach są nieodłącznym elementem interakcji użytkownika z oprogramowaniem. Takie treści mogą znacząco wpłynąć na odbiór danej aplikacji. Dlatego zrozumienie jak tworzyć komunikaty, jest kluczowe nie tylko dla projektantów, ale również programistów.
Kiedy użytkownik napotyka problem, przepływ pracy zostaje przerwany. Warto w tej sytuacji pokazać, że problem jest łatwy do rozwiązania. Zrozumiała wiadomość o błędzie może znacząco zmniejszyć poziom frustracji. Jeśli pomożemy użytkownikom zrozumieć, co się stało i zaoferujemy konkretne kroki do naprawienia problemu, użytkownicy nie będą tracić czasu i skupią się na swoim założonym celu. Chcemy także, aby użytkownicy byli świadomi, że dany proces jest prosty i szybki, a dzięki efektywnym komunikatom usprawnimy interakcję użytkownika z interfejsem.
Treści, które pokazują, że twórcy produktu dbają o użytkowników i ich doświadczenia, budują relacje. Jeśli użytkownicy widzą, że ich problemy są traktowane poważnie, są bardziej skłonni wrócić do usługi w przyszłości. Dobrze przemyślany produkt przekłada się na pozytywne opinie. W tym artykule postaram się przedstawić strategie i najlepsze praktyki, które mogą pomóc w załagodzeniu negatywnego wpływu błędów na użytkowników.
Lepiej zapobiegać niż leczyć
Najlepszym podejściem jest zminimalizowanie liczby błędów, które mogą napotkać użytkownicy. Zapobieganie będzie bardziej efektywne niż reakcja na problemy, dlatego warto zainwestować czas i zasoby na etapie projektowania oraz testowania.
Intuicyjne interfejsy zmniejszają ryzyko popełnienia błędów przez użytkowników. Wskazówki wizualne, takie jak ikony i etykiety, pomagają użytkownikom zrozumieć, jakie działania są możliwe.
Na etapie projektowania warto rozważyć elementy, które przybliżę niżej.
Onboarding
Użytkownicy, którzy są dobrze poinformowani o tym, jak korzystać z aplikacji, popełniają mniej błędów. Krótkie przewodniki, samouczki i podpowiedzi mogą znacząco poprawić zrozumienie oraz obsługę systemu.
Ograniczenia
Ograniczenia pomagają użytkownikom wprowadzać tylko poprawne dane i wykonywać tylko dopuszczalne działania. Dzięki nim minimalizujemy liczbę błędów, które użytkownicy mogą popełnić.
Automatyczne sugerowanie i poprawianie
Systemy mogą automatycznie sugerować hasła lub poprawiać drobne błędy. Jest to szczególnie użyteczne i poprawia interakcję użytkownika z produktem cyfrowym.
Zapobieganie błędom jest niezwykle ważne, ale w rzeczywistości nie da się całkowicie wyeliminować ryzyka ich wystąpienia. Niestety, błędy to nieunikniona część interakcji użytkownika z oprogramowaniem. Ważne jest, aby w momencie ich wystąpienia odpowiednio pomóc użytkownikowi.
Zrozumiały komunikat o błędzie, czyli jaki?
Właściwe ujęcie problemu jest kluczem do sukcesu. Użytkownik musi zrozumieć, co poszło nie tak. Przekaz powinien być zwięzły, ale musi też zawierać wszystkie niezbędne informacje do rozwiązania problemu. Komunikaty o błędach to elementy, których użytkownicy nie lubią. Niewłaściwy tekst może zepsuć pozytywne wrażenia.
Dobrze zaprojektowany komunikat powinien zawierać:
- ujęcie problemu,
- informację, dlaczego dany problem wystąpił,
- informację, jak dany problem wpływa na użytkownika i jego dalsze działanie,
- instrukcję, jak rozwiązać problem i co można zrobić, aby problem nie wystąpił ponownie.
Najważniejsze zasady przy projektowaniu komunikatów o błędach
W dalszej części znajdziecie informacje dotyczące poprawnego projektowania komunikatów o błędach.
Nie należy obwiniać użytkownika
Obwinianie użytkownika za błąd może prowadzić do jeszcze większej frustracji i zniechęcenia. Projektowane treści powinny być neutralne i skoncentrowane na rozwiązaniu problemu. Nie zapominajmy o uprzejmości i empatii.
Pamiętajmy też, aby nie atakować użytkowników wielkimi literami czy wykrzyknikami. Na przykład, jeśli osoba wypełnia formularz i zapomni wpisać swój adres e-mail, nie stosujmy agresywnych wiadomości „Błąd formularza!” czy „POLE WYMAGANE”. Spróbujmy użyć łagodniejszego komunikatu: „Uzupełnij pole e-mail”. Taki komunikat jest bardziej zrozumiały i pomaga użytkownikowi skupić się na poprawieniu błędu bez dodatkowego stresu.
Konkretnie i na temat
Komunikaty o błędach powinny dokładnie informować użytkownika o problemie. Ogólnikowe wiadomości nie dostarczają użytkownikom wystarczającej ilości informacji do podjęcia dalszych kroków. Unikajmy ogólnych stwierdzeń na rzecz bardziej szczegółowych opisów problemu, które pomogą zrozumieć, co poszło nie tak.
Pierwszy komunikat jest zbyt ogólny, użytkownik nie ma pojęcia, gdzie tkwi problem ani co powinien zrobić dalej. Używajmy bardziej szczegółowych komunikatów, które dają jasne wskazówki dotyczące problemu oraz kroków, które można podjąć, aby go rozwiązać.
Prosty język, bez żargonu technicznego
Piszmy w sposób zrozumiały dla standardowego użytkownika i unikajmy technicznego żargonu. Bardzo ważna kwestą jest projektowanie komunikatów, które każdy użytkownik będzie w stanie zrozumieć. Nie używajmy skrótów ani terminów zrozumiałych tylko dla programistów.
Pamiętajmy, że prosty język w części odpowiada za dostępność cyfrową. Więcej o prostym języku przeczytamy na stronie rządowej.
W miarę możliwości unikajmy zbyt ogólnych stwierdzeń i tajemniczych liczb, np. błąd 1020.
Jeśli koniecznie musimy użyć kodu błędu, to możemy zawrzeć go w komunikacie. Ważne jest, aby wyjaśnić, co to dokładnie oznacza dla użytkownika.
404: Przecież to jasne!
Także w przypadku znanych kodów błędów jakimi są: „Kod 404: Strona nie istnieje” czy „Kod 500: Wewnętrzny błąd serwera”, powinniśmy pamiętać o użytkownikach, którzy mają różny poziom znajomości technologii. Lepiej nie zakładać z góry, że każdy zrozumie, co oznaczają takie kody.
Zamiast: „Błąd 404: Nie znaleziono strony”
Użyjmy: „Nie możemy znaleźć strony, której szukasz. Sprawdź, czy adres URL jest poprawny, lub wróć na stronę główną”
Zamiast: „Błąd 500: Wewnętrzny błąd serwera”
Użyjmy: „Wystąpił problem z naszym serwerem. Prosimy spróbować ponownie za kilka minut. Jeśli problem będzie się powtarzał, skontaktuj się z nami pod adresem [email protected]”
Nasze komunikaty powinny być napisane w sposób zrozumiały dla wszystkich, bez względu na ich wiedzę techniczną.
Co w przypadku, gdy grupa docelowa ma wąską specjalizacje i specyficzne potrzeby?
W przypadku aplikacji skierowanych do specjalistycznych grup użytkowników, takich jak lekarze, unikanie terminologii branżowej może być wyzwaniem. Często użytkownicy w takich dziedzinach są przyzwyczajeni do specyficznych terminów i oczekują, że komunikaty będą zawierały język branżowy.
Używajmy jednak terminologii zgodnie z kontekstem aplikacji i poziomem zaawansowania użytkowników. Upewnijmy się, że komunikaty są zgodne z powszechnie używanym językiem w danej dziedzinie. Unikajmy skrótów i terminów, które mogą być mylące, a jeśli musimy użyć specyficznego języka, to zapewnijmy wyjaśnienie lub definicję tam, gdzie to możliwe.
Negatywne słowa wyrzućmy do kosza
Treści powinny być jak najbardziej neutralne. Negatywne słowa i zwroty mogą tylko pogorszyć sytuację, zwiększając podenerwowanie użytkownika. Unikajmy negatywnych terminów takich jak „zły”, „krytyczny”, czy „niedopuszczalny”, a także żartów, slangu i skrótów, które mogą być źle zrozumiane.
Tak więc – zamiast pisać „Krytyczny błąd!”, opiszmy konkretnie przyczynę: „Wystąpił problem z operacją. Proszę spróbować ponownie lub skontaktować się z pomocą techniczną”. Negatywne zwroty zniechęcają, mogą także wywołać poczucie winy lub niekompetencji.
Żarty i slang mogą być mylące i nieprofesjonalne. Zamiast tego, używajmy jasnych i profesjonalnych komunikatów.
Wsparcie użytkownika
Komunikaty o błędach powinny nie tylko informować o problemie, ale również sugerować, co użytkownik może zrobić, aby go rozwiązać. W ten sposób pomagamy użytkownikowi szybko wrócić do działania.
Jeśli komunikat o błędzie nie jest wystarczająco zrozumiały lub problem nie został rozwiązany, użytkownicy powinni mieć możliwość skontaktowania się z pomocą techniczną.
Komunikat powinien być widoczny
Komunikaty o błędach powinny być łatwe do zauważenia i czytelne. Używanie wyróżniających się kolorów oraz odpowiedniego umiejscowienia na stronie pomaga w skutecznym przekazywaniu informacji. Używajmy kolorów, które wyraźnie odróżniają się od reszty interfejsu. Czerwony i pomarańczowy są powszechnie używane do wyróżniania błędów, ponieważ przyciągają uwagę i są łatwo zauważalne. Aby komunikat był czytelny, zapewnijmy odpowiedni kontrast między tekstem a tłem. Na przykład, czerwony tekst na białym tle lub biały tekst na czerwonym tle.
Umieść komunikaty o błędach w miejscach, gdzie użytkownik na pewno je zauważy. Najlepiej w pobliżu elementu, który spowodował błąd. Złym przykładem będzie umieszczenie komunikatu o błędzie na dole strony, gdzie użytkownik może go łatwo przegapić. Najlepiej, gdy komunikat pojawi się bezpośrednio obok pola formularza, w którym wystąpił błąd.
Dla błędów globalnych warto umieścić komunikat w stałym miejscu, na przykład na górze strony, gdzie będzie widoczny niezależnie od przewijania. Zamiast wyświetlać komunikat o błędzie w losowym miejscu na stronie, lepiej wyświetlić komunikat w górnym pasku lub na środku ekranu.
Co jeśli czerwień jest kolorem głównym lub drugorzędnym w identyfikacji wizualnej?
Jeśli czerwień jest dominującym kolorem w identyfikacji wizualnej aplikacji, należy znaleźć inny sposób, aby komunikaty o błędach nadal wyróżniały się i były czytelne. Musimy pamiętać o tym, żeby nie łamać spójności designu.
W tej sytuacji możemy dodać kolory uzupełniające, takie jak żółty lub pomarańczowy. Innym rozwiązaniem jest użycie ikon ostrzegawczych, które wskazują na błąd.
Przykładem takiego podejście jest aplikacja Crane, która używa pomarańczowego koloru do wyróżnienia błędów. Kolor czerwony jest kolorem drugorzędnym, więc czerwony błąd w tym przypadku nie wyróżniałby się wystarczająco od otaczającego interfejsu użytkownika i mógłby zostać błędnie odczytany.
Czas wyświetlania komunikatu
Ważnym aspektem jest czas wyświetlania danego komunikatu. Informacje o błędach powinny być obecne na ekranie wystarczająco długo, aby użytkownik mógł je spokojnie przeczytać. W przypadku poważnych błędów, komunikaty powinny pozostawać widoczne aż do momentu, gdy problem zostanie naprawiony.
Nie należy wyświetlać błędów zbyt wcześnie
Prezentowanie błędów zbyt wcześnie może wywoływać u użytkowników większą frustrację i dezorientację. Aby tego uniknąć, warto stosować strategie takie jak:
- walidacja danych w czasie rzeczywistym,
- opóźnione wyświetlanie komunikatów,
- jasne podpowiedzi.
Wprowadzenie technik stopniowego ujawniania informacji jest skuteczną metodą minimalizowania negatywnych doświadczeń związanych z błędami. Polega ono na dostarczaniu użytkownikom tylko tych informacji, które są im potrzebne w danym momencie. Regularne testowanie interfejsu z rzeczywistymi użytkownikami pozwala na identyfikację momentów, w których błędy są wyświetlane przedwcześnie.
Należy unikać wyświetlania komunikatów o błędach, dopóki użytkownik nie zakończy wypełniania danego pola i nie przejdzie do następnego. Wyświetlanie komunikatów o błędach w trakcie wpisywania może sprawiać wrażenie nieuzasadnionej reprymendy.
Spójność
Używaj tych samych terminów i fraz w całej aplikacji, aby unikać zamieszania. Jeśli w jednym miejscu używasz określenia „hasło”, nie zamieniaj go w innym miejscu na „klucz dostępu”. Utrzymywanie stałej terminologii pomaga użytkownikom szybko zrozumieć komunikat bez dodatkowego zastanawiania się nad jego znaczeniem.
Zachowujmy także jednolite formatowanie tekstu w komunikatach o błędach. Dotyczy to rozmiaru czcionki, kolorów, pogrubień, kursywy itp. Spójne formatowanie sprawia, że komunikaty są łatwiejsze do rozpoznania i zrozumienia. Zachowanie jednolitej terminologii i układu wizualnego wzmacnia także profesjonalny i przemyślany wizerunek aplikacji.
Testy
Obserwuj, jak użytkownicy reagują na komunikaty. Regularnie przeglądaj i aktualizuj komunikaty o błędach na podstawie nowych informacji i feedbacku. Taki proces powinien być kontynuowany przez cały cykl życia produktu, aby dostosować komunikaty do zmieniających się potrzeb i oczekiwań użytkowników.
Nie tylko błędy
W niektórych sytuacjach istotne jest, aby użytkownik otrzymał potwierdzenie, że dana operacja została zakończona pomyślnie i wszystko poszło zgodnie z planem. Dotyczy to zwłaszcza procesów, w których użytkownicy mogą mieć wątpliwości co do statusu wykonanej czynności, takich jak składanie zamówień czy wysyłanie formularzy.
Humor w komunikatach
Humor w komunikatach o błędach to temat, który budzi wiele kontrowersji i różnorodnych opinii. Może on mieć zarówno pozytywne, jak i negatywne skutki, w zależności od kontekstu i sposobu jego użycia.
Odpowiednio użyty humor może pomóc w budowaniu pozytywnego wrażenia o marce i uczynić interakcje z aplikacją bardziej przyjemnymi. Pamiętajmy, że różni ludzie mogą interpretować humor na różne sposoby. Co dla jednej osoby może być zabawne, dla innej może być nieodpowiednie lub mylące.
Kiedy stosować humor w komunikatach o błędach?
Humor może być stosowany w mniej krytycznych sytuacjach, gdzie błąd nie wpływa znacząco na funkcjonalność lub bezpieczeństwo aplikacji. Przykładem mogą być komunikaty dotyczące drobnych problemów, takich jak chwilowy brak połączenia z Internetem czy brak treści pod danym linkiem.
Poniżej mamy do czynienia z komunikatem na platformie Twitch. Wiadomość jest zgodna z wizerunkiem marki, odrobinę humorystyczna, ale nie przesadnie urocza i irytująca.
Jeśli marka jest znana z luźnego i przyjaznego tonu, humor może być spójny z jej wizerunkiem i dobrze odebrany przez użytkowników. Zanim wprowadzimy humorystyczne komunikaty o błędach, warto przetestować je na grupie docelowej i zebrać feedback, aby upewnić się, że są one dobrze przyjęte i zrozumiałe.
Lista kontrolna
Projektując komunikaty, warto prowadzić arkusz lub inny rodzaj dokumentu, w którym będziemy dokumentowali teksty i zmiany. Warto numerować błędy, dzięki czemu łatwiej odnajdziemy się w treściach aplikacji. Idealnym rozwiązaniem jest opracowanie listy kontrolnej, na którą możemy spoglądać, pisząc komunikaty. Skompletowanie najlepszych praktyk i podzielenie się z zespołem będzie bardzo wartościowe i ułatwi pracę.
Poniżej przedstawiam przykładową listę kontrolną.
- Opisz problem prostym i zrozumiałym językiem. Używaj pełnych zdań.
- Wyjaśnij, co spowodowało problem.
- Unikaj zbyt ogólnych stwierdzeń.
- Wyjaśnij rozwiązanie problemu. Jeśli wymaga ono kilku kroków, podaj link do strony pomocy, która zawiera szczegółowe instrukcje.
- Oferuj wsparcie lub kontakt z pomocą techniczną.
- Unikaj technicznej terminologii, pisz głosem użytkownika.
- Używaj przyjaznych i pełnych zrozumienia komunikatów.
- Nie obwiniaj użytkownika za błąd. Unikaj tekstu zapisanego wielkimi literami i wykrzykników.
- Sprawdź czy komunikat jest łatwo zauważalny.
- Projektuj treści zgodne z wartościami marki i dostosowane do grupy docelowej. Pamiętaj o odpowiednim stylu i formie komunikacji.
- Sprawdź, czy komunikaty w produkcie są ze sobą spójne nie tylko pod względem treści, ale także wizualnym.
W zależności od zapotrzebowania warto sporządzić własną listę, którą będziemy wykorzystywać na potrzeby danego klienta. Listę powinniśmy również wzbogacić o przykłady tekstów wykorzystywanych w naszym produkcie.
Podsumowanie
W artykule omówiliśmy szereg zasad, które warto stosować przy tworzeniu komunikatów o błędach. Odpowiednio skonstruowane treści nie tylko informują o problemie, ale również prowadzą użytkownika do rozwiązania i minimalizują frustrację. Efektywne komunikaty o błędach mogą także wzmacniać pozytywne relacje między użytkownikami a marką.
Pamiętajmy również o integracji tekstów z UI tak wcześnie jak to możliwe. Pozwala to na stworzenie spójnego i zintegrowanego doświadczenia. Gdy teksty są projektowane równocześnie z elementami UI, można lepiej dostosować ich formatowanie i sposób wyświetlania. Ważnym aspektem jest także testowanie komunikatów w rzeczywistych warunkach oraz regularne aktualizowanie ich w oparciu o feedback od użytkowników. Dzięki temu można dostosować nasze treści do potrzeb oraz oczekiwań odbiorców.
Bibliografia
- Error-Message Guidelines (nngroup.com)
- Hostile Patterns in Error Messages (nngroup.com)
- The ultimate error message UX writing guide (plus examples) (theuxgal.com)
- Prosty język – Dostępność cyfrowa – Portal Gov.pl (www.gov.pl)
- Poznaj 10 zasad prostego języka w Centralnym Ośrodku Informatyki (www.gov.pl)
- książka „UX writing. Moc języka w produktach cyfrowych”, Wojciech Aleksander
- How to Write Error Messages: Faster, Stronger, Better – Technical Writing Tools (ihearttechnicalwriting.com)
- Tips for UX Writing – UX Magazine
- How to Design Inline Editing and Validation in Tables – UX Design World (uxdworld.com)
Bardzo dobrze, że taki artykuł powstał. Każdy deweloper – nie tylko frontendu – powinien znać te podstawowe reguły.