Formularz kontaktowy: ile pól, jakie komunikaty i co obniża liczbę zgłoszeń

Ile pól powinien mieć formularz kontaktowy

Formularz kontaktowy powinien zawierać wyłącznie te pola, bez których firma nie jest w stanie odpowiedzieć na zapytanie. Punkt wyjścia jest prosty: imię, adres e-mail lub numer telefonu oraz pole na wiadomość. Każde kolejne pole wymaga uzasadnienia.

Takie podejście wynika wprost z zaleceń organizacji W3C, która opracowuje standardy sieci. We wstępie do samouczka o formularzach czytamy, że użytkownicy zwykle wolą formularze proste i krótkie, a prośba o dane nieistotne lub nadmiarowe sprawia, że częściej rezygnują z wypełniania.

W praktyce pomocne jest jedno pytanie zadawane przy każdym polu: co zrobimy z tą informacją podczas pierwszej rozmowy z klientem. Jeżeli odpowiedź brzmi "nic" albo "przyda się kiedyś do statystyk", pole można usunąć lub przenieść na późniejszy etap kontaktu. Hydraulik z Łodzi nie potrzebuje w pierwszym zgłoszeniu numeru NIP ani dokładnego adresu z kodem pocztowym - wystarczy mu opis awarii, dzielnica i telefon.

Pola, które zwykle wystarczają

Dla typowej firmy usługowej zestaw podstawowy to imię (bez wymuszania nazwiska), jeden kanał kontaktu i treść wiadomości. Wymaganie telefonu i adresu e-mail jednocześnie jest jedną z częstszych przyczyn rezygnacji, które obserwujemy podczas przeglądów stron: część osób nie chce podawać numeru, a część nie korzysta na co dzień z poczty.

Inaczej wygląda formularz wyceny, w którym bez kilku parametrów nie da się przygotować oferty. Sklep z Poznania sprzedający meble na wymiar potrzebuje wymiarów i rodzaju materiału. Dodatkowe pola są wtedy uzasadnione, pod warunkiem że użytkownik rozumie, po co się je zbiera.

Gdy liczby pól nie da się ograniczyć, W3C zaleca podział długiego formularza na mniejsze części ułożone w logiczne etapy, z informacją o ich liczbie i o postępie, na przykład w nagłówku "Opis zlecenia (etap 2 z 3)".

Które pola oznaczyć jako obowiązkowe i jak to zrobić

Obowiązkowe powinny być tylko te pola, bez których zgłoszenie jest bezużyteczne, a ich status trzeba pokazać zarówno w treści etykiety, jak i w kodzie strony. W formularzu kontaktowym są to zazwyczaj dane do odpowiedzi i treść wiadomości.

Według zaleceń W3C dotyczących instrukcji w formularzach informację o tym, które pola są wymagane, a które opcjonalne, oraz w jakim formacie należy podać dane, powinno się przekazać użytkownikowi wprost. Instrukcję odnoszącą się do całego formularza najlepiej umieścić przed nim. Powód jest techniczny: czytniki ekranu, z których korzystają osoby niewidome, wewnątrz formularza często odczytują same pola i etykiety, więc luźny tekst między polami może zostać pominięty.

Sama gwiazdka przy nazwie pola bywa niezrozumiała, zwłaszcza gdy nigdzie nie wyjaśniono jej znaczenia. Bezpieczniejszy jest dopisek słowny w etykiecie. W przykładzie z części samouczka poświęconej sprawdzaniu poprawności danych etykieta zawiera słowo "wymagane" w nawiasie, a pole otrzymuje atrybut required, który większość współczesnych przeglądarek rozpoznaje.

<p>Pola z dopiskiem "wymagane" są niezbędne do wysłania wiadomości.</p>
<form action="/kontakt/" method="post" id="formularz-kontakt">
  <label for="imie">Imię (wymagane)</label>
  <input type="text" id="imie" name="imie" required autocomplete="given-name">
</form>

Osobną kwestią są zgody i klauzule informacyjne pod formularzem. Ich treść wynika z przepisów o ochronie danych osobowych, dlatego warto omówić ją z prawnikiem.

Dlaczego etykiety powinny stać nad polami, a nie w ich wnętrzu

Etykieta nad polem pozostaje widoczna przez cały czas wypełniania i dobrze sprawdza się na wąskich ekranach, natomiast tekst podpowiedzi wpisany w pole znika po pierwszym znaku. Dlatego każde pole formularza powinno mieć stałą, widoczną etykietę, a podpowiedź w polu może być co najwyżej jej uzupełnieniem.

W3C w części samouczka o etykietowaniu pól wskazuje, że etykiety należy zapewnić wszystkim elementom formularza: polom tekstowym, polom wyboru, przyciskom opcji i listom rozwijanym. Służy do tego element label, którego atrybut for musi dokładnie odpowiadać atrybutowi id pola. Takie powiązanie daje dwie korzyści. Przeglądarka traktuje etykietę jako dodatkowy obszar do kliknięcia, co ułatwia trafienie w małe pole wyboru, a technologie wspomagające potrafią odczytać, czego dane pole dotyczy.

Jeżeli chodzi o położenie, wytyczne opisują przyjęty zwyczaj: przy polach wyboru i przyciskach opcji etykieta stoi po prawej stronie, przy pozostałych polach - po lewej lub bezpośrednio nad nimi. W3C dodaje, że umieszczenie etykiet nad polami na ogół ogranicza konieczność przewijania w poziomie u osób słabowidzących oraz u użytkowników urządzeń mobilnych. Zastrzega jednocześnie, że układ trzeba ocenić indywidualnie, a celem jest bliski i jednoznaczny związek wizualny między etykietą a polem.

Tekst podpowiedzi w polu nie zastępuje etykiety

Tekst podpowiedzi, w kodzie zapisywany w atrybucie placeholder, to jasny napis widoczny w pustym polu. W3C opisuje kilka jego słabości. Zwykle ma niższy kontrast niż tekst wpisany przez użytkownika, więc część osób go nie dostrzega. Znika w chwili rozpoczęcia pisania, przez co trudniej sprawdzić własne odpowiedzi przed wysłaniem. Wreszcie czytniki ekranu nie traktują go jako etykiety.

Formularze, w których nazwy pól istnieją wyłącznie jako znikające podpowiedzi, wyglądają oszczędnie, ale należą do rozwiązań, które najczęściej poprawiamy przy okazji prac nad stronami. Podpowiedź warto zostawić tam, gdzie pełni rolę przykładu, a nazwę pola przenieść do etykiety. Wskazówkę o oczekiwanym formacie najprościej, i według W3C niezawodnie, dopisać w treści samej etykiety.

<label for="telefon">Numer telefonu (dziewięć cyfr, wymagane)</label>
<input type="tel" id="telefon" name="telefon" required autocomplete="tel">

Jak typ pola i autouzupełnianie skracają wypełnianie

Właściwie dobrany typ pola sprawia, że telefon wyświetla klawiaturę dopasowaną do rodzaju danych, a przeglądarka sama proponuje zapisane wcześniej informacje. Użytkownik wpisuje wtedy mniej znaków, co na małym ekranie ma duże znaczenie.

Kurs o formularzach w serwisie web.dev, prowadzonym przez Google, wyjaśnia, że na podstawie atrybutu type przeglądarka wyświetla różne interfejsy i różne klawiatury ekranowe oraz stosuje różne reguły sprawdzania. W formularzu kontaktowym dotyczy to przede wszystkim pól typu email i tel. W3C dodaje, że starsze przeglądarki, które tych typów nie znają, pokazują je jako zwykłe pola tekstowe, więc ich zastosowanie niczego nie psuje.

Drugim ułatwieniem jest autouzupełnianie. Jak opisuje rozdział web.dev poświęcony tej funkcji, przeglądarki zapamiętują wcześniej wpisane dane i proponują je w kolejnych formularzach, a twórca strony pomaga im dobrać właściwą podpowiedź, nadając polom odpowiednie wartości atrybutu autocomplete, na przykład email dla adresu poczty. Z tym samym mechanizmem wiąże się kryterium standardu dostępności WCAG dotyczące określenia przeznaczenia pola: programowe wskazanie, jakiego rodzaju danych oczekuje pole, ułatwia wypełnianie formularzy zwłaszcza osobom z niektórymi trudnościami poznawczymi.

Sprawdzanie danych powinno być wyrozumiałe

Formularz powinien akceptować różne sposoby zapisu tej samej informacji. W3C podaje przykład numerów telefonów, które ludzie zapisują z różnymi separatorami i w różnych grupach cyfr, i zaleca, aby sprawdzanie poprawności było możliwie tolerancyjne. Formularz odrzucający numer ze spacjami albo z prefiksem kraju zmusza użytkownika do zgadywania, o jaki zapis chodzi. Łatwiej usunąć zbędne znaki po stronie serwera, niż wymagać od klienta jednego ustalonego formatu.

W tych samych wytycznych znajduje się zastrzeżenie techniczne: sprawdzanie danych w przeglądarce poprawia wygodę, ale można je ominąć, dlatego dane trzeba weryfikować także po stronie serwera. W3C zwraca też uwagę na limity czasu - o ile to możliwe, formularz nie powinien wygasać w trakcie wypełniania. Na stronach firmowych kłopot pojawia się zwykle wtedy, gdy zabezpieczenie przed spamem traci ważność i starannie pisana wiadomość nie zostaje wysłana.

Dobór typów pól, ich kolejność i sposób działania na telefonie planujemy już na etapie makiety, w ramach projektowania UX.

Jeśli chcą Państwo zamówić stronę internetową, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Jak pisać komunikaty błędów, które pomagają dokończyć zgłoszenie

Dobry komunikat błędu mówi trzy rzeczy: którego pola dotyczy, co jest nie tak i jak to poprawić. Sama czerwona ramka albo ogólne zdanie o nieprawidłowych danych pozostawia użytkownika bez wskazówki, co ma zrobić.

Wymóg ten zapisano w standardzie WCAG. Zgodnie z objaśnieniem kryterium identyfikacji błędu po nieudanej próbie wysłania nie wystarczy ponownie wyświetlić formularza bez żadnej informacji o niepowodzeniu. Błąd musi zostać wskazany tekstem, razem z określeniem pola, w którym wystąpił. W3C pokazuje różnicę na przykładzie adresu poczty: komunikat stwierdzający jedynie, że adres jest nieprawidłowy, spełnia wymóg wskazania błędu, ale dopiero prośba o podanie adresu w formacie nazwa@domena podpowiada także sposób naprawy.

W części samouczka o powiadomieniach dla użytkownika W3C opisuje dwa uzupełniające się poziomy informacji zwrotnej. Pierwszy to lista błędów umieszczona nad formularzem, z wyraźnym nagłówkiem. Każda jej pozycja powinna odwoływać się do etykiety pola, zwięźle opisywać błąd, podpowiadać poprawkę i zawierać odnośnik prowadzący do właściwego pola. Drugi poziom to komunikat tekstowy przy samym polu, połączony ze wskazówką wizualną, na przykład ikoną i ramką. Jeżeli wysłane dane zawierają błędy, wygodnie jest też ustawić kursor w pierwszym błędnym polu.

Gdy formularz działa bez przeładowania strony, lista błędów pojawia się dynamicznie. W3C zaleca wtedy nadać jej kontenerowi atrybut role o wartości alert, aby technologie wspomagające poinformowały o zmianie. Bez tego osoba niewidoma może nie dowiedzieć się, że wiadomość nie została wysłana.

Ton komunikatów również ma znaczenie: lepiej sprawdza się rzeczowy opis i uprzejma prośba niż sformułowania obwiniające użytkownika. Bardzo ważne jest też to, by po błędzie formularz nie usuwał wpisanej treści - utrata dłuższej wiadomości jest, według naszych obserwacji, jednym z najpewniejszych sposobów na utratę zapytania.

Potwierdzenie wysłania i treść przycisku

Po wysłaniu formularza użytkownik musi otrzymać wyraźne potwierdzenie, że wiadomość dotarła, a przycisk powinien nazywać czynność, którą faktycznie uruchamia. Oba elementy są krótkie, ale w dużym stopniu decydują o tym, czy klient ma poczucie załatwionej sprawy.

W3C podkreśla, że komunikaty o powodzeniu są ważne, ponieważ potwierdzają wykonanie zadania. Wytyczne wymieniają kilka sposobów przekazania takiej informacji, które można łączyć: główny nagłówek strony z podziękowaniem, tytuł strony (użytkownik czytnika ekranu słyszy go od razu po załadowaniu) oraz okno dialogowe, przydatne wtedy, gdy inne formy łatwo przeoczyć.

Na stronach firmowych stosuje się dwa rozwiązania. Pierwsze to osobna strona z podziękowaniem, jednoznaczna i łatwa do zmierzenia. Drugie to komunikat wyświetlany w miejscu formularza, bez przeładowania strony. Tu najczęstszym błędem jest mały napis pod przyciskiem, który na telefonie znajduje się poza widocznym obszarem ekranu. Użytkownik nie widzi zmiany, naciska przycisk ponownie i firma otrzymuje to samo zgłoszenie kilka razy.

Co napisać w potwierdzeniu

Dobre potwierdzenie odpowiada na pytania, które klient zadałby przy okienku: czy wiadomość doszła, kto się odezwie, w jakiej formie i kiedy. Zdanie w rodzaju "Dziękujemy, wiadomość została wysłana. Odpowiadamy w dni robocze na podany adres poczty" jest lepsze niż samo "Dziękujemy". Deklarowany czas odpowiedzi musi być prawdziwy. Warto też podać numer telefonu dla osób, których sprawa jest pilna.

Jak nazwać przycisk

Zgodnie z opisem W3C etykietę przycisku umieszcza się wewnątrz elementu button i to ona informuje, co się stanie po jego użyciu. Ogólne polecenie wysłania, domyślne w wielu wtyczkach, jest poprawne, ale niczego nie obiecuje. Konkretniejsze brzmienie lepiej zamyka formularz: "Wysyłam zapytanie", "Zamawiam rozmowę telefoniczną", "Proszę o wycenę". Treść przycisku powinna zgadzać się z nagłówkiem formularza i z tym, co rzeczywiście nastąpi - jeżeli przycisk zapowiada wycenę, klient oczekuje wyceny, a nie rozmowy handlowej.

Warto również zadbać o stan przycisku po naciśnięciu: krótka informacja o trwającym wysyłaniu i zablokowanie ponownego kliknięcia ograniczają liczbę zdublowanych zgłoszeń. O tym, jak formularz współgra z nagłówkiem i treścią oferty, piszemy we wpisie o budowie strony docelowej, która zamienia ruch w zapytania.

Co najczęściej obniża liczbę zgłoszeń

Liczbę zgłoszeń obniżają przede wszystkim zbędne pola, niejasne oczekiwania wobec użytkownika i błędy, których nie potrafi on samodzielnie naprawić. Poniższe zestawienie łączy zalecenia W3C z problemami, które najczęściej znajdujemy podczas przeglądów stron firmowych; objawy opisane w drugiej kolumnie to obserwacje z praktyki agencji, a nie wyniki badań.

Osobną grupą są problemy, które leżą w otoczeniu formularza. Formularz umieszczony wyłącznie na podstronie kontaktowej zbiera mniej zapytań niż formularz dostępny tam, gdzie klient podejmuje decyzję, czyli na stronie usługi. Znaczenie ma też zaufanie: brak informacji o tym, kto odpowie i w jakim czasie. Szerzej o zależności między wygodą a wynikami piszemy we wpisie UX a SEO: jak wygoda użytkownika przekłada się na widoczność i sprzedaż, a o treści poprzedzającej formularz - we wpisie o opisywaniu oferty na stronie usługi.

Jak mierzyć rozpoczęte i wysłane zgłoszenia

Najprostszym sposobem jest pomiar zaawansowany w Google Analytics, który bez zmian w kodzie strony rejestruje dwa zdarzenia: form_start i form_submit. Porównanie ich liczby pokazuje, jaka część osób rozpoczynających wypełnianie doprowadza je do końca.

Jak wyjaśnia strona pomocy Zdarzenia objęte pomiarem zaawansowanym, zdarzenie form_start jest wywoływane przy pierwszej interakcji użytkownika z formularzem w ramach sesji, a form_submit - gdy użytkownik przesyła formularz. Do zdarzeń dołączane są parametry: form_id (atrybut id formularza), form_name (atrybut name), form_destination (adres, pod który formularz jest przesyłany), a przy przesłaniu także form_submit_text, czyli tekst przycisku. Aby korzystać z tych parametrów w raportach, trzeba utworzyć dla nich wymiary niestandardowe.

1. Włączenie pomiaru

   Na stronie Administracja, w sekcji Zbieranie i modyfikowanie danych, należy wejść w Strumienie danych i wskazać strumień swojej witryny. W części Pomiar zaawansowany znajduje się przełącznik oraz ustawienia poszczególnych opcji, w tym Interakcje z formularzem. Zmiana wymaga roli Edytujący lub wyższej.

2. Odczyt liczby zdarzeń

   Dane o wywołanych zdarzeniach znajdują się w raporcie Zdarzenia w temacie Zaangażowanie. Wiersze form_start i form_submit pokazują liczbę rozpoczęć i wysłań w wybranym okresie.

3. Analiza ścieżki

   W technice Eksploracja ścieżki kolejne kroki definiuje się na podstawie zdarzeń: wejście na stronę z formularzem, rozpoczęcie wypełniania, wysłanie.

Eksploracja ścieżki, opisana na stronie pomocy poświęconej tej technice, pozwala podzielić wyniki według wybranego wymiaru. Po ustawieniu podziału na wymiar Kategoria urządzenia widać, czy formularz jest porzucany częściej na telefonach niż na komputerach. Można też włączyć wyświetlanie średniego czasu między krokami.

Strona z podziękowaniem jako pewniejszy sygnał

Z naszych obserwacji wynika, że formularze wysyłane bez przeładowania strony bywają rejestrowane niedokładnie, a zdarzenia mogą obejmować również inne formularze, na przykład wyszukiwarkę. Dlatego wyniki warto porównać z rzeczywistą liczbą wiadomości w skrzynce.

Pewniejszym sygnałem jest wejście na stronę z podziękowaniem. Pomoc Google w artykule Tworzenie i modyfikowanie kluczowych zdarzeń opisuje dokładnie taki przypadek: na podstawie zdarzenia page_view i adresu strony potwierdzenia tworzy się nowe zdarzenie, które następnie można oznaczyć jako kluczowe i w ten sposób liczyć osoby, które przesłały dane kontaktowe. Samego page_view nie należy oznaczać jako kluczowego, bo wtedy liczone byłyby wszystkie odsłony. Zdarzenie tworzy się na stronie Administracja, w sekcji Wyświetlanie danych, w pozycji Zdarzenia, metodą bez kodu.

Wynik warto porównywać z poprzednim stanem tego samego formularza: zapisać stosunek wysłań do rozpoczęć, wprowadzić jedną poprawkę i sprawdzić wartość po kilku tygodniach. Konfigurację zdarzeń i raportów przygotowujemy w ramach usługi analityka i raportowanie SEO, a te same kluczowe zdarzenia przydają się później do oceny kampanii Google Ads.

Jak samodzielnie przejrzeć formularz i kiedy potrzebna jest pomoc

Przegląd formularza najlepiej zacząć od wypełnienia go na telefonie tak, jak zrobiłby to klient, a następnie celowo popełnić kilka błędów. Większość opisanych wcześniej problemów widać w ciągu kilkunastu minut, bez specjalistycznych narzędzi.

Pierwsza próba to zwykłe zgłoszenie: ile czasu zajmuje, czy klawiatura pasuje do pola, czy przeglądarka podpowiada zapisane dane, czy po wysłaniu widać potwierdzenie bez przewijania. Druga próba to wysłanie pustego formularza i ocena, czy komunikaty wskazują konkretne pola. Trzecia - wpisanie numeru telefonu ze spacjami i z prefiksem kraju oraz adresu poczty z literówką. Czwarta - przejście przez wszystkie pola samym klawiszem Tab, bez myszy, co pokazuje, czy kolejność jest logiczna i czy przycisk da się uruchomić z klawiatury.

• Każde pole jest potrzebne do udzielenia pierwszej odpowiedzi.
• Pola obowiązkowe i opcjonalne są opisane słowami.
• Każde pole ma widoczną etykietę, a kliknięcie etykiety ustawia kursor w polu.
• Podpowiedzi wewnątrz pól służą wyłącznie jako przykłady.
• Pola adresu poczty i telefonu mają właściwe typy oraz wartości autouzupełniania.
• Komunikat błędu wskazuje pole, opisuje problem i podpowiada poprawkę.
• Po błędzie wpisane dane pozostają w formularzu.
• Potwierdzenie wysłania jest widoczne na telefonie i informuje, co nastąpi dalej.
• Zgłoszenie próbne dociera na właściwą skrzynkę, a w Google Analytics pojawia się odpowiednie zdarzenie.

Część poprawek można wprowadzić samodzielnie w ustawieniach wtyczki formularza: usunąć pola, zmienić etykiety, treść komunikatów i przycisku, ustawić przekierowanie na stronę z podziękowaniem. Pomoc wykonawcy przydaje się wtedy, gdy zmiana dotyczy kodu szablonu - powiązania etykiet z polami, zachowania formularza po błędzie, sprawdzania danych po stronie serwera albo podziału na etapy. Wsparcie jest też wskazane, gdy dane z Google Analytics i liczba wiadomości w skrzynce wyraźnie się różnią, bo zwykle oznacza to błąd w konfiguracji pomiaru lub w dostarczaniu poczty.

Przy nowych realizacjach formularz planujemy razem z całą stroną: ustalamy, jakie zapytania firma chce otrzymywać, kto na nie odpowiada i jakich informacji potrzebuje. Dotyczy to zarówno serwisów powstających w ramach usługi tworzenie stron, jak i pojedynczych stron kampanii, czyli usługi landing page. O tym, gdzie umieścić sekcję kontaktu, piszemy we wpisie o układzie sekcji strony głównej firmy. Trzeba przy tym uczciwie zaznaczyć, że nawet najlepiej zaprojektowany formularz nie zastąpi ruchu na stronie i dobrej oferty - usuwa przeszkody na ostatnim odcinku drogi klienta, ale nie tworzy popytu.

Jeśli chcą Państwo zamówić stronę internetową, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl