Jak pisać błędy i komunikaty, które faktycznie pomagają
Komunikaty w produkcie są trochę jak rozmowa z użytkownikiem w trudnym momencie.
Użytkownik chciał coś zrobić. Kliknął. Wypełnił formularz. Przesłał plik. Zapisał zmiany. Zapłacił. Połączył konto. I nagle coś poszło nie tak.
To jest moment, w którym produkt może zrobić jedną z dwóch rzeczy:
pomóc użytkownikowi szybko wrócić na właściwą ścieżkę,
albo jeszcze bardziej go zirytować.
Niestety wiele komunikatów brzmi tak, jakby były pisane dla systemu, a nie dla człowieka:
„Wystąpił błąd.”
„Operacja nie powiodła się.”
„Nieprawidłowe dane.”
„Spróbuj ponownie później.”
„Błąd 403.”
Technicznie coś mówią. Praktycznie nie pomagają.
Dobry komunikat nie jest ozdobą interfejsu. Jest częścią doświadczenia użytkownika. A w trudnych momentach często decyduje o tym, czy użytkownik spróbuje dalej, czy zamknie produkt z poczuciem frustracji.
1) Dobry komunikat odpowiada na trzy pytania
Każdy komunikat błędu powinien pomóc użytkownikowi zrozumieć:
Co się stało?
Dlaczego to się stało?
Co mam zrobić teraz?
Jeśli komunikat odpowiada tylko na pierwsze pytanie, jest niepełny.
Przykład słaby:
„Nie udało się zapisać zmian.”
Użytkownik nadal nie wie:
dlaczego się nie udało,
czy dane przepadły,
co ma zrobić,
czy może spróbować ponownie.
Lepsza wersja:
„Nie zapisaliśmy zmian, bo straciłeś połączenie z internetem. Twoje dane są bezpieczne. Sprawdź połączenie i kliknij „Spróbuj ponownie”.”
To nie jest dużo dłuższe. Ale jest dużo bardziej pomocne.
2) Nie pisz językiem systemu
System mówi:
„Błąd autoryzacji.”
„Token wygasł.”
„Walidacja nie powiodła się.”
„Brak uprawnień do zasobu.”
Użytkownik mówi:
„Nie mogę wejść.”
„Nie wiem, co poprawić.”
„Dlaczego mnie wylogowało?”
„Nie mam dostępu.”
Komunikat powinien tłumaczyć sytuację językiem użytkownika, nie językiem backendu.
Zamiast:
„Token sesji wygasł.”
Napisz:
„Ze względów bezpieczeństwa wylogowaliśmy Cię po dłuższej bezczynności. Zaloguj się ponownie, żeby kontynuować.”
Zamiast:
„Brak uprawnień.”
Napisz:
„Nie masz dostępu do tego projektu. Poproś administratora o nadanie uprawnień.”
Zamiast:
„Nieprawidłowy format.”
Napisz:
„Wpisz datę w formacie DD.MM.RRRR, np. 29.09.2026.”
Użytkownik nie powinien musieć tłumaczyć komunikatu na ludzki język. Produkt powinien zrobić to za niego.
3) Nie obwiniaj użytkownika
Bardzo łatwo napisać komunikat, który brzmi jak oskarżenie:
„Wprowadziłeś błędne dane.”
„Niepoprawnie wypełniony formularz.”
„Nieprawidłowe hasło.”
„Źle wpisany numer telefonu.”
To niby drobiazg, ale ton ma znaczenie. Szczególnie wtedy, gdy użytkownik już jest sfrustrowany.
Lepsza zasada:
Nie mów użytkownikowi, że zrobił coś źle. Powiedz mu, jak to naprawić.
Zamiast:
„Nieprawidłowy adres e-mail.”
Napisz:
„Wpisz adres e-mail w formacie name@example.com.”
Zamiast:
„Hasło jest błędne.”
Napisz:
„To hasło nie pasuje do tego konta. Sprawdź pisownię albo zresetuj hasło.”
Zamiast:
„Niepoprawny plik.”
Napisz:
„Ten plik ma nieobsługiwany format. Prześlij plik PDF, JPG albo PNG.”
Różnica jest prosta: pierwszy komunikat ocenia, drugi prowadzi.
4) Pisz konkretnie, nie ogólnie
Najbardziej frustrujące komunikaty to te, które brzmią jak ściana:
„Coś poszło nie tak.”
Czasem rzeczywiście nie wiemy dokładnie, co się stało. Ale bardzo często możemy powiedzieć więcej.
Słabo:
„Nie udało się przesłać pliku.”
Lepiej:
„Nie przesłaliśmy pliku, bo jest większy niż 25 MB. Zmniejsz plik albo wybierz inny.”
Słabo:
„Nie udało się połączyć konta.”
Lepiej:
„Nie możemy teraz połączyć konta Google. Sprawdź, czy masz uprawnienia administratora, i spróbuj ponownie.”
Słabo:
„Wystąpił błąd płatności.”
Lepiej:
„Bank odrzucił płatność. Sprawdź kartę lub wybierz inną metodę płatności.”
Im bardziej konkretny komunikat, tym mniej użytkownik musi zgadywać.
A zgadywanie w produkcie prawie zawsze oznacza frustrację.
5) Pokaż następny krok
Dobry komunikat powinien kończyć się działaniem.
Nie tylko:
„Nie udało się.”
Ale:
„Zrób teraz to.”
Przykłady dobrych następnych kroków:
„Spróbuj ponownie.”
„Sprawdź połączenie z internetem.”
„Wybierz mniejszy plik.”
„Poproś administratora o dostęp.”
„Zaloguj się ponownie.”
„Wybierz inną metodę płatności.”
„Skontaktuj się z supportem i podaj kod błędu.”
Jeśli użytkownik po przeczytaniu komunikatu nadal nie wie, co zrobić, komunikat nie spełnił swojej roli.
6) Uspokój tam, gdzie pojawia się ryzyko
Niektóre momenty są szczególnie stresujące:
płatność,
usuwanie danych,
wysyłka ważnego formularza,
import pliku,
zapisywanie zmian,
integracja z innym narzędziem,
zmiana uprawnień.
W tych miejscach użytkownik często myśli:
„Czy coś straciłem?”
„Czy pieniądze zostały pobrane?”
„Czy mogę to cofnąć?”
„Czy ktoś zobaczył moje dane?”
„Czy muszę zaczynać od początku?”
Dlatego komunikat powinien nie tylko informować, ale też uspokajać.
Przykład:
„Nie udało się wysłać formularza. Twoje odpowiedzi zostały zapisane. Spróbuj ponownie za chwilę.”
Albo:
„Nie pobraliśmy płatności. Możesz spróbować ponownie lub wybrać inną metodę.”
Albo:
„Projekt został przeniesiony do kosza. Możesz go przywrócić przez 30 dni.”
Takie zdania zmniejszają stres i budują zaufanie.
7) Komunikat powinien pojawić się tam, gdzie problem
Jeśli błąd dotyczy konkretnego pola, pokaż go przy tym polu.
Nie każ użytkownikowi szukać problemu na całej stronie.
Słabo:
Na górze formularza:
„Formularz zawiera błędy.”
Lepiej:
Przy polu „Numer telefonu”:
„Wpisz numer w formacie +48 123 456 789.”
Przy polu „Hasło”:
„Hasło powinno mieć co najmniej 8 znaków i 1 cyfrę.”
Przy polu „Data”:
„Ta data jest z przeszłości. Wybierz datę od dzisiaj.”
Dobre komunikaty są kontekstowe. Pojawiają się dokładnie tam, gdzie użytkownik może coś poprawić.
8) Nie używaj modala, jeśli wystarczy mały komunikat
Nie każdy błąd zasługuje na przerwanie pracy użytkownika.
Modal powinien być zarezerwowany dla sytuacji, w których użytkownik musi podjąć decyzję albo istnieje poważne ryzyko.
Przykłady, gdzie modal ma sens:
usuwanie czegoś ważnego,
utrata niezapisanych zmian,
zmiana planu płatności,
nadanie szerokich uprawnień,
operacja, której nie da się łatwo cofnąć.
Ale jeśli użytkownik po prostu zapisał zmiany, przesłał plik albo zobaczył mały błąd walidacji, modal jest przesadą.
Często lepsze są:
komunikaty inline,
toast,
banner,
podpowiedź przy polu,
stan pusty z instrukcją.
Dobry komunikat pomaga. Nie powinien niepotrzebnie blokować.
9) Nie przesadzaj z humorem
Humor w produktach bywa kuszący.
„Upsik, coś się wysypało 😅”
„Houston, mamy problem!”
„Oj, tego się nie spodziewaliśmy!”
Czasem to działa. Ale przy błędach łatwo przesadzić.
Jeśli użytkownik:
stracił dane,
nie może zapłacić,
ma deadline,
nie może się zalogować,
nie może wykonać ważnej akcji,
to żart może zabrzmieć jak brak szacunku.
Dobra zasada:
Im większy stres użytkownika, tym mniej żartów.
W komunikatach błędów zwykle lepiej postawić na spokój, prostotę i konkret.
10) Daj kod błędu, ale nie zamiast wyjaśnienia
Kody błędów są przydatne dla supportu i zespołu technicznego. Ale dla użytkownika same w sobie niewiele znaczą.
Słabo:
„Error 504.”
Lepiej:
„Serwer odpowiada zbyt długo, więc nie mogliśmy załadować danych. Spróbuj ponownie za chwilę. Jeśli problem się powtórzy, podaj supportowi kod błędu: 504.”
Kod błędu może być dodatkiem. Nie powinien być całym komunikatem.
11) Dobre komunikaty sukcesu też są ważne
Nie tylko błędy wymagają dobrego tekstu.
Komunikaty sukcesu pomagają użytkownikowi zrozumieć, że coś się udało i co dalej.
Słabo:
„Zapisano.”
Lepiej:
„Zmiany zostały zapisane. Są już widoczne dla całego zespołu.”
Słabo:
„Wysłano.”
Lepiej:
„Zaproszenie zostało wysłane do Ani. Damy Ci znać, gdy dołączy do projektu.”
Słabo:
„Gotowe.”
Lepiej:
„Raport jest gotowy. Możesz go pobrać albo wysłać zespołowi.”
Dobry komunikat sukcesu zamyka pętlę i daje użytkownikowi poczucie kontroli.
12) Najprostszy szablon dobrego komunikatu
Jeśli nie wiesz, jak napisać komunikat, użyj prostego schematu:
Co się stało + dlaczego + co dalej + czy coś jest bezpieczne
Przykład:
„Nie zapisaliśmy zmian, bo straciłeś połączenie z internetem. Twoje dane są bezpieczne. Sprawdź połączenie i kliknij „Spróbuj ponownie”.”
Nie zawsze potrzebujesz wszystkich czterech elementów. Ale warto je sprawdzić.
Minimalny dobry komunikat powinien przynajmniej mówić:
co się stało,
co użytkownik może zrobić.
Przykłady przed i po
Przykład 1: formularz
Słabo:
„Nieprawidłowe dane.”
Lepiej:
„Uzupełnij wymagane pola: imię, e-mail i numer telefonu.”
Jeszcze lepiej:
Przy każdym polu pokaż konkretny komunikat:
„Wpisz adres e-mail w formacie name@example.com.”
Przykład 2: brak dostępu
Słabo:
„Brak uprawnień.”
Lepiej:
„Nie masz dostępu do tego projektu. Poproś administratora o dodanie Cię do zespołu.”
Przykład 3: płatność
Słabo:
„Płatność nieudana.”
Lepiej:
„Bank odrzucił płatność. Nie pobraliśmy pieniędzy. Sprawdź kartę albo wybierz inną metodę płatności.”
Przykład 4: import pliku
Słabo:
„Import nie powiódł się.”
Lepiej:
„Nie możemy zaimportować pliku, bo brakuje kolumny „E-mail”. Dodaj tę kolumnę i prześlij plik ponownie.”
Przykład 5: awaria
Słabo:
„Coś poszło nie tak.”
Lepiej:
„Nie możemy teraz załadować danych. Odśwież stronę za chwilę. Jeśli problem się powtórzy, skontaktuj się z supportem.”
Mini-checklista: czy komunikat faktycznie pomaga?
Przed wypuszczeniem komunikatu sprawdź:
Czy użytkownik wie, co się stało?
Czy wie, co może zrobić dalej?
Czy komunikat jest napisany ludzkim językiem?
Czy nie obwinia użytkownika?
Czy jest konkretny?
Czy pojawia się w odpowiednim miejscu?
Czy uspokaja, jeśli istnieje ryzyko utraty danych, pieniędzy albo kontroli?
Czy nie blokuje pracy bez potrzeby?
Czy support dostanie wystarczająco dużo informacji, jeśli problem wróci?
Czy da się go zrozumieć bez wiedzy technicznej?
Jeśli komunikat nie przechodzi tej checklisty, prawdopodobnie będzie bardziej frustrował niż pomagał.
Błędy i komunikaty to nie są drobne teksty na końcu projektu. To są momenty, w których produkt rozmawia z użytkownikiem wtedy, gdy coś jest niejasne, stresujące albo nie działa zgodnie z planem.
Dobry komunikat nie musi być błyskotliwy. Musi być pomocny.
Powinien powiedzieć:
co się stało,
co to oznacza,
co można zrobić dalej,
i czy użytkownik nadal ma kontrolę.
Jeśli chcesz zapamiętać jedno zdanie, niech będzie to:
Komunikat błędu nie powinien opisywać problemu systemu. Powinien pomagać użytkownikowi wrócić do działania.
To mała rzecz, która bardzo często robi dużą różnicę w doświadczeniu produktu.