PRODUCT DESIGN · RESEARCH
Designing the next generation of rail retail tools
A new retail ecosystem designed around the people who sell tickets every day — from conductors moving through trains to sales operators working at ticket offices.
Problem area
A complex system behind every simple sale
Selling a UK train ticket means navigating routes, operators, ticket types, restrictions, railcards, passenger combinations and fulfilment methods—all while the customer waits. For Transport for Wales, this complexity was compounded by two distinct working environments: conductors selling tickets on the move, often with limited connectivity and constrained by the capabilities of a handheld device, and ticket-office staff handling a broader range of complex requests.
The challenge wasn’t simply to modernise existing tools. It was to understand the practical limitations of each environment, identify what information people need at every stage and make a complex retail system feel manageable.
Research
Understanding rail retail in the real world
Tender requirements and business rules could only tell us part of the story. I travelled to Cardiff several times to observe Transport for Wales teams using the existing systems, noticing where staff hesitated, what they relied on and where technology was getting in their way.
The work moved from observation to design principles: reduce unnecessary input, keep actions reachable and predictable, and let the interface support the conversation with a passenger rather than compete with it.
Seeing the environment first-hand changed the work. A conductor does not interact with a handheld device like someone using a consumer app; every decision needed to account for movement, attention and conversation. These insights grounded the product direction in the realities around the screen.
Product approach
Making railway complexity manageable
The railway system contains an enormous amount of operational complexity, much of it necessary. Rather than exposing all of that complexity to conductors, we invested in a technology-led approach: a robust handheld application designed to work fully offline. This enabled conductors to sell and manage tickets reliably throughout their journeys, even with limited or no connectivity. Only essential end-of-day activities—such as closing a shift and completing the final reconciliation—required an internet connection.
In ticket offices, we focused on reducing the number of steps involved in repetitive tasks. We introduced concepts such as Repeat Fares, enabling users and agencies to streamline the sale of frequently purchased tickets. Together, these decisions supported a central design principle: make common tasks fast, simple and predictable while preserving the depth required for unusual journeys and complex ticketing scenarios.
PAX + ELYS
Two contexts, a shared understanding of rail retail
PAX was designed for conductors selling tickets where connectivity cannot be guaranteed. Its offline-first approach keeps essential tasks available throughout the journey, while simple features such as mode selection and the “Current headcode only” filter show conductors only the data relevant to the task at hand.
For the ticket-office experience, we built on the mental models staff had already developed through years of selling tickets. Rather than replacing familiar workflows that worked well, we preserved them and added value elsewhere—through features such as Repeat Fares, live journey-planner integrations and digitally sharing journey details with passengers. We also introduced preference-based seat booking, allowing staff to select suitable options during a conversation instead of relying on carriage-plan visualisations that were often inaccurate or unavailable.
COLLABORATION + AI
Designing across teams, systems and time zones
The platform was delivered across teams in the UK, Australia and Vietnam, with multiple backend services and APIs feeding the retail experience. Understanding those relationships was essential: an endpoint could determine what information was available, when it appeared, what worked offline and what was technically possible. We used Codex and custom GPTs to interrogate large volumes of documentation, business requirements, railway terminology and API definitions. AI did not make product decisions; it reduced time spent finding and interpreting information, giving the design team more time to ask better questions and focus on experience.
WHAT I LEARNED
The system can be complex. The experience shouldn’t have to be.
This project reinforced that complexity does not disappear because an interface looks simple. Someone has to understand it, organise it and decide what the user should — and should not — have to think about. Designing professional tools means respecting the expertise of the people using them while protecting them from unnecessary system complexity. It also means designing for the environment around the screen: a moving train, unreliable connectivity, a queue at a ticket office, a conversation with a passenger, or a task repeated hundreds of times.
