Gdy ktoś natrafia w Twoim formularzu na błąd, dzieli go jedna chwila od odejścia. Badania pokazują, że ponad 75% użytkowników porzuca formularze, gdy pojawiają się błędy, a oni nie potrafią ich od razu naprawić. To nie jest mały problem. To trzech na czterech potencjalnych klientów, leadów lub zapisów, którzy odchodzą. Różnica między zatrzymaniem a utratą często sprowadza się do jednej rzeczy: komunikatu o błędzie. Mylący komunikat odsyła ich precz. Jasny, pomocny komunikat sprowadza ich z powrotem i prowadzi do ukończenia formularza.
Komunikat o błędzie to szansa formularza, by poprowadzić kogoś do końca, gdy popełni błąd. Zły komunikat (niejasny, wskazujący winnego albo bezużyteczny) sprawia, że użytkownik czuje się zdezorientowany lub winny. Dobry komunikat mówi dokładnie, co poszło nie tak, dlaczego to ważne i jak to naprawić, prostym językiem. Ten artykuł pokazuje, jak pisać komunikaty o błędach, które działają, gdzie je umieszczać, by nie dało się ich przeoczyć, jaki ton naprawdę buduje zaufanie i dlaczego konkret decyduje o tym, czy ktoś porzuci formularz, czy go ukończy.
Co czyni komunikat o błędzie skutecznym
Skuteczny komunikat o błędzie robi trzy rzeczy. Po pierwsze, jasno mówi, co poszło nie tak. Nie "Nieprawidłowe dane". Zamiast tego: "Adresy e-mail potrzebują znaku @". Po drugie, wyjaśnia, dlaczego dane zostały odrzucone, jeśli to pomaga. "Hasła muszą mieć co najmniej 8 znaków, bo krótsze łatwiej złamać." Po trzecie, mówi użytkownikowi, co dokładnie zrobić dalej. "Wróć do pola hasła i dodaj co najmniej 4 znaki." Użytkownik zna już problem, rozumie, dlaczego jest ważny, i wie, jak go naprawić.
Ton komunikatu o błędzie ma większe znaczenie, niż większość osób sądzi. Komunikat, który brzmi gniewnie lub protekcjonalnie, sprawia, że użytkownik czuje się obwiniany. "Zapomniano o znaku @" brzmi jak wina użytkownika. "Adresy e-mail potrzebują znaku @" to ta sama informacja, ale bez obwiniania. Pomocny ton przyznaje, że zdarzył się błąd, nie sprawiając, że osoba czuje się z tym źle.
Czas i miejsce komunikatu o błędzie decydują o tym, czy użytkownik w ogóle go zobaczy. Komunikat, który pojawia się trzy ekrany niżej od pola, które go wywołało, łatwo przeoczyć. Komunikat obok problematycznego pola, w chwili gdy ktoś próbuje iść dalej, zmusza do zauważenia go i natychmiastowej poprawki.
Walidacja w trakcie wpisywania a walidacja przy wysyłaniu
Walidacja w trakcie wpisywania pokazuje komunikat o błędzie w chwili, gdy ktoś błędnie wypełni pole, jeszcze przed wysłaniem formularza. Pole hasła pokazuje błąd, gdy tylko wpisane hasło jest za krótkie. Pole e-mail pokazuje błąd, gdy tylko ktoś opuści pole bez znaku @. Informacja zwrotna w czasie rzeczywistym jest skuteczna, bo ludzie poprawiają błędy od razu, zamiast odkrywać je po wypełnieniu całego formularza.
Walidacja w trakcie wpisywania szczególnie dobrze robi jedno: buduje pewność. Gdy ktoś wpisze adres e-mail i zobaczy zielony znaczek, wie, że zrobił to dobrze. Idzie dalej bez wątpliwości. Bez takiego potwierdzenia zastanawia się, czy wpis był poprawny, i zaczyna się wahać.
Walidacja przy wysyłaniu to sytuacja, gdy ktoś kliknie "wyślij", a formularz sprawdza wszystkie pola naraz. Jeśli któreś pole ma błąd, na górze formularza pojawia się podsumowanie ze wszystkimi problemami, a każde pole z błędem jest podświetlone. Walidacja przy wysyłaniu wychwytuje błędy, które umknęły walidacji w trakcie wpisywania, i daje użytkownikom pełny obraz tego, co trzeba naprawić.
Najlepsze jest podejście łączone. Używaj walidacji w trakcie wpisywania dla pól, które można sprawdzić natychmiast (format e-maila, długość hasła, format kodu pocztowego). Używaj walidacji przy wysyłaniu jako ostatniej siatki bezpieczeństwa. Gdy ktoś kliknie "wyślij", a jakieś pole nadal ma błąd, pokaż od razu, co trzeba poprawić, zanim formularz zostanie wysłany.
Pisanie komunikatów o błędach konkretnych i wskazujących działanie
Konkretny komunikat mówi użytkownikowi dokładnie, na czym polega problem. Ogólnikowy zostawia go ze zgadywaniem. Porównaj te dwa:
Ogólnikowy: "Nieprawidłowy numer telefonu."
Konkretny: "Numery telefonów mają 9 cyfr. Wpisano 8. Dodaj jeszcze jedną cyfrę."
Komunikat ogólnikowy mówi, co jest źle, ale nie dlaczego ani jak to naprawić. Konkretny podaje problem, powód i dokładnie to, co zrobić. Przeczytanie konkretnego zajmuje trochę dłużej, ale oszczędza użytkownikowi minuty frustracji.
Komunikat wskazujący działanie zawiera instrukcję. "Hasła muszą zawierać co najmniej jedną cyfrę" mówi, czego brakuje. "Hasła muszą zawierać co najmniej jedną cyfrę. Wróć do pola hasła i dodaj cyfrę." mówi, co zrobić. W formularzach instrukcja jest zwykle oczywista (wróć do pola), ale jej wypisanie pomaga osobom, które słabo znają formularze albo korzystają z technologii asystujących.
Używaj prostego języka. Nie "Format kodu pocztowego niepoprawny". Zamiast tego: "Kody pocztowe mają 5 cyfr. Wpisano litery." Nie "Nieprawidłowy format e-maila". Zamiast tego: "Adresy e-mail potrzebują znaku @ i domeny (przykład: imie@firma.pl)."
Umiejscowienie, przez które błędów nie da się przeoczyć
Komunikat umieszczony daleko od pola, które go wywołało, łatwo przeoczyć. Gdy ktoś wypełnia formularz z wieloma polami, skupia się na każdym po kolei. Komunikat, który pojawia się na dole formularza, gdy uwaga jest jeszcze na górze, pozostaje niezauważony.
Najlepsze miejsce na komunikat o błędzie to bezpośrednio pod polem z błędem lub obok niego. Gdy ktoś przechodzi do kolejnego pola albo próbuje wysłać formularz, komunikat pojawia się od razu pod właśnie wypełnionym polem. Nie da się go uniknąć, bo pojawia się tam, gdzie spodziewana jest następna akcja.
Podsumowanie walidacji (lista wszystkich błędów po wysłaniu) umieść na górze formularza. Daje to użytkownikowi pełny widok wszystkich problemów. Potem, gdy przewija w dół, komunikaty przy poszczególnych polach pojawiają się ponownie obok każdego pola do poprawienia. To podwójne podejście służy dwóm celom: pokazuje pełen zakres poprawek i przypomina o nich podczas pracy nad kolejnymi polami.
Nigdy nie używaj w formularzach komunikatów typu toast. Toast to powiadomienie, które na chwilę pojawia się w rogu ekranu, a potem znika. W formularzach to najgorsze możliwe umiejscowienie. Błąd pojawia się daleko od pola, które go wywołało. Znika, zanim użytkownik zdąży go przeczytać. Tworzy rozdźwięk między problemem a miejscem naprawy. Jeśli komunikat musi zniknąć, powinno to nastąpić dopiero po pomyślnym poprawieniu pola.
Projekt wizualny komunikatów o błędach
Sam kolor nie wystarcza do przekazania błędu. Osoba z daltonizmem może nie widzieć czerwieni sygnalizującej błąd. Bardzo małą ikonę błędu może przeoczyć osoba słabowidząca. Polegaj na kilku sygnałach: kolor plus tekst plus ikona.
Czerwone obramowanie pola. Czerwona lub pomarańczowa ikona obok komunikatu. Tekst jasno opisujący problem. Wszystkie trzy razem tworzą stan błędu, który rozpozna niemal każdy.
Rozmiar czcionki ma znaczenie. Tekst komunikatu o błędzie powinien mieć ten sam rozmiar co etykieta pola. Jeśli jest mniejszy, ludzie mogą go przeoczyć albo uznać za mniej ważny, niż jest. Komunikat o błędzie zasługuje na taką samą wagę wizualną jak etykieta.
Może zmienić się też etykieta problematycznego pola. Tekst etykiety może zrobić się czerwony lub pogrubiony. To kolejny sygnał wizualny, który pomaga szybko przejrzeć formularz i znaleźć pole wymagające uwagi.
Ton i uprzejmość w komunikatach o błędach
Komunikaty o błędach powinny brzmieć tak, jakbyś komuś pomagał, a nie go obwiniał. Unikaj słów brzmiących ostro lub oskarżycielsko.
Ostro: "Wpisano nieprawidłowy adres e-mail."
Pomocnie: "Adresy e-mail potrzebują znaku @. Sprawdź wpis i spróbuj ponownie."
Ostro: "Hasło jest zbyt słabe."
Pomocnie: "Hasła potrzebują co najmniej 8 znaków. Dłuższe hasła są bezpieczniejsze."
Ostro: "Zapomniano wypełnić to pole."
Pomocnie: "To pole jest wymagane. Daj nam znać, co myślisz."
Pomocny ton przyznaje, że zdarzył się błąd, nie sprawiając, że osoba czuje się z tym źle. Wyjaśnia, dlaczego reguła istnieje (gdy to pomaga). Idzie naprzód, nie rozpamiętując błędu.
Częste błędy w komunikatach o błędach
Najczęstszy błąd to zbytnia ogólnikowość. "Nieprawidłowe dane" nic użytkownikowi nie mówi. "Coś poszło nie tak" jest równie bezużyteczne. Pisz konkretnie, na czym polega problem.
Drugi błąd to język techniczny. "Regex mismatch" czy "Validation failed" mogą coś znaczyć dla inżynierów, ale zwykli ludzie nie mają pojęcia, co te terminy oznaczają. Tłumacz błędy techniczne na prosty język.
Trzeci błąd to pokazywanie zbyt wielu błędów naraz. Jeśli formularz ma 20 pól i wszystkie 20 pokazuje błędy, użytkownik czuje się przytłoczony. Ustal priorytety: które błędy są krytyczne (jak puste pole wymagane) i pokaż je najpierw. Błędy drugorzędne (jak pole z problemem formatowania, ale opcjonalne) można pokazać potem.
Czwarty błąd to komunikaty powtarzające etykietę bez dodawania nowych informacji. Etykieta mówi "Adres e-mail". Komunikat mówi "Adres e-mail jest nieprawidłowy". Użytkownik już wie, które pole ma problem (widzi czerwone obramowanie), ale nadal nie wie, dlaczego jest nieprawidłowy. Komunikat powinien dodawać informację, a nie powtarzać etykietę.
Piąty błąd to brak wskazania drogi naprawy. "Hasło nie spełnia wymagań" mówi użytkownikowi, że coś jest nie tak, ale nie, jakie są wymagania. "Hasło nie spełnia wymagań. Hasła potrzebują co najmniej 8 znaków i jednej cyfry" mówi, co poprawić.
Jak WEMASY pomaga tworzyć jasne komunikaty o błędach
Kreator formularzy WEMASY zawiera gotowe komunikaty o błędach dla typowych typów pól. Pola e-mail pokazują "Adresy e-mail potrzebują znaku @", gdy format jest błędny. Pola telefonu pokazują "Numery telefonów mają 10 cyfr", gdy długość jest nieprawidłowa. Pola hasła pokazują wymagania dotyczące siły hasła, gdy użytkownik pisze. Te komunikaty są domyślnie jasne, konkretne i pomocne.
Możesz dostosować komunikaty do tonu swojej marki. Zmień "Adresy e-mail potrzebują znaku @" na "Ups, to nie wygląda na e-mail. Spróbujesz jeszcze raz?" Ton się zmienia, a konkret zostaje. Kontrolujesz, jak komunikat brzmi, bez utraty jasności.
Przy własnej walidacji (pola z konkretnymi regułami właściwymi Twojemu formularzowi) możesz pisać własne komunikaty bezpośrednio w kreatorze. System pomaga umieścić komunikat obok pola, pokazać go we właściwym momencie (w trakcie wpisywania lub przy wysyłaniu) i ostylować zgodnie z projektem formularza.
Walidacja w czasie rzeczywistym jest wbudowana, więc komunikaty mogą pojawiać się, gdy użytkownicy piszą, a nie dopiero po wysłaniu. Dzięki temu błędy wychodzą wcześnie, a unika się frustracji z wypełnienia całego formularza tylko po to, by na końcu odkryć problemy.
Sprawdź, jakie funkcje formularzy zawiera Twój pakiet WEMASY.