Komunikaty błędów na stronie są częścią zadania, które klient nadal chce wykonać. „Coś poszło nie tak” nie wyjaśnia, czy należy poprawić adres, wybrać inny termin, czy sprawdzić wynik ostatniej próby. Najpierw rozpoznaj typ niepowodzenia, później napisz komunikat i dopiero wtedy sprawdź drogę powrotu. W przypadku formularza kontaktowego oraz innych działań liczy się również to, czy wpisane informacje pozostają dostępne i czy klient rozumie stan zgłoszenia.
Rozdziel błąd pola, zmianę stanu i brak potwierdzenia
Błąd pola oznacza, że konkretną wartość trzeba poprawić, na przykład format adresu. Zmiana stanu oznacza, że prawidłowe wcześniej dane nie pozwalają już wykonać zadania, bo ktoś zajął termin albo obiekt został usunięty. Brak potwierdzenia odpowiedzi serwera pozostawia inną niepewność: operacja mogła zostać zapisana, mimo że ekran nie pokazał wyniku. Te trzy sytuacje wymagają różnych następnych kroków, dlatego nie powinny otrzymywać jednego komunikatu i identycznego przycisku ponowienia.
Weź jeden częsty ekran i poproś właściciela funkcji o przypisanie faktycznych odpowiedzi aplikacji do tych kategorii. Nie wnioskuj o przyczynie tylko z koloru powiadomienia lub słów użytkownika. Jeżeli błąd dotyczy określonej grupy, techniczne warunki sprawdzaj również według podejścia do błędów widocznych u części użytkowników. Nagranie drogi użytkownika pokazuje zachowanie interfejsu, lecz nie zastępuje potwierdzenia wyniku po stronie serwera.
Zapisz stan danych zanim obiecasz ponowną próbę
Komunikat powinien wyjaśniać, co pozostało z dotychczasowej pracy, ale wyłącznie na podstawie sprawdzonego zachowania. Jeżeli pola rzeczywiście pozostają w formularzu, można napisać „Pozostałe dane zachowaliśmy w tym formularzu”. Jeżeli aplikacja ich nie przechowuje, nie dodawaj takiej obietnicy dla uspokojenia klienta. Sprawdź osobno błąd pojedynczego pola, odrzucenie całego zadania i przerwanie połączenia, bo mogą prowadzić do różnych stanów formularza.
Przed proponowaniem ponowienia ustal też, czy operacja mogła już zostać wykonana. W przypadku zapisu rezerwacji sprawdzenie aktualnego stanu może być bezpieczniejsze niż drugi wybór przycisku. Opisz tę drogę w języku klienta, bez polecenia odczytania wewnętrznego kodu błędu. Projektowanie zabezpieczenia przed duplikatami należy do właściciela funkcji; sam komunikat ani narzędzie analityczne nie gwarantują, że ponowna próba nie utworzy kolejnego zapisu.
Napisz komunikat prowadzący do właściwego działania
Użyteczny komunikat nazywa problem, wskazuje potrzebną zmianę i oferuje działanie zgodne z faktycznym stanem. Dla błędu adresu wystarczy przykład oczekiwanego formatu przy polu. Dla zajętego terminu potrzebny jest powrót do dostępnych terminów, a nie zachęta do ponownego wysłania tych samych danych. Tabela przedstawia przykłady dla fikcyjnej rezerwacji, których nie należy kopiować bez sprawdzenia zachowania własnej aplikacji.
Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.
| Rodzaj problemu | Przykładowy komunikat | Właściwa dalsza droga |
|---|---|---|
| Pole | Wpisz adres e-mail w formacie nazwa@example.com. | Popraw wskazane pole bez utraty pozostałych danych |
| Stan zadania | Ten termin został właśnie zajęty. Wybierz inny termin. | Wróć do aktualnego wyboru terminów |
| Niepotwierdzony wynik serwera | Nie możemy teraz potwierdzić rezerwacji. Sprawdź jej stan przed kolejną próbą. | Sprawdź faktyczny zapis i uniknij duplikatu |
Unikaj wiadomości „Błąd 500, spróbuj ponownie”, jeżeli klient nie może ocenić skutku poprzedniego działania. Czytelny tekst może brzmieć: „Nie możemy teraz potwierdzić rezerwacji. Otwórz listę swoich rezerwacji i sprawdź, czy termin został zapisany, zanim rozpoczniesz kolejną próbę”. Takie brzmienie jest właściwe tylko wtedy, gdy lista rzeczywiście pozwala wiarygodnie sprawdzić stan. Jeśli nie ma takiej drogi, trzeba przygotować inny proces wyjaśnienia wyniku, zamiast wymyślać przycisk prowadzący donikąd.
Sprawdź komunikat przy polu i w podsumowaniu
Komunikat przy polu pomaga poprawić wartość bez szukania jej na całej stronie. Gdy błędów jest kilka, podsumowanie może wskazać wymagane poprawki, lecz musi prowadzić do właściwych miejsc. Sprawdź, czy nazwa pola jest jednoznaczna, a tekst pozostaje widoczny po rozpoczęciu korekty. Nie opieraj identyfikacji błędu wyłącznie na kolorze obramowania, bo część odbiorców nie rozpozna z niego znaczenia ani potrzebnego działania; sprawdź także ekran przy powiększeniu i upewnij się, że opis nie znika pod stałym paskiem oraz nie zasłania poprawianego pola podczas wpisywania nowej wartości na telefonie z otwartą klawiaturą ekranową.
Przejdź formularz klawiaturą i sprawdź kolejność dojścia do poprawki oraz widoczność zaznaczonego elementu. Przetestuj również komunikat z technologią asystującą, jeśli jest dostępna w procesie weryfikacji produktu. Samo nagranie kursora nie potwierdzi, że powiadomienie zostało prawidłowo zakomunikowane czytnikowi ekranu. Powiąż tę próbę z pracą nad dostępnością ścieżek kontaktu, zachowując w artykule konkretny problem odzyskania zadania po błędzie.
W3C w poradniku powiadomień formularzy zaleca jasne komunikaty informujące o błędach oraz sposobach ich poprawienia i o prawidłowym zakończeniu zadania. Przykłady poniżej są propozycjami redakcyjnymi dla opisanych sytuacji.
Odtwórz, co klient zrobił po powiadomieniu
Analiza powinna obejmować chwilę przed błędem oraz działania po jego wyświetleniu. W dostępnych nagraniach zaznacz wybraną akcję, pojawienie się komunikatu, próbę poprawki i końcowy stan ekranu. Nie zakładaj, że zamknięcie okna oznacza przeczytanie tekstu, a brak kolejnego kliknięcia świadczy o rezygnacji z usługi. Porównaj kilka przebiegów, aby znaleźć powtarzalny problem powrotu, na przykład ponowne wysyłanie bez poprawienia wskazanego pola.
Korzystaj z zasad analizy nagrań sesji i odnotuj ograniczenia próbki oraz dostępnego zakresu rejestracji. Dane pola mogą być zamaskowane, więc nie próbuj odgadywać wpisanej wartości z zachowania klienta. Do potwierdzenia konkretnego błędu użyj kontrolowanego testu albo odpowiednich danych technicznych bez ujawniania danych osobowych. Nagranie pomaga wskazać miejsce do sprawdzenia, ale nie jest rejestrem wszystkich odpowiedzi serwera i nie pokaże każdej przyczyny niepowodzenia.
Połącz poprawkę z potwierdzeniem zakończenia
Po udanej poprawce klient powinien rozpoznać, że zadanie zostało zakończone i co nastąpi dalej. Jeśli aplikacja potwierdza wysłanie zgłoszenia, napisz, jaki stan został osiągnięty, zamiast pozostawiać puste pola jako jedyny sygnał. Nie utożsamiaj wyboru przycisku z przyjęciem operacji. W pomiarze używaj zdefiniowanego celu, uruchamianego przez właściwe potwierdzenie aplikacji, jeżeli zostało ono zintegrowane; samo narzędzie nie zna znaczenia dowolnego kliknięcia.
Sprawdzając wyniki dla kilku odmian adresu strony, najpierw ustal, czy opisują ten sam ekran. Temat parametrów URL w raportach pomoże uniknąć rozproszenia przypadków błędu między pozornie różnymi stronami. W analityce Meetlead oceń dostępne nagrania i ścieżki, a znaczenie wyniku potwierdź w aplikacji wykonującej zadanie. Zacznij od jednego typu niepowodzenia i jednej poprawki, której dalszy przebieg możesz rzeczywiście obserwować.
Pytania o komunikaty błędów
Czy wystarczy zmienić tekst „Coś poszło nie tak”? Nie, jeśli proponowana droga nadal jest niedostępna albo prowadzi do utraty pracy. Najpierw ustal stan operacji i danych, następnie dopasuj treść oraz działanie.
Sprawdź cały powrót, od powiadomienia do potwierdzenia zakończenia. Dobry tekst nie zastępuje naprawy procesu, lecz pomaga klientowi wykorzystać prawidłowo działający proces.
Czy nagrania pokażą każdy błąd formularza? Nie, ich zakres zależy od rejestracji sesji, pokrycia danych i zachowania strony.
Mogą pokazać widoczny komunikat oraz reakcję, ale nie potwierdzają same w sobie przyczyny ani zapisu operacji. Weryfikację uzupełnij kontrolowaną próbą i właściwymi danymi aplikacji. Brak błędu w próbce nagrań nie dowodzi, że błąd nigdy nie występuje.
