Liczba ekranów nie rozwiązuje złych pytań
Długi formularz nie staje się przyjazny tylko dlatego, że podzielono go na cztery części. Jeżeli każde pytanie jest niezrozumiałe albo wymaga danych, których klient jeszcze nie zna, kolejne ekrany jedynie odsuwają moment rezygnacji. Najpierw sprawdź, co jest niezbędne do obsługi zapytania. Krótkie pytanie o oddzwonienie zwykle nie potrzebuje osobnego kreatora.
Podział ma sens, gdy odpowiada naturalnym grupom informacji. W przykładowej firmie organizującej wydarzenia można oddzielić rodzaj spotkania, termin, warunki miejsca i dane kontaktowe. WAI zaleca logiczne etapy, widoczną informację o postępie i możliwość pomijania części opcjonalnych. Nie chodzi o ukrywanie długości formularza, lecz o uporządkowanie decyzji.
Zbuduj ścieżki, a nie tylko kolejne numery
Pytanie o nagłośnienie może być niepotrzebne przy wydarzeniu online, ale ważne podczas spotkania stacjonarnego. Rozpisz zależności w małej tabeli: odpowiedź, następne pytanie i warunek pominięcia. Dla każdej ścieżki sprawdź, czy użytkownik dochodzi do podsumowania. Szczególnie łatwo przeoczyć wariant „nie wiem”, który w realnym zapytaniu może być uczciwszy od przypadkowego wyboru.
Po zmianie wcześniejszej odpowiedzi zdefiniuj los danych z nieaktualnej gałęzi. Nie wysyłaj ukrytej informacji, że klient potrzebuje sali, gdy wybrał już wydarzenie zdalne. Można zachować dane roboczo na potrzeby powrotu, lecz końcowy zestaw musi odpowiadać aktualnym decyzjom. To reguła procesu, którą trzeba sprawdzać również na serwerze.
Pozwól wrócić bez ponownego przepisywania
Przycisk „Wstecz” nie powinien kasować pracy. Zapisuj odpowiedzi między etapami i pokazuj użytkownikowi, które części są gotowe. Jeśli zapis jest wyłącznie chwilowy, nie obiecuj bezterminowego wznowienia. Poinformuj, czy zamknięcie przeglądarki albo wygaśnięcie sesji może usunąć szkic. Dłuższy formularz wymaga takiej decyzji jeszcze przed wyborem technologii.
Nie przechowuj w przeglądarce danych wrażliwych tylko dla wygody implementacji. Rozważ ograniczony szkic po stronie serwera i czas jego usunięcia, dostosowany do realnej potrzeby. Każda metoda ma konsekwencje dla dostępu i prywatności. Formularz nie powinien ujawniać odpowiedzi kolejnej osobie korzystającej z tego samego urządzenia ani dołączać ich do publicznego adresu strony.
Waliduj w odpowiednim momencie
Po przejściu do kolejnego etapu pokaż błędy dotyczące tej części, zachowując prawidłowe odpowiedzi. Komunikat „niepoprawne dane” jest zbyt ogólny; klient powinien wiedzieć, co i w jaki sposób poprawić. Walidacja przeglądarkowa wspiera wygodę, ale nie zastępuje sprawdzenia po stronie serwera. OWASP rozróżnia poprawność formatu oraz zgodność wartości z regułami biznesowymi.
Taką ścieżkę zapytania można przygotować we współpracy z MyTworzymy.pl, która obsługuje firmy w całej Polsce. Warto zacząć od prawdziwych pytań zadawanych przez pracowników, a potem ograniczyć formularz do tych, które rzeczywiście zmieniają wycenę lub sposób kontaktu. Dzięki temu narzędzie nie staje się ankietą zbierającą dane na zapas.
Pokaż podsumowanie przed ostateczną wysyłką
Podsumowanie jest osobnym krokiem kontrolnym, a nie ozdobną kopią formularza. Pogrupuj odpowiedzi i umożliwiaj edycję konkretnej części. Nie pokazuj pytań z pominiętych gałęzi, a brak odpowiedzi opcjonalnej oznacz czytelnie. Wzorzec GOV.UK przewiduje powrót do poprawianego fragmentu oraz ponowne wejście do podsumowania bez zbędnego przechodzenia całej sekwencji.
Przycisk kończący powinien wyjaśniać skutek. „Wyślij zapytanie” znaczy coś innego niż „Zarezerwuj termin”. Jeżeli zespół dopiero oceni możliwość realizacji, napisz to przed kliknięciem i w potwierdzeniu. Nie pokazuj sukcesu wyłącznie po zamknięciu ostatniego ekranu. Musi on wynikać z przyjęcia zgłoszenia przez właściwy mechanizm serwerowy.
Zaplanuj ponowienie i pracę obsługi
Po zerwaniu sieci użytkownik nie wie, czy dane dotarły. Proces powinien umieć rozpoznać ponowienie tego samego zgłoszenia i wyświetlić wynik bez tworzenia przypadkowych kopii. Panel pracownika musi otrzymać spójny zestaw odpowiedzi oraz informację, jaką ścieżką przechodził klient. Nie każ mu odgadywać, czy puste pole było opcjonalne, niewidoczne czy pominięte wskutek błędu.
Przy omawianiu wdrożenia z MyTworzymy.pl dobrze przejść również drugą połowę procesu: kto widzi zgłoszenie, co może zmienić i jak potwierdza odbiór. Właśnie połączenie formularza z codzienną obsługą odróżnia użyteczny program od atrakcyjnego kreatora. Odbiór powinien obejmować zachowanie obu stron, a nie tylko ekran klienta.
Sprawdź cały formularz bez idealnych warunków
Przetestuj zmianę pierwszej odpowiedzi na ostatnim kroku, obrót telefonu, powiększony tekst, cofnięcie w przeglądarce i utratę połączenia. Dodatkowo przejdź wszystkie etapy klawiaturą. Informacja o postępie musi być zrozumiała także wtedy, gdy dana osoba nie rozpoznaje koloru wyróżnionego kółka. Numery i nazwy etapów są ważniejsze od samej animacji.
O skuteczności rozwiązania świadczy możliwość wysłania poprawnego zapytania i jego sprawnej obsługi, nie liczba dodanych funkcji. Zapisz przypadki testowe razem z formularzem. Kiedy za pół roku dojdzie nowe pytanie, będzie wiadomo, które zależności sprawdzić, aby dodatkowa opcja nie uszkodziła działających wcześniej ścieżek.
Warto przygotować także próbę z dwoma otwartymi oknami tego samego formularza. Każdy szkic powinien mieć własną tożsamość albo jasno opisane zasady współdzielenia. Inaczej odpowiedź zmieniona w jednej karcie może zastąpić dane z drugiej, a klient dopiero w wiadomości potwierdzającej zobaczy konfigurację, której nie zamierzał wysłać.