01
Role and ownership
What I led
- Framing the problem as a change in the passenger's job, not a missing feature.
- The decision logic: what gets checked, in what order, and what the service says at each outcome.
- The recovery journey and its states, from an active trip through to a completed record.
- The screens and the proposed validation approach.
Alongside
A freelance engagement, so the working arrangement and team are not described here.
What this case does not claim
A launched service, real passenger data, research findings or measured impact. The screens use illustrative data.
The call
Check whether a route is viable before ranking, then recommend one.
Rather than
Returning a ranked list and leaving the hardest work with someone on a concourse.
Why
Ticket validity, access and connection risk decide whether a route works at all. Speed only matters among routes that pass.
02
Disruption creates a different product job.
Planning tools help people search, compare, buy and travel. Once the plan breaks, the immediate need is to detect what changed, understand the consequence and commit to a viable recovery.
Read this diagram as text
The planned journey has four steps: search, compare, buy and travel. When the timetable changes, a disruption occurs and the passenger's job changes.
The disrupted journey has five steps: detect what changed, understand what it means, recover with the next best option, reassure, and continue. If the recovery fails again, the journey returns to the recover step.
Those facts often sit across different products and organisations. The pressure comes from having to connect them quickly, in the right order, while already in motion.
03
The information existed. The gap was connecting it around one passenger.
Rejoin is not another journey planner. It assembles network truth, the journey already bought and the passenger's constraints, then turns them into one defensible action.
Read this diagram as text
Five sources each hold part of the picture: the ticketing app (what the passenger bought), the train operator (live service status), network information (wider network truth), station staff (judgement and local knowledge) and Delay Repay (later entitlement).
Examples of the fragmented facts include a service delayed by 42 minutes, an alternative route, a platform change at short notice, limited wheelchair space and possible eligibility for compensation.
Rejoin brings these together with the passenger's journey and access needs, and produces a next correct action: a clear, confident next step for this passenger.
Resolve before ranking
Remove routes that fail ticket, access or connection checks before comparing speed.
Show the reasoning
Make validity, timing and accessibility visible so the recommendation can be trusted and checked.
Stay useful after failure
Treat recovery as a live state that can change again, not a one-off alert.
04
Do not return a list and call it help.
A ranked list still leaves the hardest work with somebody on a concourse. Rejoin checks whether a route is viable first, then gives one recommendation with the reasons in the main path.
Try it: press a check to change how it comes out
One checked route
Illustrative logic for one candidate route, with no live data. It is not a working service.
Is it running?
The service checks live status first, because a route that is not running cannot be recommended however convenient it looks.
Is the ticket accepted?
Ticket rules are resolved before speed is compared. A fast route the ticket does not cover is not a recovery.
Can this passenger use it?
Step-free access is a blocking condition, not a preference. A route that fails it is removed before ranking.
Can they make the connection?
Walking and platform-change time are counted. A connection that looks fine on a timetable can fail on a concourse.
What happens if it fails?
If a route fails, the passenger should be left with a recoverable position, so the checked route prefers one where that is true.
Read this diagram as text
Five real-world inputs feed the check: live service status, ticket validity, access requirements, connection viability and journey consequence. The service checks viability before ranking options and keeps uncertainty visible. If any key information is uncertain, it does not recommend a route.
There are three outcomes. A recommended route, which is safe and viable for this passenger, with the ticket, access and connection checks shown and other routes available. A needs-verification state, when some information is missing or uncertain, where the service confirms the details first. And no viable route, where the service explains why and suggests next steps, including when to check again.
Recommended route
Safe and viable for this passenger, with the checks shown and other routes available.
Needs verification
Something is missing or uncertain, so the service confirms the details first.
No viable route
The service explains why and suggests next steps, including when to check again.
05
Recovery is a state the journey can enter more than once.
The interface changes with the passenger's job. Normal journey guidance gives way to an explanation of what happened, a checked recovery route and reassurance as the new plan progresses.
Read this diagram as text
The planned journey moves through upcoming, active and attention needed. The recovery lifecycle then runs through checking recovery, recovery ready, recovering and back on track, before the journey completes.
A dashed route from back on track returns to attention needed: plans can change again, and a new disruption can return the journey to attention needed.
The interface stops behaving like a timetable when the timetable stops being useful. The transition is deliberate: say what changed, show what is being resolved and only then ask the passenger to commit.
06
The value is continuity, not another journey planner.
Rejoin carries the decision beyond the alternative train. It records what actually happened, keeps the evidence and makes compensation or later review part of the same journey history.
During disruption
One viable next action, with reasons and a fallback.
While recovering
Updated guidance if the new plan changes again.
After arrival
Actual journey evidence, claim status and an audit trail.
These screens show the designed outcome with illustrative data. They do not represent a launched service or measured impact.
The useful test is whether the recommendation survives uncertainty and failure.
The validation approach I would use is proposed and has not been run. It tests the first decision, then introduces a second disruption to see whether the recovery and the passenger's trust hold.
Read this diagram as text
The proposed flow starts with a realistic disruption scenario. The passenger sees the recommendation and chooses what to do. Four measures are captured: time to the next correct action, decision confidence, error type and re-checking elsewhere.
A second disruption is then introduced after the initial decision, and the test observes how the passenger recovers and whether trust is maintained after failure.
The diagram is labelled as proposed research that has not yet been run.
What I would measure
Time to the next correct action, ticket, access and connection errors, confidence at the moment of commitment, and trust after an injected second disruption.
What this case does not show
Any result from that testing. I would run it with passengers, including those who need step-free routes, before claiming the logic works.