Klient znalazł produkt, wybrał odpowiedni wariant i chce go kupić. Z perspektywy sklepu najtrudniejsza część wydaje się wykonana.
A jednak właśnie w koszyku i podczas składania zamówienia może pojawić się bariera, która sprawi, że część użytkowników nie będzie w stanie dokończyć zakupu.
Niedostępny formularz, niewidoczny fokus klawiatury, problem z wyborem punktu odbioru, niezrozumiały komunikat błędu czy niedostępna bramka płatnicza mogą skutecznie zatrzymać klienta tuż przed płatnością.
Dlatego dostępności checkoutu nie warto oceniać ekran po ekranie. Najlepiej przejść całą ścieżkę dokładnie tak, jak robi to klient.
Co oznacza dostępny proces zakupowy?
Dostępny checkout powinien pozwolić użytkownikowi samodzielnie przejść od koszyka do potwierdzenia zamówienia.
W praktyce oznacza to możliwość:
- sprawdzenia produktów znajdujących się w koszyku,
- zmiany liczby produktów lub ich usunięcia,
- uzupełnienia danych klienta i adresu,
- wyboru sposobu dostawy,
- wyboru metody płatności,
- zrozumienia i poprawienia błędów formularza,
- sprawdzenia ceny i podsumowania zamówienia,
- złożenia zamówienia,
- otrzymania jednoznacznego potwierdzenia, że operacja się udała.
Problem polega na tym, że proces zakupowy często składa się z wielu niezależnych elementów. Motyw sklepu może pochodzić od jednego dostawcy, formularz od drugiego, wybór punktu odbioru od firmy kurierskiej, a płatność od operatora płatności.
Każdy z tych elementów może działać poprawnie osobno, a cały proces nadal może być niedostępny.
Zacznij od prawdziwego scenariusza zakupowego
Zamiast sprawdzać osobno koszyk, formularz i płatności, przygotuj jedno konkretne zamówienie testowe.
Przykładowy scenariusz może wyglądać tak:
- Znajdź produkt posiadający kilka wariantów.
- Wybierz wariant i dodaj produkt do koszyka.
- Zmień jego liczbę.
- Przejdź do checkoutu.
- Uzupełnij dane klienta.
- Celowo wpisz nieprawidłowy kod pocztowy.
- Wybierz sposób dostawy.
- Wybierz punkt odbioru, jeśli sklep udostępnia taką możliwość.
- Popraw wcześniej wprowadzony błąd.
- Wybierz metodę płatności.
- Sprawdź podsumowanie i złóż zamówienie.
Najlepiej wykonywać taki test na środowisku testowym, aby nie uruchamiać rzeczywistych płatności, wysyłek czy procesów magazynowych.
Scenariusz można później powtarzać po każdej większej zmianie w sklepie. Jest znacznie bardziej użyteczny niż ogólne polecenie „sprawdź dostępność checkoutu”, ponieważ dokładnie określa oczekiwany rezultat.
Spróbuj kupić produkt bez używania myszy
Jednym z podstawowych testów jest przejście całego procesu przy użyciu klawiatury.
Nie używaj myszy ani touchpada. Korzystaj między innymi z klawiszy Tab, Shift + Tab, Enter, Spacja i klawiszy kierunkowych.
Podczas testu zwracaj uwagę na kilka rzeczy:
- czy zawsze wiadomo, który element ma aktualnie fokus,
- czy kolejność przechodzenia między elementami jest logiczna,
- czy można zmienić liczbę produktów,
- czy można zaznaczyć checkboxy i opcje dostawy,
- czy można otwierać i zamykać listy oraz okna modalne,
- czy da się wybrać punkt odbioru,
- czy wszystkie przyciski można uruchomić bez myszy,
- czy w żadnym miejscu fokus nie zostaje uwięziony.
Szczególnej uwagi wymagają elementy bardziej rozbudowane: mapy punktów odbioru, własne selecty, kalendarze, slidery, popupy oraz widgety zewnętrznych dostawców.
Jeżeli użytkownik może otworzyć okno wyboru dostawy klawiaturą, ale nie może go zamknąć albo przejść do kolejnego elementu, proces zakupowy jest w praktyce zablokowany.
Nie zapisuj tylko „nie działa klawiatura”
Jeżeli podczas testu znajdziesz problem, sposób jego opisania ma duże znaczenie dla osoby, która będzie go naprawiała.
Informacja:
Wybór dostawy nie działa z klawiatury.
jest mało precyzyjna.
Znacznie bardziej użyteczny będzie opis:
Po otwarciu okna wyboru punktu odbioru fokus przechodzi do pierwszego elementu na mapie, ale za pomocą klawisza Tab nie można przejść do przycisku zamknięcia ani wrócić do formularza zamówienia.
Developer może wtedy odtworzyć dokładnie ten sam scenariusz i sprawdzić, czy wdrożona poprawka rzeczywiście rozwiązała problem.
Formularz checkoutu jest jednym z najważniejszych miejsc całego procesu.
Każde pole powinno mieć zrozumiałą etykietę, a wymagane informacje powinny być jasno określone. Sam placeholder wewnątrz pola nie zawsze jest wystarczającym zamiennikiem etykiety.
Szczególnie ważne jest zachowanie formularza po wystąpieniu błędu.
Komunikat:
Nieprawidłowe dane.
niewiele mówi użytkownikowi.
Znacznie bardziej pomocna będzie informacja:
Sprawdź kod pocztowy. Wpisz go w formacie 00-000.
Oczywiście taki format powinien być wymagany tylko wtedy, gdy rzeczywiście wynika z wybranego kraju.
W3C wskazuje między innymi na potrzebę identyfikowania błędów i przekazywania użytkownikowi informacji pomagającej je poprawić.
Źródło: W3C – User Notifications
Co dzieje się po wystąpieniu błędu?
Sam tekst komunikatu to tylko część problemu.
Celowo popełnij błąd pod koniec formularza i sprawdź, co wydarzy się po próbie złożenia zamówienia.
Czy użytkownik dowie się, które pole jest błędne? Czy fokus zostanie przeniesiony w odpowiednie miejsce? Czy wcześniej wprowadzone dane pozostaną w formularzu? Czy trzeba ponownie wybierać dostawę lub metodę płatności?
Jeżeli drobny błąd w jednym polu powoduje konieczność ponownego uzupełnienia całego zamówienia, użytkownik wykonuje niepotrzebną pracę.
W skrajnym przypadku może po prostu zrezygnować z zakupu.
Sprawdź dynamiczne zmiany ceny, dostawy i płatności
Checkout rzadko jest statycznym formularzem.
Wybranie kraju może zmienić dostępne metody dostawy. Wybór kuriera może zmienić cenę. Konkretna metoda dostawy może wpłynąć na dostępne płatności. Kod rabatowy może zmienić całkowitą wartość zamówienia.
Za każdym razem warto sprawdzić, czy użytkownik otrzymuje informację o takiej zmianie.
Dotyczy to szczególnie osób korzystających z czytników ekranu. Sama zmiana tekstu w DOM nie gwarantuje jeszcze, że użytkownik zostanie o niej poinformowany we właściwym momencie.
Testy z czytnikiem ekranu powinny być wykonywane przez osobę, która potrafi prawidłowo korzystać z takiego oprogramowania i ocenić nie tylko obecność informacji, ale również jej kolejność i kontekst.
Nie zapominaj o zewnętrznych modułach
Jednym z częstszych problemów w ecommerce jest założenie, że za dostępność zewnętrznego modułu odpowiada wyłącznie jego dostawca.
Z technicznego punktu widzenia możliwość wprowadzenia zmian rzeczywiście może być ograniczona. Z perspektywy klienta nie ma to jednak większego znaczenia.
Jeżeli nie może wybrać paczkomatu albo zapłacić za zamówienie, po prostu nie może zakończyć zakupu.
Dlatego w testach należy uwzględnić również:
- widgety firm kurierskich,
- mapy punktów odbioru,
- zewnętrzne systemy płatności,
- systemy ratalne,
- mechanizmy logowania zewnętrznego,
- CAPTCHA i inne mechanizmy zabezpieczające.
Jeżeli problem znajduje się w zewnętrznym rozwiązaniu, warto przygotować dla dostawcy konkretne zgłoszenie zawierające kroki odtworzenia, opis problemu oraz oczekiwane zachowanie.
Jeżeli poprawa nie jest możliwa, należy rozważyć alternatywny sposób wykonania zadania albo inne rozwiązanie techniczne.
Automatyczny audyt pomoże, ale nie przejdzie zakupów za użytkownika
Automatyczne narzędzia są bardzo dobrym pierwszym krokiem podczas sprawdzania checkoutu. Mogą znaleźć między innymi problemy z formularzami, kontrastem, strukturą HTML czy wybranymi zastosowaniami ARIA.
Do takiej analizy można wykorzystać narzędzia online, takie jak DockAccess, albo narzędzia działające bezpośrednio w przeglądarce. Nasze bezpłatne rozszerzenie dla Chrome i Firefox pozwala sprawdzać dostępność podczas pracy ze stroną i analizować wybrane elementy interfejsu.
Automat nie zastąpi jednak przejścia całego procesu zakupowego.
Może nie wykryć, że po wyborze dostawy użytkownik nie wie, co zrobić dalej, że kolejność fokusu jest nielogiczna albo że zewnętrzne okno uniemożliwia powrót do checkoutu.
Dlatego najlepsze rezultaty daje połączenie automatycznych testów z manualnym przejściem rzeczywistej ścieżki użytkownika.
Nie kończ testu po kliknięciu „Kupuję i płacę”
Złożenie zamówienia nie kończy procesu.
Sprawdź również, co dzieje się później.
Użytkownik powinien jednoznacznie wiedzieć, czy zamówienie zostało przyjęte, czy płatność zakończyła się powodzeniem oraz jaki będzie kolejny krok.
Warto sprawdzić stronę potwierdzenia, komunikat po płatności oraz wiadomość e-mail wysyłaną po zakupie.
Szczególnie ważne są sytuacje nietypowe: odrzucona płatność, zerwane połączenie, powrót z bramki płatniczej czy ponowienie płatności.
Dostępny proces powinien pomóc użytkownikowi zrozumieć również to, co poszło niezgodnie z planem.
Jak zacząć sprawdzanie dostępności checkoutu?
Nie musisz zaczynać od przebudowy całego sklepu.
Wybierz jeden popularny produkt i przejdź pełną ścieżkę od jego dodania do koszyka aż do potwierdzenia zamówienia. Następnie wykonaj ją ponownie bez używania myszy i celowo popełnij kilka błędów w formularzu.
Zapisuj nie tylko techniczne błędy, ale wszystkie momenty, w których nie wiadomo, co zrobić dalej.
To dobry punkt wyjścia do dokładniejszego audytu dostępności.
W Dock pomagamy analizować dostępność całych procesów ecommerce, łącząc automatyczne testy z audytem manualnym. Możemy również pomóc we wdrożeniu poprawek w sklepie, jego komponentach i integracjach oraz ponownie przetestować proces po zmianach.
