Jak pisać komunikaty w produkcie, które nie wkurzają użytkowników

Słowa w interfejsie (UX Writing) to nie jest „wypełniacz”. To jedna z najważniejszych części designu. Komunikaty w produkcie działają jak personalna obsługa klienta w świecie rzeczywistym. W trudnym momencie mogą uratować sytuację albo doprowadzić użytkownika do szału.

Możesz mieć najpiękniejsze UI na świecie, ale jeśli użytkownik przy próbie zapłaty zobaczy komunikat: „Wystąpił nieznany błąd (Error 503)”, to jego zaufanie do produktu spada do zera.

Co ciekawe komunikaty najczęściej wkurzają nie dlatego, że są „niegrzeczne”. Wkurzają, bo są niejasne, zrzucają winę na użytkownika albo zostawiają go bez rozwiązania.

Oto 7 zasad, jak zamienić irytujące błędy w pomocną dłoń.

---

1) Przestań obwiniać użytkownika (no blame)

Nikt nie lubi czuć się głupio. A komunikaty często brzmią jak oskarżenie. „Wpisałeś złe hasło”, „Podałeś błędny format”, „Nieprawidłowe dane”. To są klasyczne mikro-agresje UX.

Jak to naprawić – zdejmij winę z użytkownika. Mów o problemie, a nie o osobie.

• Źle: „Wpisałeś nieprawidłowy e-mail.” (Ty zrobiłeś błąd).

• Dobrze: „Nie znaleźliśmy konta z tym adresem e-mail.” (My nie znaleźliśmy).

• Źle: „Błędny format daty.”

• Dobrze: „Wpisz datę w formacie DD/MM/RRRR.”

2) Zasada 3 pytań (komunikat musi mieć rozwiązanie)

Komunikat „Wystąpił błąd” to ślepa uliczka. Użytkownik w stresującej sytuacji potrzebuje odpowiedzi na trzy proste pytania:

• Co się stało?

• Dlaczego?

• Co mam teraz zrobić?

Jeśli komunikat nie odpowiada na te pytania, użytkownik będzie się irytował.

• Źle: „Błąd płatności.”

• Dobrze: „Nie udało się pobrać opłaty (co?), ponieważ Twoja karta wygasła (dlaczego?). Zaktualizuj dane karty lub wybierz BLIK (co robić?).”

3) Mów językiem ludzi, nie robotów

Programiści piszą komunikaty dla systemu. Ty musisz je przetłumaczyć dla ludzi. Użytkownik nie żyje w sesjach, tokenach i kodach błędów. Żyje w swoich zadaniach.

• Źle: „Server Response Timeout (504).”

• Dobrze: „Serwer długo nie odpowiada. Sprawdź połączenie z internetem i spróbuj odświeżyć stronę.”

• Źle: „Token sesji wygasł.”

• Dobrze: „Wylogowaliśmy Cię ze względów bezpieczeństwa. Zaloguj się ponownie.”

4) Przyciski muszą być instrukcją

Największy grzech modali? Pytanie i przyciski „Tak / Nie” lub „Anuluj / OK”. Użytkownik nie czyta całego tekstu. Skanuje nagłówek i szuka przycisku. Jeśli przycisk brzmi „Tak”, a on nie przeczytał pytania, to nie wie, na co się zgadza.

Jak to naprawić? Przycisk powinien być czasownikiem opisującym akcję.

• Kontekst: Czy na pewno chcesz usunąć projekt?

• Źle: [Tak] / [Nie]

• Dobrze: [Usuń projekt] / [Zachowaj]

5) Daj poczucie kontroli i bezpieczeństwa

Największy stres użytkownika to: „Czy coś zepsułem? Czy straciłem dane?”. Dobre komunikaty działają jak tabletka uspokajająca.

• Źle: „Nie udało się zapisać.”

• Dobrze: „Nie zapisaliśmy zmian, bo straciłeś połączenie. Twoje dane są bezpieczne. Kliknij ‘Spróbuj ponownie’, gdy wróci internet.”

• Wskazówka: Używaj zwrotów: „Możesz to zmienić później”, „Możesz cofnąć tę akcję”. To redukuje lęk przed kliknięciem.

6) Puste stany (empty states) to szansa, nie błąd

Pusta lista zadań, pusty koszyk, brak powiadomień. Najgorsze, co możesz napisać, to: „Brak danych”. To brzmi jak błąd systemu.

Jak to naprawić? Wykorzystaj puste miejsce na edukację i wezwanie do akcji.

• Źle: „Brak zadań do wyświetlenia.”

• Dobrze: „Wszystko zrobione na dziś! 🎉 Dodaj nowe zadanie, żeby zacząć planować jutro.” (poniżej przycisk „Dodaj”).

7) Humor jest ryzykowny (tone of voice)

Kiedyś modne było bycie „zabawnym” w komunikatach błędów („Ups, nasze małpy coś zepsuły”). Dziś wiemy, że w momentach stresu (płatności, logowanie, błędy) humor jest odbierany jako lekceważenie.

Podtawowa zasada – jeśli chodzi o pieniądze lub dane użytkownika, to bądź konkretny, a nie zabawny.

Ogólny szablon komunikatu błędu

Jeśli musisz szybko napisać komunikat i nie wiesz jak, użyj tego schematu. Prawie zawsze działa:

• Co się stało (ludzkim językiem).

• Dlaczego (jeśli to pomaga zrozumieć).

• Co dalej (konkretna akcja / przycisk).

• Bezpiecznik (uspokojenie o dane).

Przykład:

„Nie możemy wysłać Twojego raportu (co?), ponieważ plik jest za duży (dlaczego?). Zmniejsz plik do 5MB i spróbuj ponownie (co dalej?). Twoja wersja robocza została zapisana (bezpiecznik).”

Test – przeczytaj komunikat na głos

Zanim zatwierdzisz tekst w makiecie, zrób prosty test. Przeczytaj komunikat na głos koledze z zespołu, który nie zna kontekstu. Jeśli musisz mu dopowiedzieć: „No chodzi o to, że serwer padł i musi odświeżyć”, to znaczy, że komunikat jest do poprawy. Komunikat musi bronić się sam. Bez tłumacza.

---

Słowa w produkcie to element UX, tak samo ważny jak przyciski i kolory. Złe słowa tworzą tarcie. Dobre słowa je usuwają.

Następnym razem, gdy będziesz pisać komunikat błędu, pomyśl o użytkowniku, który jest zmęczony, spieszy się i właśnie coś mu nie zadziałało. Nie dokładaj mu stresu. Daj mu jasne rozwiązanie.