Im bardziej zagmatwany formularz zamówienia, tym mniej kupujących kończy

Otwórz na żywo formularz zamówienia na telefonie. Policz każde pole, które nie jest potrzebne do wysyłki ani płatności. Jeśli opłacone zamówienia urywają się po koszyku, zwykle winne jest to właśnie – im bardziej zagmatwany formularz zamówienia, tym mniej kupujących kończy.

Część 5 z Konwersja, strona po stronie – pełny plan

Ostatni odcinek serii to strona koszyka potwierdzająca zawartość. Tu jest pobierana płatność. Adres, sposób dostawy, płatność. Formularz, który dodatkowo pyta, skąd gość o nas wie, chce drugi numer telefonu „na wieczory”, i ukrywa Gość pod Utwórz konto, to nie jest dokładność. To sposób, by odwieść od zamówienia, które koszyk już wygrał.

Co musi robić formularz zamówienia

Jedno zadanie: pobrać płatność i adres dostawy. Kto dostaje przesyłkę. Dokąd ją wysłać. Jak wysłać. Jak zapłacić. Potem przycisk Zapłać, który da się rzeczywiście znaleźć.

Koszyk już pokazał pozycje i sumę. Ten formularz zamówienia nie musi ponownie sprzedawać produktu, zbierać ankiety marketingowej ani wymuszać hasła przed kartą. Jeśli pole nie jest wymagane do wysłania zamówienia ani obciążenia karty, nie ma tu miejsca na tym ekranie.

Co sprawia, że formularz zamówienia jest zagmatwany

Najdłuższy, z którym rozplątywaliśmy się w tym roku, to sklep odzieżowy na domyślnym motywie – nic niestandardowego, nic szalonego. Utwórz konto przed kartą. E-mail, potem e-mail jeszcze raz. Hasło, potem potwierdzenie hasła. Firma. VAT. Faks, nadal siedzący tam od 2012 roku. Dwa pola telefonu, jedno z etykietą „wieczór”. Lista rozwijana: skąd o nas wiesz. Newsletter zaznaczony z góry. Pasek postępu mówił Krok 3 z 5 i nie dawał żadnej wskazówki, czym są 4 i 5. Suma siedziała jako drobna linia pod widgetem kuponu. Zapłać mieszkało pod zagięciem, nazwane „Kontynuuj”, więc nikt nie wiedział, że ten klik obciąża kartę.

Nic z tego nie jest egzotyczne. Większość zagmatowanych formularzy zamówienia to zwykłe dodatki układane jeden po drugim – każdy się broni, stos jest śmiertelny.

Najczystszy formularz gościa, jaki wdrożyliśmy, pyta o adres wysyłki, metodę, którą da się przeczytać, płatność, jedno Zapłać. Gość jest domyślny. Konto to propozycja po obciążeniu, jeśli ktoś chce historię zamówień. To samo zadanie co długi formularz. Jeden z nich bierze pieniądze.

Pola, które mogą poczekać aż po płatności

Artykuł Nicka Babicha w Smashing Magazine o formularzach mobilnych streszcza regułę w jednym zdaniu: każde pole to wysiłek, a krócej jest lepiej. Dodatkowe pytania przy rejestracji lub płatności to sposób, by stracić osobę, którą się już miało. Dopytaj później, jeśli potrzebujesz historii. Nie trzymaj karty jako zakładnika za to.

Wytnij lub przenieś z tego ekranu:

• Skąd o nas wiesz
• Zapis do newslettera (zapytaj po Zapłać, bez zaznaczenia z góry)
• Firma i VAT, chyba że kupujący wybrał zamówienie firmowe
• Faks
• Drugi telefon
• Hasło do konta, jeśli gość może zapłacić
• Data urodzenia, „ulubiony kolor”, cokolwiek, co karmi CRM, a nie etykietę wysyłkową

Wymagane do faktury prawnej lub formularza celnego to nie „miło mieć”. Zostaw je. Test jest ten sam: czy to pole wysyła przesyłkę albo obciąża kartę. Jeśli nie – może poczekać.

Zamówienie gościa a mur konta

Wymuszenie logowania przed płatnością to dwa formularze robiące robotę jednego. E-mail już wpisano w koszyku, albo zaraz trzeba go wpisać na paragon. Pytanie o hasło przed kartą to biurko członkostwa między „tak” a pieniędzmi.

Najpierw Gość. Utwórz konto pokaż po obciążeniu, gdy zamówienie istnieje i historia ma sens. Jeśli ktoś już ma konto, logowanie to skrót – nie jedyne wejście. Ukrycie Gościa jako drobnego linku pod wysokim polem logowania to ten sam mur, tylko z gorszymi manierami.

Gdy formularz kasuje to, co już wpisano

Nieudane Zapłać, które czyści formularz, wystarczy, by stracić zamówienie. Kupujący wypełnia adres, wpisuje kartę, klika Zapłać. Coś się sypie – CVV, wymagane pole, kod pocztowy, którego przewoźnik nie akceptuje. Strona się przeładowuje. Numer karty znika. Czasem adres też. Większość ludzi nie zaczyna od nowa. Wychodzi.

Zachowaj to, co wpisano. Oznacz jedno pole, które się wysypało. Nie czyść karty, bo checkbox newslettera był pusty. PCI nie wymaga karania ludzi; wymaga, by nie przechowywać PAN. Przeładowanie, które czyści formularz, to błąd sklepu, nie funkcja bezpieczeństwa.

Ten sam formularz na telefonie

Na mobilnej stronie produktu już walczono z desktopem wrzuconym na telefon. Zamówienie to miejsce, gdzie tę walkę łatwiej przegrać: każde dodatkowe pole to klawiatura na całą szerokość i powiększone pole, a pięć „kroków”, które na 27-calowym monitorze wyglądały schludnie, to pięć osobnych wizyt w autobusie.

Pola na całą szerokość. Etykiety nad polem, nie obok. Klawiatura numeryczna dla karty. Jedna kolumna. Zapłać widoczne bez polowania. Jeśli potrzebny jest drugi ekran, niech to będzie „dane karty” – nie „powiedz, skąd o nas wiesz”.

Otwórz dziś wieczorem formularz na żywo i policz ponownie. Wytnij to, co nie wysyła ani nie obciąża. Koszyk już raz wygrał to zamówienie – jedyne zadanie to nie stracić go na formularzu. Potem spróbuj zapłacić na telefonie jednym kciukiem. Jeśli tu się utknie, utkną kupujący.

Pracuj nad tym z agentem AI

Nie proś agenta o „ulepszenie UX zamówienia”. Podaj mu prawdziwy formularz i każ posortować: wysyłka lub obciążenie vs może poczekać.

Co wkleić: HTML zamówienia albo dwa zrzuty ekranu (desktop + telefon). Jeśli pierwszy ekran to Gość vs konto, wklej i to – plus stan błędu, ekran, który kupujący widzi po nieudanym obciążeniu.

Prompt 1 – inwentaryzacja pól. „Wypisz każde pole i krok w tym zamówieniu. Oznacz każde: potrzebne do wysyłki lub obciążenia, albo może poczekać aż po płatności. Zaproponuj listę do wycięcia. Nie dodawaj funkcji. Nie wymyślaj Express Pay jako naprawy.”

Prompt 2 – ścieżka gościa. „Oto pierwszy ekran zamówienia. Przepisz go tak, by gość mógł zapłacić bez tworzenia hasła. Konto staje się propozycją po obciążeniu.”

Prompt 3 – test czyszczenia. „Oto stan błędu po nieudanej płatności. Wypisz wszystko, co formularz wyczyścił. Przepisz flow tak, by nieudane obciążenie zachowywało każde pole, które kupujący już wpisał.”

Dobry wynik: inwentaryzacja pól, krótsza kolejność bloków i stan błędu, który zachowuje to, co wpisano – coś, co można przekazać motywowi. Nie „ulepsz flow”.