Formularze irytujące klientów trochę mniej... a może wcale?

Zamawiając produkt przez internet, wypełniasz skrupulatnie formularz (a przynajmniej tak Ci się wydaje). Przechodzisz przez wszystkie wymagane pola, a na koniec dostajesz powiadomienie o konieczności potwierdzenia kodem, który zostanie wysłany przez sms.

No i spoko, czekasz, nie ma, klikasz wyślij ponownie, dalej nic. “Kurde co jest grane?!” No dobra, nie ma to jak rozwiązanie siłowe! SMS za smsem, odśwież, odśwież, ODŚWIEŻ! Z każdym kliknięciem narasta w Tobie chęć unicestwienia sprzętu wraz z całą infrastrukturą, a potem światem niczym ludzka czarna dziura.

Po chwili obwiniania wszystkiego dookoła oraz nieugiętego i walecznego wciskania przycisku “wyślij nowy kod” patrzysz… Ups końcówka numeru telefonu się nie zgadza… Osoba posiadająca ten źle wpisany numer musiała mieć ciekawe doświadczenie.

Zaczynasz rozmyślać… przecież można by tego uniknąć - wykorzystując weryfikację… A teraz nic tylko anulowanie umowy i wycieczka na początek formularza, aby całą przygodę rozpocząć od nowa, czy będzie to droga do mordoru?

I właśnie takie formularze sprawiają, że użytkownik rzuca myszką o ścianę. Bo nie — po co ułatwiać życie klientowi, skoro można je komplikować?

Kilka stopni weryfikacji formularzy.

Pamiętasz zamierzchłe lata 2000 i początek 2010? Internet był wtedy dzikim zachodem. Web 2.0: MySpace pozwalał każdemu wrzucać na stronę GIF-y, playlisty i czcionki, które łamały oczy, wszystko wyglądało jakby zwymiotowała na to zmutowana tęcza prosto z żakietu Liberace. Facebook dopiero zaczynał swoją misję “możesz wyglądać jak chcesz, o ile będzie to zgodne z naszą wizją”.

Formularze? Cóż… w tamtych czasach pole typu „email” w HTML jeszcze raczkowało, więc wszystko, co można było wypełnić, było zdefiniowane jako type="text" (czyli pole do wpisania tekstu) lub textarea (większe pole tekstowe) dla większej ilości treści.

Oznaczało to tyle, że:

• mogłeś wpisać jan@kowalski i system radośnie to przyjmował,
• walidacja? chciałbyś — całe sprawdzanie przerzucano na serwer,
• użytkownik dowiadywał się o błędzie dopiero po kliknięciu „Wyślij” i odświeżeniu strony,
• a jak coś nie grało… wracałeś do pustego formularza i zaczynałeś od zera.

Weryfikacja numeru telefonu? Ha! Jedyne, co mogłeś zrobić, to liczyć, że użytkownik dobrowolnie poda poprawny numer, bo inaczej nikt się z nim nie skontaktuje. Zero sugestii, zero podpowiedzi, zero UX - wyobraź sobie, że to, co obecnie jest dostępne nie było nawet w planach.

Wyglądało to mniej więcej tak:

I wtedy pojawił się HTML5. Nagle type="email", type="tel", required czy pattern zaczęły ratować sytuację.

Przeglądarka zaczęła podpowiadać: „hej, to nie wygląda jak e-mail”, zanim jeszcze serwer dostał szansę. Rewolucja? Raczej ewolucja, ale wydaje się być czymś niesamowitym i o ile nie widzisz tego tak jak ja, to rozwój tego daje jedno: większą wygodę dla użytkownika i lepszą kontrolę dla programistów.

Ewolucja formularzy – timeline.

• 2005
  Wszystko było type="text"
  E-mail, numer telefonu, adres – wszystko wrzucane w jedno pole. Literówki? Normalka. System radośnie przyjmował nawetasdfgh.
• 2008
  Walidacja tylko po stronie serwera
  Klikasz „Wyślij”, strona się przeładowuje, a Ty dostajesz komunikat: „Błąd w polu 3”. Formularz pusty, więc wpisujesz wszystko od nowa. Idealny przepis na rage quit.
• 2010
  Pierwsze walidacje w JavaScript
  Regexy, które sprawdzały, czy jest „@” w adresie e-mail. W praktyce a@b przechodziło bez problemu. Obsługa klienta w firmach tonęła w „prawdziwych” adresach e-mail typu asd@asd.
• 2012
  HTML5 zmienia zasady gry
  Pojawiają się nowe typy pól: email, tel, url, number. Do tego requiredipattern. Przeglądarka nagle zaczyna pomagać użytkownikowi i blokuje część głupich błędów jeszcze przed wysyłką.
• 2025
  UX-first: autocomplete, inputmode, live validation.
  Formularze prowadzą za rękę. Podpowiadają dane, pokazują odpowiednią klawiaturę na mobile, zapisują postęp. Mniej frustracji, więcej konwersji. I zero wymówek, że „nie da się tego zrobić”.

Rozwinięcie edycji formularzy poszło w dobrym kierunku, to ale nie oznacza jednak, że wszystko jest bezobsługowe.

Jakie rodzaje podpowiedzi są do dyspozycji?

Dobra, pola wybrane ale co dalej, bo przecież do pola tekstowego możesz wpisać co ci się żywnie podoba, a pole numeryczne to nie musi być ilość … jaką chcesz zamówić, aby wreszcie rozliczyć się ze znajomym.

Tutaj pojawia się nowe dziecko - autocomplete, które jest informacją dla przeglądarek - słuchaj bro, ziom (i inne stwierdzenia, które jednoznacznie pokażą mój wiek na tle młodych) tu ma być "coś". Informacja ta daje przeglądarce instrukcje - słuchaj wiem, że zapisujesz wszystkie dane, jakie wpisuję do formularzy, aby (oczywiście) pomóc mi w przyszłości nie popełniać tylu błędów. Wykorzystaj te informacje i podpowiedź mi tutaj to, co potrzeba wpisać do formularza - a co to jest, to sugeruje właśnie autocomplete

Najczęściej używane wartości autocomplete

Powtórka z rozrywki, czyli zabezpiecz kluczowe pola.

Możesz mieć najlepsze autocomplete, walidacje w locie i nawet podpowiadającą klawiaturę… ale jeśli użytkownik na nowym komputerze wpisze zły numer telefonu, to i tak skończy on jak ja w mojej historii z SMS-ami.

Dlatego dla kluczowych pól lepiej dodać drugą linię obrony:

• e-mail → pole „powtórz e-mail” (tak, trochę nudne, ale ratuje przed literówkami typu gmial.com),
• numer telefonu → powtórne wpisanie albo wyraźne podglądnięcie ostatnich cyfr z możliwością edycji,
• hasło → klasyka: „wpisz ponownie hasło” (z opcją pokaż/ukryj, żeby nie pisać na ślepo), w dobie managerów haseł może się to wydawać zbędne, ale przydatne w przypadku dostępów, gdzie nie powinny one być zapisywane.

Przykład:

Numer telefonu

Powtórz numer telefonu

Tak, to oznacza dwa dodatkowe kliknięcia.
Ale w zamian unikasz sytuacji, że klient kończy cały proces… i wszystko idzie w kosmos, bo jedna cyfra była źle.

Podsumowanie.

Okej, wpisywanie telefonu podwójnie, potrójnie, do tego jeszcze dwa razy e-mail to nie jest marzenie żadnego użytkownika. To raczej szybka droga do tego, żeby stwierdził: „a może zrobię coś mniej stresującego… na przykład zapłacę podatki”.

Kiedy więc stosować te dodatkowe zabezpieczenia?

Pomyśl o sytuacjach, gdzie błąd naprawdę kosztuje: wniosek kredytowy, założenie konta w banku, rejestracja na szkolenie, które wymaga potwierdzenia przez SMS. Jeśli w takim procesie okaże się, że w numerze telefonu albo e-mailu zabrakło jednej cyfry, a formularz tego nie wyłapał — to sorry, ale cała zabawa zaczyna się od nowa. Zero cofnięcia, zero ratunku, tylko powtórka z rozrywki.

Dlatego zasada jest prosta: powtarzaj tylko pola krytyczne (telefon, e-mail, hasło). Resztę ogarnie autocomplete, inputmode i walidacja w locie. Dzięki temu nie zabijasz konwersji, a jednocześnie ochronisz użytkownika przed katastrofą na samym końcu drogi.

Formularze to z pozoru prosta sprawa, ale w praktyce często decydują o tym, czy użytkownik zostanie Twoim klientem, czy pójdzie gdzie indziej. Warto więc patrzeć szerzej – na całą podróż użytkownika, architekturę informacji i wygodę procesu. Bo każda sekunda frustracji to sekunda, w której Twój konkurent właśnie przejął klienta.

Na koniec kilka statystyk które pokazują jak wielkim problemem a jednocześnie szansą jest wykorzystanie tej wiedzy przy projektowaniu formuarzy.

Masz formularz, który wygląda jakby utknął w 2005 roku?

Użytkownicy porzucają go szybciej niż ankietę w ZUS-ie, a Ty zastanawiasz się, czemu nikt nie klika „Wyślij”?

Umów się ze mną na krótką rozmowę. Zrobię audyt Twoich formularzy i pokażę Ci, jak za pomocą prostych zmian (autocomplete, inputmode, walidacja w locie) sprawić, że klienci będą je wypełniać do końca - zamiast rzucać laptopem o ścianę.

O autorze.

Od lat związany z szeroko rozumianą informatyką. Pierwszą stronę stworzyłem w liceum, za co otrzymałem wyróżnienie.

Ciągle uczę się, aby dorównać tempu rozwoju nowoczesnych technologii łącząc je z wiedzą o psychologii aby zwiększać skuteczność stron i aplikacji internetowych.