Keeping the journey when a fare check fails

The 03:10 departure

In a walkthrough of the public mobile site, selecting the IC 431 train from Wrocław to Kraków (leaving at 03:10 on 17 October) triggered a message beginning with “Nieznany kod: 109”. The rest of it stated that only places for passengers travelling with a bicycle were available. The system could not calculate a ticket price, and the next step remained disabled.

The train appeared in the timetable, yet its price could not be confirmed for the passenger choosing it.

While the message did offer some explanation, it left the next move entirely to the passenger. Someone travelling without a bicycle had to find an alternative on their own. Better error wording could have explained the restriction more clearly, but wording alone could not propose another departure or decide which entered details should be preserved when the passenger changed course.

That change of course is what I designed for. The evaluation was anonymous and stopped before booking. It covered a 390 × 844 mobile viewport, mixed results (trains and coaches), and ticket selection for one train and one coach. Based on this observation alone, it is impossible to say how often the error occurs or how travellers typically react to it. Therefore, the starting point was a single recorded interface state, around which I designed and prepared a testable recovery path.

Separating the search from the response

I split the journey into distinct parts that the interface must not confuse:

• Search holds Wrocław, Kraków, the departure date, and the number of adults.
• Selected connection holds the departure time, stations, and carrier.
• Price applies to this specific connection and the current passenger configuration.

Changing one of these parts must not quietly make the others look confirmed.

This division also dictates the wording of system messages, as each response means something different:

• Bicycle restriction is a specific condition returned by the system.
• Unknown availability means no usable response was returned by the system.
• Failed price request means the operation itself failed.

In the last two cases, availability remains unresolved—neither provides grounds for displaying a "sold out" label. In the working prototype, you can toggle between these states without having to guess their meaning based solely on a color or a disabled button.

Obtaining a confirmed price still does not reserve a seat. The scenario with an available price moves to the review summary, but it never claims the seat has been held. There is no countdown timer here, as I do not have authoritative data regarding the duration of such a hold for this project. A real carrier integration would need to define precisely when a quote expires and what happens if the amount changes while reviewing the summary.

Try the recovery path

Test it in the following order:

1. Start with the bicycle restriction message.
2. (Select the option to change the connection)
3. Open the list of other connections and choose a later train. The date and adult count will remain unchanged.
4. Change either of those fields. The displayed price will be withdrawn until the next check completes.

The toggles located above the Polish interface load fixed, repeatable scenarios, allowing you to inspect every system response without needing a live connection to a transport service.

An answer belongs to the request that produced it

Suppose someone selects a coach while a train fare is still being checked. If the response for the train arrives later, it could overwrite the coach summary. The screen would still look coherent, but it would actually pair the selected journey with the wrong price.

The prototype prevents this—it ties every pending check to the specific request that initiated it. Selecting a new option, changing the date, or modifying the passenger count causes a delayed response from an older query to be discarded, preventing it from updating the screen.

A short delay has been added to each check in the prototype so you can observe this logic in action: while a check is running, select a different scenario or change the adult count. The earlier answer will not affect the new interface state.

This is local, simulated behavior. Connecting to a real service would require an API contract that unambiguously identifies the specific departure, passenger configuration, and response validity period—guarantees that a simple browser timer cannot provide on its own.

Reading order and navigation as part of recovery

Most controls are native browser elements. Test scenarios are selected using standard radio buttons, while journey parameters are set via a date field and an adult-count dropdown. Recovery actions are triggered by native buttons. Their visible labels describe the action directly: Check again, Show other connections, or Review chosen journey. Relying on native controls preserves default keyboard behaviour and leaves fewer custom interactions to explain.

Focus movement and announcements follow the traveller's intent:

• A fare response arriving in the background updates a polite status announcement (aria-live="polite") without interrupting speech or moving focus.
• Opening the list of alternatives is an explicit navigation action, so focus moves to the alternatives heading.
• Selecting an alternative connection returns attention to the updated operation status.
• Review has its own heading and a clear return action.
• A loading state does not trap the user, and errors are presented visually as well as in explicit text.

These principles draw on the W3C guidance on status messages, which distinguishes an update announced without taking focus from a full change of context. That distinction is essential here: a fare arriving in the background and a user deliberately opening alternatives require completely different handling.

Because no screen-reader audit has been conducted yet, these design choices still require verification with assistive technologies.

Another connection may mean another station

In the sample dataset, the train runs between Wrocław Główny and Kraków Główny. The coach, however, leaves from the bus station and arrives at Kraków MDA.

On this route, a coach is a plausible alternative to rail. Changing the mode of transport, however, changes the endpoints at both ends. Both stations are therefore clearly shown in the alternative list before selection and again in the journey review. A lower fare alone cannot tell anyone whether transferring to that station works for someone travelling with heavy luggage or mobility constraints.

What can be tested in this prototype

The developed artifact makes a narrow set of behaviours inspectable under repeatable conditions:

• all four system response types,
• selecting an alternative departure,
• preserving the date and passenger count,
• invalidating a quote when inputs change,
• a review summary that stops before payment.

One shortcut is noted beside the controls: retrying an unanswered or failed check returns a scripted success scenario. This merely demonstrates the state transition and implies nothing about whether a second attempt normally succeeds in production.

The prototype also clearly demonstrates its technical limits. Changing the date does not fetch a real timetable. Alternatives are fictional, checking a price creates no reservation, and the calculated total covers full-fare adults only. There is no seat map, bicycle booking, transfer guarantee, or payment gateway return. A production system would require authoritative business logic for each of these before making corresponding promises.

Next step: user testing

What remains unknown is whether travellers can correctly interpret a given state and select a suitable path forward without guidance.

In a moderated task, a participant would be given an arrival deadline and a budget, shown the restriction, and asked to continue. Session records should capture:

• the final departure chosen,
• how the participant interprets the displayed fare,
• any fields they have to re-enter,
• any facilitator intervention required.

A confident explanation can still be wrong—confidence alone does not constitute UX success.

Testing must include regular users of screen readers, keyboard navigation, and screen magnification operating their own hardware and software. These sessions would evaluate the sequence and timing of announcements as well as control operability. Comparing this layout with the preserved-results variant would then reveal whether an inline explanation truly aids recovery or merely lengthens the page. No such participant sessions have been conducted for this study yet.