Zachować plan podróży, gdy nie udaje się sprawdzić ceny

Odjazd o 03:10

Podczas przeglądu mobilnej wersji serwisu wybór pociągu IC 431 z Wrocławia do Krakowa (odjazd 17 października o 03:10) wywołał komunikat zaczynający się od słów „Nieznany kod: 109”. W dalszej części napisano, że dostępne są wyłącznie miejsca dla osób podróżujących z rowerem. System nie był w stanie wyliczyć ceny biletu, a przejście do kolejnego kroku zostało zablokowane.

Pociąg widniał w rozkładzie jazdy, ale pasażer, który go wybrał, nie mógł poznać jego ceny.

Komunikat co prawda cokolwiek wyjaśniał, ale pozostawiał decyzję o dalszym kroku wyłącznie pasażerowi. Osoba podróżująca bez roweru musiała sama szukać alternatywy. Lepsze sformułowanie błędu mogłoby czytelniej wyjaśnić to ograniczenie, ale sam tekst nie zaproponowałby innego odjazdu ani nie zdecydowałby, które wpisane dane powinny zostać zachowane, gdy pasażer zmienia plany.

I właśnie ten moment zmiany planów był przedmiotem mojego projektu. Badanie miało charakter anonimowy i zakończyło się przed etapem rezerwacji. Obejmowało widok mobilny o rozdzielczości 390 × 844, mieszane wyniki wyszukiwania (pociągi i autokary) oraz wybór biletu dla jednego pociągu i jednego autokaru. Na podstawie tej obserwacji nie da się określić, jak często występuje ten błąd ani jak zazwyczaj reagują na niego podróżni. Dlatego punktem wyjścia był jeden konkretny stan interfejsu, wokół którego zaprojektowałam i przygotowałam do testów ścieżkę wyjścia z sytuacji błędu.

Oddzielam wyszukiwanie od odpowiedzi

Podzieliłam podróż na części, których interfejs nie może ze sobą mieszać:

• Wyszukiwanie obejmuje Wrocław, Kraków, datę wyjazdu i liczbę dorosłych.
• Wybrane połączenie to godzina odjazdu, stacje i przewoźnik.
• Cena dotyczy tego konkretnego połączenia i aktualnej konfiguracji pasażerów.

Zmiana jednej z tych części nie może po cichu sprawiać wrażenia, że pozostałe zostały już potwierdzone.

Od tego podziału zależy też język komunikatów, bo każda odpowiedź systemu oznacza coś innego:

• Ograniczenie dotyczące przewozu rowerów to konkretny warunek zwrócony przez system.
• Nieznana dostępność oznacza brak użytecznej odpowiedzi z systemu.
• Błąd pobierania ceny oznacza, że sama operacja zapytania zakończyła się niepowodzeniem.

W dwóch ostatnich przypadkach kwestia dostępności pozostaje nierozstrzygnięta – żaden z nich nie daje podstaw do wyświetlenia etykiety „wyprzedane”. W działającym prototypie można przełączać się między tymi stanami bez konieczności zgadywania ich znaczenia tylko na podstawie koloru czy nieaktywnego przycisku.

Samo uzyskane potwierdzenie ceny nadal nie oznacza rezerwacji miejsca. Scenariusz z dostępną ceną przechodzi do podsumowania, ale nigdzie nie twierdzi, że miejsce zostało zablokowane. Brak tu też licznika czasu, ponieważ na potrzeby tego projektu nie dysponuję wiążącymi danymi o czasie trwania takiej blokady. Rzeczywista integracja z systemem przewoźnika musiałaby precyzyjnie określać, kiedy wycena traci ważność i co się dzieje, jeśli kwota ulegnie zmianie w trakcie przeglądania podsumowania.

Wypróbuj ścieżkę naprawczą

Przetestuj ją w następującej kolejności:

1. Zacznij od komunikatu o ograniczeniu dotyczącym roweru.
2. (Wybierz opcję zmiany połączenia)
3. Otwórz listę innych połączeń i wybierz późniejszy pociąg. Data oraz liczba dorosłych pozostaną bez zmian.
4. Zmień dowolne z tych pól. Wyświetlona cena zostanie wycofana do momentu zakończenia kolejnej weryfikacji.

Przełączniki umieszczone nad polskim interfejsem wczytują gotowe, powtarzalne scenariusze, dzięki czemu możesz przeanalizować każdą odpowiedź systemu bez konieczności połączenia z żywym serwisem transportowym.

Odpowiedź musi dotyczyć zapytania, które ją wywołało

Załóżmy, że ktoś wybiera autokar, gdy cena dla pociągu jest jeszcze weryfikowana. Jeśli odpowiedź dotycząca pociągu nadejdzie później, może nadpisać podsumowanie dla autokaru. Ekran nadal wygląda spójnie, ale w rzeczywistości łączy wybraną podróż z niewłaściwą ceną.

Prototyp temu zapobiega – wiąże każde trwające sprawdzenie z konkretnym zapytaniem, które je uruchomiło. Wybór nowej opcji, zmiana daty lub modyfikacja liczby pasażerów sprawiają, że spóźniona odpowiedź ze starszego zapytania zostaje odrzucona i nie aktualizuje ekranu.

W prototypie dodano krótkie opóźnienie przy każdym sprawdzeniu, dzięki czemu tę zasadę można zaobserwować w praktyce: w trakcie weryfikacji wybierz inny scenariusz albo zmień liczbę dorosłych. Wcześniejsza odpowiedź nie wpłynie na nowy stan interfejsu.

Jest to zachowanie lokalne i symulowane. Połączenie z rzeczywistym serwisem wymagałoby kontraktu API, który jednoznacznie identyfikuje konkretny odjazd, konfigurację pasażerów oraz czas ważności odpowiedzi – a takich gwarancji sam licznik czasowy w przeglądarce nie jest w stanie zapewnić.

Porządek odczytu i nawigacja jako elementy wychodzenia z błędu

Większość elementów sterujących to natywne komponenty przeglądarki. Wybór scenariusza testowego odbywa się za pomocą standardowych pól jednokrotnego wyboru (radio buttons), a parametry podróży ustawia się w polu daty i na liście wyboru liczby dorosłych. Akcje naprawcze uruchamiają klasyczne przyciski. Ich etykiety wprost opisują działanie: Sprawdź ponownie, Pokaż inne połączenia lub Przejdź do podsumowania. Oparcie interfejsu na natywnych kontrolkach zachowuje domyślne zachowanie klawiatury i ogranicza potrzebę tłumaczenia niestandardowych interakcji.

Przenoszenie fokusu i komunikaty głosowe podążają za intencją pasażera:

• Odpowiedź o cenie przychodząca w tle aktualizuje komunikat o stanie (za pomocą dyskretnego powiadomienia dynamicznego aria-live="polite"), nie przerywając bieżącej wypowiedzi czytnika ekranu i nie przenosząc fokusu.
• Otwarcie listy alternatywnych połączeń jest świadomą akcją nawigacyjną, dlatego fokus zostaje przeniesiony na nagłówek tej listy.
• Wybór alternatywnego połączenia kieruje uwagę użytkownika z powrotem na aktualny stan operacji.
• Podsumowanie posiada własny nagłówek oraz wyraźny przycisk powrotu.
• Stan ładowania danych nie blokuje pasażera, a błąd jest przedstawiony zarówno wizualnie, jak i w formie jednoznacznego tekstu.

Zasady te oparłam na wytycznych W3C dotyczących komunikatów o stanie (Status Messages), które odróżniają dyskretną aktualizację bez zabierania fokusu od pełnej zmiany kontekstu. W tym przypadku ma to kluczowe znaczenie: cena nadesłana w tle i świadome otwarcie listy alternatyw przez użytkownika wymagają całkowicie odmiennego traktowania.

Ponieważ nie przeprowadzono jeszcze pełnego audytu z użyciem czytników ekranu, przyjęte założenia wymagają weryfikacji za pomocą technologii asystujących.

Inne połączenie może oznaczać zmianę stacji

W przykładowym zestawie danych pociąg kursuje między stacjami Wrocław Główny a Kraków Główny. Autokar odjeżdża natomiast z dworca autobusowego i dociera na przystanek Kraków MDA.

Na tej trasie autokar stanowi realną alternatywę dla kolei. Zmiana środka transportu wiąże się jednak ze zmianą punktów początkowego i docelowego. Dlatego oba dworce są wyraźnie widoczne na liście alternatyw przed dokonaniem wyboru, a następnie w podsumowaniu wybranego połączenia. Sama niższa cena nie odpowiada na pytanie, czy przesiadka na inny dworzec będzie dogodna dla osoby podróżującej z dużym bagażem lub z ograniczoną mobilnością.

Co pozwala sprawdzić ten prototyp?

Opracowana makieta umożliwia przetestowanie ściśle określonego zbioru zachowań w warunkach powtarzalnych:

• wszystkich czterech typów odpowiedzi systemu,
• wyboru alternatywnego odjazdu,
• zachowania wpisanej daty i liczby pasażerów,
• unieważnienia wyceny po zmianie parametrów wejściowych,
• przejścia do podsumowania, które kończy się przed etapem płatności.

Przy przełącznikach zaznaczono jedno uproszczenie: ponowienie próby w przypadku braku odpowiedzi lub błędu zwraca zaprogramowany scenariusz z udaną wyceną. Służy to wyłącznie zaprezentowaniu przejścia między stanami i w żaden sposób nie sugeruje, że w środowisku produkcyjnym druga próba zakończyłaby się sukcesem.

Prototyp wyraźnie pokazuje też swoje ograniczenia technologiczne. Zmiana daty nie pobiera rzeczywistego rozkładu jazdy. Alternatywne połączenia są fikcyjne, sprawdzanie ceny nie tworzy rezerwacji w systemie, a wyliczona kwota dotyczy wyłącznie biletów normalnych. Brak tu mapy miejsc, opcji rezerwacji roweru, gwarancji przesiadek czy obsługi powrotu z bramki płatniczej. Wdrożenie produkcyjne wymagałoby ścisłych reguł biznesowych dla każdego z tych procesów.

Kolejny krok: badania z udziałem użytkowników

To, czego nadal nie wiem, to czy podróżni potrafią bez zewnętrznej pomocy poprawnie zinterpretować dany stan interfejsu i podjąć właściwy krok.

W moderowanym teście zadaniowym uczestnik otrzymałby określony czas przybycia na miejsce oraz budżet. Po napotkaniu ograniczenia miałby za zadanie kontynuować proces. Analiza sesji powinna objąć:

• ostatecznie wybrane połączenie,
• sposób, w jaki uczestnik rozumie wyświetloną cenę,
• dane, które musiał wpisać ponownie,
• wszelkie interwencje ze strony moderatora.

Warto pamiętać, że odpowiedź udzielona z dużym przekonaniem nadal może być błędna – sama pewność siebie użytkownika nie stanowi miernika sukcesu UX.

W badaniach powinny wziąć udział osoby na co dzień korzystające z czytników ekranu, nawigacji klawiaturowej oraz narzędzi powiększających – na własnym sprzęcie i oprogramowaniu. Sesje testowe pozwoliłyby ocenić kolejność i czas odczytywania komunikatów oraz wygodę obsługi elementów sterujących. Porównanie tego rozwiązania z wariantem powrotu do zapisanych wyników wyszukiwania wykazałoby, czy wyjaśnienie błędu bezpośrednio przy połączeniu rzeczywiście pomaga w rozwiązaniu problemu, czy jedynie niepotrzebnie wydłuża stronę. W ramach niniejszego opracowania nie przeprowadzono jeszcze takich badań.