Co powinna powiedzieć aplikacja, gdy się psuje: pisanie komunikatów o błędach, które ludzie naprawdę rozumieją

Każda aplikacja czasem się psuje. Internet pada, serwer się zacina, ktoś wpisuje numer telefonu z literami zamiast cyfr. Tego do końca nie da się uniknąć. Co możesz kontrolować, to komunikat o błędzie — tekst, który aplikacja pokazuje, gdy coś pójdzie nie tak — i to właśnie ten jeden komunikat często decyduje o różnicy między użytkownikiem, który wzrusza ramionami i próbuje jeszcze raz, a użytkownikiem, który po cichu uznaje, że aplikacja jest zepsuta, i nigdy nie wraca.

Większość aplikacji zbudowanych przez AI robi ten moment źle. Nie dlatego, że builder podszedł do tego niedbale, ale dlatego, że komunikaty o błędach to element, o którym nikt nie myśli, dopóki coś nie zawiedzie na oczach prawdziwej osoby. Domyślnie aplikacje mają tendencję do pokazywania jednej z dwóch najgorszych rzeczy: nic albo przerażającego bloku technicznego tekstu. Naprawmy obie.

Dlaczego aplikacje zawodzą po cichu albo pokazują przerażające błędy?

Aplikacje psują się źle na dwa sposoby: milczą, gdy coś zawiedzie, albo pokazują techniczny błąd, którego zwykły człowiek nie zrozumie. Oba pozostawiają użytkownika w niepewności, a niepewność to właśnie to, co sprawia, że ludzie się poddają.

Cicha awaria. Freelancerka, którą nazwę Maya, zbudowała formularz rezerwacji dla swojej działalności fotograficznej. Klientka nacisnęła „Potwierdź rezerwację”, przycisk mrugnął i… nic. Żadnego potwierdzenia, żadnego błędu, żadnego spinnera. Czy się udało? Klientka nie była pewna, więc zarezerwowała jeszcze raz. Teraz Maya miała dwie rezerwacje na ten sam termin i zdezorientowaną klientkę. Aplikacja się nie zawiesiła — po prostu nie udało się zapisać danych, a aplikacja nic nie powiedziała, więc osoba przed ekranem nie miała pojęcia, jaka jest rzeczywistość.

Przerażający błąd techniczny. Druga awaria jest głośniejsza i jakoś jeszcze gorsza. Wolontariuszka prowadząca zbiórkę na cele społeczne próbowała wgrać arkusz kalkulacyjny i dostała czerwoną ramkę z napisem Error 500: Internal Server Error. Odczytała to jako „coś zepsułam”. Nie spróbowała ponownie, nie napisała maila po pomoc, po prostu zamknęła kartę — bo komunikat sprawiał, że problem brzmiał jak jej wina i jakby dalsze próby mogły być ryzykowne.

Obie użytkowniczki trafiły na zwykły, odwracalny problem. Obie odeszły, bo komunikaty o błędach w aplikacji albo milczały, albo brzmiały przerażająco.

Co sprawia, że komunikat o błędzie jest dobry?

Dobry komunikat o błędzie robi cztery drobne rzeczy, prostymi słowami: mówi, co się stało, mówi, czyj to problem, mówi, co zrobić dalej, i nie gubi pracy użytkownika.

Mówi, co się stało — „Nie udało się zapisać Twojej rezerwacji”, a nie cisza i nie 500.
Mówi, czyj to problem — zazwyczaj uczciwa odpowiedź brzmi „nasz”, a powiedzenie tego wprost uspokaja ludzi.
Mówi, co zrobić dalej — „Spróbuj ponownie za chwilę” albo „Sprawdź połączenie z internetem i spróbuj jeszcze raz”.
Nie gubi ich pracy — cokolwiek wpisali, wciąż jest w formularzu, gdy pojawia się komunikat.

I to tyle. Bez eseju z przeprosinami, bez kodu błędu jako nagłówka, bez obwiniania. Oto te same trzy awarie, przepisane na nowo:

❌ (nic się nie dzieje) → ✅ „Nie udało się tego teraz zapisać. Twoje dane wciąż tu są — dotknij Potwierdź, żeby spróbować ponownie.”
❌ Error 500: Internal Server Error → ✅ „Coś poszło nie tak po naszej stronie podczas wgrywania tego pliku. To nie Twoja wina. Spróbuj ponownie za chwilę.”
❌ Invalid input → ✅ „Ten numer telefonu wygląda podejrzanie — powinien mieć 10 cyfr, np. 555-123-4567.”

Zwróć uwagę, że ten ostatni wskazuje na konkretne pole i pokazuje, jak powinno wyglądać poprawne wypełnienie. „Invalid input” zmusza do zgadywania; „ten numer telefonu powinien mieć 10 cyfr” mówi dokładnie, co poprawić.

Które błędy aplikacji naprawić najpierw?

Nie musisz tworzyć własnego komunikatu dla każdej możliwej awarii — trzy przypadki pokrywają niemal wszystko, co może pójść nie tak w typowej aplikacji: nieudany zapis lub wysłanie, dane, których aplikacja nie może wykorzystać, oraz coś, co psuje się po Twojej stronie.

Nieudany zapis lub wysłanie. Najbardziej niszczący zaufanie przypadek, bo użytkownik zrobił wszystko dobrze i nie wie, czy zadziałało. Zawsze potwierdzaj sukces i wyjaśniaj porażkę. Nigdy nie zostawiaj ich w niepewności i nigdy nie wyrzucaj tego, co wpisali.

„Nie możemy wykorzystać tego, co wpisałeś” (walidacja). To tak naprawdę nie jest błąd — to nieporozumienie. Wychwyć je w momencie, gdy użytkownik opuszcza pole, wskaż dokładne pole i pokaż przykład poprawnego formatu. Nie czekaj, aż kliknie Wyślij, żeby ujawnić ścianę czerwieni.

„Coś się zepsuło po naszej stronie”. Prawdziwe problemy z serwerem lub siecią. Powiedz, że to po Twojej stronie, zachowaj spokojny ton i daj możliwość ponowienia próby. Użytkownik nie naprawi Twojego serwera, więc nie sprawiaj, żeby czuł, że musi.

Trzy nawyki, które po cichu pomagają

Kilka rzeczy odróżnia aplikacje, które radzą sobie z awariami z klasą, od tych, które sobie nie radzą:

Nigdy nie pokazuj surowego kodu błędu jako całego komunikatu. Kod może stać drobnym drukiem gdzieś na dole na potrzeby wsparcia, ale nagłówek, który czyta człowiek, powinien być zdaniem, a nie ERR_CONN_RESET.
Nigdy nie obwiniaj użytkownika. „Wpisałeś coś źle” boli; „ta data wygląda, jakby była w przeszłości — czy chodziło Ci o przyszły miesiąc?” pomaga. Ta sama informacja, zupełnie inne odczucie.
Zawsze zachowuj wpisane dane. Jeśli aplikacja się przeładuje albo zapis się nie uda, a formularz się wyczyści, zamieniłeś drobną usterkę w dziesięć minut ponownego wpisywania. Ludzie wybaczają nieudany zapis. Nie wybaczają robienia tej samej pracy dwa razy.

Jak sprawić, żeby Twój builder AI pisał lepsze komunikaty o błędach?

Większość z tego możesz uzyskać jednym poleceniem — wklej coś w stylu poniższego promptu, a Twój builder AI zastosuje powyższe zasady prostego języka w całej aplikacji.

„Kiedy zapis lub wgrywanie pliku się nie powiedzie, nie zawodź po cichu i nie pokazuj technicznego kodu błędu. Pokaż krótki, przyjazny komunikat prostym językiem, który mówi, co się stało, mówi, że można spróbować ponownie, i zachowuje wszystko, co użytkownik już wpisał. Dla pól formularza waliduj dane w momencie, gdy użytkownik opuszcza pole, i pokaż konkretny komunikat z przykładem poprawnego formatu.”

Następnie poproś, żeby przeprowadził Cię przez trzy scenariusze: internet jest wyłączony, wymagane pole jest puste, serwer działa wolno. Jeśli odpowiedzią na którykolwiek z nich jest „nic się nie pokazuje” albo „pokazuje się surowy błąd” — to jest Twoja następna poprawka.

Jak przetestować komunikaty o błędach w Twojej aplikacji?

Wyłącz wifi, otwórz aplikację i spróbuj wykonać główną czynność — to cały test i zajmuje dwie minuty.

Zarezerwuj termin, zapisz notatkę, wgraj plik. Zobacz, co się pokaże. Czy powiedziało Ci coś, co zwykły człowiek by zrozumiał? Czy zgubiło to, co wpisałeś? Teraz włącz wifi z powrotem i celowo wpisz coś bezsensownego w pole. Te same pytania.

Większość aplikacji nie przechodzi tego testu za pierwszym razem i to w porządku — po prostu pokazuje, od czego zacząć. Nie musisz uczynić idealnym każdego komunikatu o błędzie. Znajdź jedną rzecz w swojej aplikacji, która psuje się najczęściej, i spraw, żeby ten komunikat był życzliwy, jasny i szczery. Następnym razem, gdy trafi na niego prawdziwa osoba, spróbuje ponownie zamiast odejść — a próbowanie ponownie to cała gra.