Formularz potrafi zepsuć sprzedaż szybciej niż wolna strona. Użytkownik wpisuje numer telefonu, klika „Wyślij” i dostaje suchy komunikat: „Nieprawidłowe dane”. Bez informacji, co poprawić. Bez wskazania pola. Czasem formularz czyści wszystkie wpisane dane. Wtedy nie mamy problemu technicznego. Mamy utracony kontakt, porzucone zamówienie albo użytkownika, który już nie wróci.
Walidacja formularzy nie polega na tym, żeby blokować błędy za wszelką cenę. Jej zadaniem jest przeprowadzić użytkownika przez formularz tak, aby podał dane w formacie możliwym do obsłużenia przez system. Dobra walidacja działa cicho, szybko i jasno. Zła walidacja krzyczy po fakcie, ukrywa przyczynę problemu i przerzuca odpowiedzialność na użytkownika.
Jak działa walidacja formularza i gdzie powinna się odbywać?
Walidację trzeba rozdzielić na dwa poziomy: walidację po stronie przeglądarki i walidację po stronie serwera. To nie są zamienniki. To dwa różne zabezpieczenia, które pracują na innych etapach.
Walidacja w przeglądarce działa przed wysłaniem formularza. Można ją oprzeć o natywne mechanizmy HTML, między innymi:
required— pole obowiązkowe,type="email"— adres e-mail w podstawowym formacie,type="number"— liczba,minimax— minimalna oraz maksymalna wartość,minlengthimaxlength— długość tekstu,pattern— własny wzorzec, na przykład dla kodu pocztowego,step— skok wartości, przydatny np. przy cenach lub ilościach.
To dobry pierwszy filtr. Jeżeli pole „e-mail” jest puste, nie ma sensu wysyłać formularza na serwer tylko po to, żeby po chwili zwrócić błąd. Przeglądarka może zatrzymać taki formularz od razu.
Nie wolno jednak na tym kończyć. Walidacja po stronie serwera jest obowiązkowa, bo dane z formularza można wysłać z pominięciem przeglądarki: przez skrypt, narzędzie developerskie, aplikację zewnętrzną albo źle skonfigurowane API. Jeżeli serwer ufa tylko temu, co sprawdził frontend, system jest podatny na śmieciowe dane, błędy zapisu, nadużycia i ataki.
Praktyczna zasada jest prosta:
- frontend pomaga użytkownikowi poprawić dane przed wysłaniem,
- backend decyduje, czy dane mogą zostać przyjęte,
- baza danych powinna mieć własne ograniczenia tam, gdzie błąd zapisu byłby kosztowny.
Największy priorytet mają pola krytyczne: e-mail, telefon, hasło, zgody formalne, adres dostawy, NIP, kwoty, liczby sztuk i identyfikatory zamówień. Jeżeli te dane trafią do systemu w złym formacie, problem może pojawić się dopiero później: przy wysyłce, fakturze, kontakcie z klientem albo integracji z CRM.
Dobrze zaprojektowana walidacja nie powinna blokować poprawnych, ale mniej typowych danych. To częsty błąd. Adres e-mail może mieć dłuższą domenę. Nazwisko może zawierać myślnik, apostrof albo polskie znaki. Numer telefonu może mieć prefiks kraju. Kod pocztowy może zależeć od kraju, więc sztywne sprawdzanie formatu 00-000 ma sens tylko wtedy, gdy formularz dotyczy wyłącznie Polski.
W praktyce warto przyjąć zasadę: sprawdzaj tylko to, co naprawdę musisz wiedzieć na danym etapie. Jeżeli użytkownik zapisuje się do newslettera, wystarczy poprawny e-mail i zgoda. Numer telefonu, firma, stanowisko i budżet reklamowy to dodatkowe tarcie. Każde nadmiarowe pole zwiększa ryzyko porzucenia formularza.
Dlaczego same komunikaty błędów nie wystarczą?
Komunikat „Wypełnij poprawnie formularz” jest technicznie prawdziwy, ale użytkowo bezużyteczny. Użytkownik musi wiedzieć trzy rzeczy:
- które pole jest błędne,
- dlaczego jest błędne,
- jak dokładnie je poprawić.
Dlatego dobry komunikat powinien być konkretny. Zamiast „Nieprawidłowy telefon” lepiej napisać: „Podaj numer telefonu w formacie +48 600 000 000 albo 600 000 000”. Zamiast „Hasło jest za słabe”: „Hasło musi mieć minimum 12 znaków i zawierać co najmniej jedną cyfrę”.
Walidacja powinna pojawiać się w odpowiednim momencie. Nie ma sensu pokazywać błędu przy polu e-mail po wpisaniu pierwszej litery. Użytkownik jeszcze nie skończył. Lepszy moment to utrata fokusu z pola, próba przejścia dalej albo wysłanie formularza. Wyjątkiem są pola, w których informacja zwrotna pomaga na bieżąco, na przykład siła hasła, dostępność loginu lub limit znaków.
W formularzach wieloetapowych trzeba dodatkowo uważać na miejsce błędu. Jeżeli użytkownik jest na kroku trzecim, a błąd dotyczy kroku pierwszego, system musi go tam zaprowadzić. Samo czerwone obramowanie niewidocznego pola nie rozwiązuje problemu.
Najlepsze efekty daje połączenie kilku elementów:
- komunikat bezpośrednio pod błędnym polem,
- wyraźne oznaczenie pola,
- zachowanie wpisanych danych po błędzie,
- lista błędów nad formularzem przy dłuższych formularzach,
- fokus ustawiony na pierwsze błędne pole po próbie wysłania,
- tekst błędu dostępny dla czytników ekranu.
Nie należy opierać walidacji wyłącznie na kolorze. Czerwone pole bez tekstu jest problemem dla osób z zaburzeniami widzenia barw, ale też dla każdego, kto korzysta z formularza w pośpiechu albo na słabym ekranie. Błąd musi być opisany tekstem.
Jest jeszcze jeden detal, który widać dopiero w praktyce: formularz nie może karać użytkownika za drobiazgi. Spacje przed i po adresie e-mail można usunąć automatycznie. Numer telefonu można zapisać w jednym standardzie po stronie systemu, nawet jeśli użytkownik wpisał go ze spacjami. Wielkość liter w e-mailu zwykle nie powinna mieć znaczenia przy walidacji. Im więcej prostych korekt wykona system, tym mniej błędów zobaczy użytkownik.
Co robić, a czego nie robić przy walidacji formularzy?
Najpierw trzeba ustalić, które pola są naprawdę potrzebne. To ważniejsze niż wybór biblioteki JavaScript. Krótszy formularz z dobrą walidacją prawie zawsze będzie działał lepiej niż rozbudowany formularz z efektownymi animacjami.
Najwyższy priorytet:
- oznacz pola obowiązkowe,
- sprawdzaj wymagany format już w przeglądarce,
- powtarzaj tę samą walidację po stronie serwera,
- pokazuj błąd przy konkretnym polu,
- nie kasuj danych po nieudanej wysyłce,
- zapisuj dane w jednym spójnym formacie w backendzie.
Drugi poziom, przydatny po uporządkowaniu podstaw:
- dodaj maski wpisywania tam, gdzie pomagają, np. przy numerze telefonu lub dacie,
- stosuj podpowiedzi formatu przed wpisaniem danych,
- pokazuj licznik znaków przy polach z limitem,
- testuj formularz na telefonie, nie tylko na komputerze,
- sprawdzaj formularz z użyciem klawiatury, bez myszy.
Dopiero później warto myśleć o bardziej zaawansowanych mechanizmach: walidacji dostępności loginu w czasie rzeczywistym, zapisie wersji roboczej, automatycznym uzupełnianiu danych firmy po NIP czy integracji z zewnętrznymi bazami. To ma sens wtedy, gdy formularz jest długi, drogi w obsłudze albo dotyczy danych, których błąd generuje realny koszt.
Czego nie robić?
- Nie blokuj wklejania danych do pól. Menedżery haseł, schowek i automatyczne uzupełnianie są normalnym sposobem korzystania z formularzy.
- Nie wymuszaj nietypowego formatu bez pokazania przykładu.
- Nie używaj komunikatów typu „Błąd 400” dla zwykłego użytkownika.
- Nie waliduj pola zbyt wcześnie, zanim użytkownik skończy pisać.
- Nie ukrywaj zgód formalnych w niejasnych etykietach.
- Nie zakładaj, że wszyscy użytkownicy mają polski numer telefonu, polski adres i dwuczłonowy schemat imienia oraz nazwiska.
- Nie stosuj zbyt agresywnych wyrażeń regularnych dla e-maila. Można odrzucić prawidłowe adresy, jeśli wzorzec jest zbudowany pod kilka najpopularniejszych przypadków.
Decyzja graniczna: jeżeli dane mają skutki prawne, finansowe albo logistyczne, nie wystarczy zwykłe sprawdzenie formatu. Adres dostawy powinien być możliwy do obsłużenia przez przewoźnika. NIP powinien mieć poprawną strukturę dla danego kraju. Kwota w formularzu płatności musi być zgodna z tym, co serwer przeliczył samodzielnie. Frontend może pokazać wynik, ale nie powinien być źródłem prawdy.
Przy formularzach kontaktowych warto też dodać zabezpieczenia antyspamowe, ale ostrożnie. CAPTCHA potrafi obniżyć liczbę wysłanych formularzy, szczególnie na urządzeniach mobilnych. Jeżeli spam nie jest dużym problemem, lepiej zacząć od mniej inwazyjnych metod: ukrytego pola typu honeypot, limitu częstotliwości wysyłki, filtrowania podejrzanych treści i walidacji po stronie serwera. CAPTCHA jest sensowna wtedy, gdy prostsze metody nie wystarczają.
Najlepszy test formularza jest banalny: poproś kogoś, kto nie zna projektu, żeby wypełnił go na telefonie. Bez instrukcji. Jeżeli pyta, co ma wpisać, gdzie jest błąd albo dlaczego nie może przejść dalej, problem nie leży po stronie użytkownika. Problem leży w formularzu.
FAQ
Czy walidacja HTML wystarczy do zabezpieczenia formularza?
Nie. Walidacja HTML pomaga użytkownikowi, ale nie zabezpiecza systemu. Każde ważne pole trzeba sprawdzić także po stronie serwera.
Kiedy pokazywać błędy: od razu czy po kliknięciu „Wyślij”?
Najbezpieczniej pokazywać błędy po opuszczeniu pola albo po próbie wysłania formularza. Walidowanie podczas wpisywania ma sens tylko tam, gdzie informacja pomaga użytkownikowi, na przykład przy haśle lub limicie znaków.
Jak napisać dobry komunikat błędu?
Dobry komunikat wskazuje pole, przyczynę i sposób poprawy. Zamiast „Nieprawidłowe dane” lepiej napisać: „Podaj adres e-mail w formacie nazwa@domena.pl”.
Czy warto stosować maski w polach formularza?
Tak, ale tylko tam, gdzie format jest przewidywalny. Maska dla polskiego kodu pocztowego ma sens w formularzu dla Polski. Przy formularzu międzynarodowym może przeszkadzać.
Czy formularz powinien usuwać dane po błędzie?
Nie. To jeden z najgorszych błędów UX. Po nieudanej wysyłce użytkownik powinien zobaczyć swoje dane i poprawić tylko błędne pola.
Od czego zacząć poprawę istniejącego formularza?
Najpierw sprawdź trzy rzeczy: czy błędy wskazują konkretne pola, czy dane nie znikają po błędzie i czy serwer ponownie waliduje wszystkie ważne dane. Dopiero potem poprawiaj detale wizualne, animacje i dodatkowe automatyzacje.
