Blog
Klient chce kupić. Twoja strona mówi mu, że nie może.
Klient chce kupić produkt. Wybrał rozmiar, dodał go do koszyka i przeszedł do płatności. Wpisuje kod pocztowy, a sklep informuje go, że nie ma dostępnych sposobów dostawy. Klient zaczyna się zastanawiać, czy firma w ogóle wysyła zamówienia do jego miejscowości. Właściciel sklepu zastanawia się, dlaczego ludzie porzucają koszyki. Programista wie, że wystarczy jeszcze wpisać nazwę miasta.
Trzy osoby patrzą na tę samą sytuację i rozumieją ją zupełnie inaczej. A przecież klient nie przyszedł sprawdzać, w którym momencie system przelicza dostawę. Chciał po prostu zrobić zakupy.
Sklep działa. Tylko klient o tym nie wie
W październiku 2026 roku właściciel sklepu WooCommerce opisał problem z przedwczesnym komunikatem „No shipping options available”. Pojawiał się po wpisaniu kodu pocztowego, zanim użytkownik zdążył uzupełnić miasto. Po podaniu całego adresu dostawa była dostępna. Według relacji przedsiębiorcy niektórzy klienci kontaktowali się ze sklepem, przekonani, że zamówienie jest niemożliwe. To pojedynczy przypadek, a nie dowód skali zjawiska, ale podobny problem został odnotowany w zgłoszeniu WooCommerce dotyczącym blokowego checkoutu.
Z technicznego punktu widzenia system nie miał jeszcze kompletu informacji. Z perspektywy kupującego sklep przekazał jednak jasny komunikat: nie możemy dostarczyć zamówienia. I właśnie tu leży problem. Komunikat może być zgodny z bieżącym stanem aplikacji, ale nadal wprowadzać człowieka w błąd.
Programista widzi stan systemu. Klient widzi problem
Osoba projektująca formularz zna jego logikę. Wie, które pola uruchamiają przeliczenie kosztów, jakie dane są niezbędne i dlaczego po chwili znika komunikat. Klient nie ma tej wiedzy i nie powinien jej potrzebować. Kieruje się własnym wyobrażeniem tego, jak działają zakupy: wpisuję adres, wybieram dostawę, płacę.
W badaniach doświadczenia użytkownika mówi się o modelach mentalnych. To uproszczone wyobrażenia, według których próbujemy zrozumieć działanie systemu. Gdy strona zachowuje się inaczej, niż się spodziewamy, pojawia się konieczność wyjaśnienia rozbieżności. W sklepie internetowym nie zawsze mamy ochotę przeprowadzać takie dochodzenie. Zwłaszcza gdy obok otwarta jest karta konkurencji.
Dlatego komunikat „Nie znaleziono metod dostawy” i komunikat „Uzupełnij adres, aby zobaczyć dostępne sposoby dostawy” nie są tym samym. Pierwszy informuje o pozornym końcu drogi. Drugi pokazuje kolejny krok. Oczywiście ten drugi ma sens tylko wtedy, gdy problem rzeczywiście polega na niekompletnym adresie, a nie na faktycznym braku dostawy.
Dlaczego czerwony komunikat potrafi zatrzymać zakup?
Nie trzeba odwoływać się do tajemniczych mechanizmów mózgu, żeby to wyjaśnić. Niejasny komunikat zwiększa wysiłek potrzebny do wykonania zadania. Użytkownik musi przerwać wpisywanie danych, zrozumieć przyczynę błędu, zgadnąć rozwiązanie i zdecydować, czy warto próbować dalej. W projektowaniu interfejsów taki wysiłek określa się między innymi jako koszt interakcji.
Nielsen Norman Group podkreśla, że dobry komunikat błędu powinien być zrozumiały, pojawiać się w odpowiednim miejscu i wskazywać możliwy sposób rozwiązania problemu. Z kolei Baymard w badaniach walidacji formularzy zwraca uwagę na znaczenie momentu wyświetlania informacji i usuwania błędu po poprawieniu pola. To zalecenia wynikające z obserwacji użyteczności, nie gwarancja określonego wzrostu sprzedaży.
Wyobraź sobie formularz, który ogłasza niepoprawny e-mail, kiedy zdążyłeś wpisać dopiero „anna@”. Albo numer telefonu, który świeci się na czerwono, zanim dokończysz ostatnią cyfrę. System jest niecierpliwy. Użytkownik wcale nie musi być.
Nie każdy błąd jest błędem klienta
Czasami użytkownik faktycznie wpisuje niepoprawną wartość. Innym razem problem leży w konfiguracji integracji, przestarzałym skrypcie, walidacji uruchamianej za wcześnie albo komunikacie, który nie rozróżnia braku danych od braku możliwości realizacji usługi. Tych sytuacji nie należy wrzucać do jednego worka.
Formularz kontaktowy, który po nieudanej wysyłce usuwa wszystkie wpisane dane, zmusza człowieka do powtarzania pracy. Checkout, który pokazuje techniczny kod błędu płatności, nie mówi, czy środki zostały pobrane i co należy zrobić. Rezerwacja, która wyświetla „Wystąpił błąd”, pozostawia gościa bez informacji, czy termin został zablokowany. Każdy z tych przykładów wymaga innej naprawy, ale zasada pozostaje wspólna: użytkownik powinien rozumieć, co się stało i co może zrobić dalej.
Nie chodzi o ukrywanie prawdziwych awarii za miłymi zdaniami. Jeżeli płatność się nie udała, strona powinna powiedzieć to wprost. Jeżeli formularz jeszcze czeka na komplet danych, nie powinna udawać, że transakcja jest niemożliwa.
Dobra strona nie tylko zgłasza problem. Pomaga go rozwiązać
Najprostszy test? Otwórz swoją stronę na telefonie i celowo wykonaj kilka czynności nieidealnie. Wpisuj adres powoli. Pozostaw jedno pole puste. Zrób literówkę w e-mailu, popraw ją i sprawdź, czy komunikat znika. Przerwij wybór dostawy. Sprawdź, czy po problemie z płatnością klient dostaje jasną informację, a jego koszyk pozostaje nienaruszony.
W formularzach warto rozróżnić przynajmniej trzy stany: „potrzebujemy jeszcze informacji”, „wszystko jest poprawne” oraz „wystąpił rzeczywisty błąd”. Ich komunikaty nie mogą sobie przeczyć. Zanim zmienisz treść, sprawdź jednak logikę: jeśli metoda dostawy nie działa z powodu błędu integracji, sama kosmetyka tekstu niczego nie naprawi.
Przy większych sklepach można połączyć testy użyteczności z pomiarem miejsc, w których pojawiają się błędy, oraz analizą kolejnych kroków w lejku. Tylko z zachowaniem prywatności klientów i bez zapisywania wrażliwych danych formularzy. Liczby pokażą, gdzie coś się dzieje; dopiero testy i diagnostyka pomogą ustalić dlaczego.
Właściciel często patrzy na stronę przez pryzmat tego, czy technicznie działa. Kupujący patrzy na nią inaczej: czy rozumiem, co się dzieje, i czy mogę dokończyć to, po co tu przyszedłem? Właśnie dlatego pojedyncze zdanie obok formularza potrafi mieć większe znaczenie niż następna animacja przycisku.
Klient nie musi wiedzieć, dlaczego Twój system czegoś nie rozumie. To Twoja strona powinna wiedzieć, jak mu to wyjaśnić.
Źródła
- WooCommerce, GitHub — potwierdzone zgłoszenie #66632: komunikat „No shipping options” podczas wpisywania kodu pocztowego (15.07.2026) — rzeczywisty przykład błędu.
- W3C / WCAG 2.2 — Understanding Success Criterion 3.3.1: Error Identification — standard dostępności dotyczący identyfikowania błędów.
- W3C / WCAG 2.2 — Understanding Success Criterion 3.3.3: Error Suggestion — wskazówki naprawiania błędów.
- GOV.UK Design System — Error Message (aktualizacje wytycznych m.in. 2024) — praktyka projektowania komunikatów i zachowywania wpisanych danych.
- Baymard Institute — Inline Form Validation — uzupełniające badania użyteczności walidacji formularzy.