Booking flows get tested against the happy path. Someone travels from A to B on a day when the service runs as published, and the experience is measured there.
That is the day nobody remembers. Reputation is built on the other one — the cancellation, the diversion, the platform change announced twelve minutes late — and most systems handle it as an exception rather than as a core case.
Disruption is not an edge case
It is a routine operating condition. Weather, faults, staff shortages and knock-on delay are normal, and any given passenger meets one regularly.
Yet the software usually treats the disrupted state as a failure of the model. The app shows a timetable that is no longer true. The booking references a service that is not running. The confirmation email describes a journey that has ceased to exist. Nothing has crashed; the system is confidently wrong, which is worse.
What people actually need when it goes wrong
Not more information. Different information, in a different order:
- Tell them it changed before they find out. A push notification that arrives ahead of the departure board is worth more than a perfect journey planner.
- Say what it means for them, not what happened. “Your 07:42 is cancelled — the 08:05 gets you in at 09:31” beats an incident description every time.
- Say what you do not know. “We expect an update by 08:15” is genuinely reassuring. Silence reads as nobody being in charge.
- Make the next action obvious. Rebooking, refund, or the alternative platform. A passenger standing on a concourse should not have to work out their own entitlement.
- Stop showing the plan that died. Stale certainty destroys more trust than admitted uncertainty.
The hard part is upstream
None of that is a design problem, really. It is a data problem wearing a design problem’s clothes.
Telling a passenger what a disruption means for their journey requires the booking and the live operational state to be connected. In many operators they are not: one system knows who is travelling, another knows what is running, and the join happens in a person’s head in a control room.
Until that join exists, the passenger-facing app cannot be better than a generic alert, no matter how it is designed. This is the same pattern we see everywhere — the interface is blamed for a limitation that sits three systems back.
Design for the staff too
The other group having a disrupted day is the people working it, usually on a phone, often outdoors, with a queue forming. They need the same connected picture and a smaller number of decisions, and they are frequently given a desktop tool designed for a control room.
If the person at the barrier knows less than the passenger’s app, everything after that is damage limitation.
Where to start
Not with a redesign. With one question: when a service is cancelled, how many systems have to agree before an affected passenger can be told what it means for them?
If the answer is more than one, that is the project.
Working on how your service behaves when the plan breaks? Get in touch, or see how we build for travel and transport.