Transport for Wales
Designing rail retail for real-world complexity
A retail ecosystem designed around the people who sell tickets every day — from conductors moving through trains to sales operators working at ticket offices.
My role:
I owned research and end-to-end design for the retail app across conductor handhelds and ticket-office systems. I also coordinated design across the wider Transport for Wales programme, including gate monitoring, SOS and other workstreams.
Overview
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.
Our challenge was to design tools that supported both environments while making the underlying railway rules manageable.
Research
Understanding what happens around the screen
Across three rounds of field research in Cardiff, we observed six conductors and six ticket-office operators using existing systems and handling passenger requests.
01
Design for movement and divided attention.
Conductors are standing, walking through moving trains, talking to passengers and often operating a handheld device with one hand.
02
Build on familiar ways of working.
Years of using paper-based workflows shaped strong mental models. Digitising these tasks meant preserving familiar patterns while reducing effort.
03
Make repeated tasks faster.
Ticket-office operators spend much of their working day selling the same tickets repeatedly.
Product approach
Different working environments needed different design priorities
The conductor and ticket-office experiences shared railway rules, but their day-to-day demands were different.
For conductors, reliable access to essential tasks came first. We designed an almost entirely offline handheld experience so they could sell and manage tickets throughout the day without depending on connectivity. Only end-of-day tasks, including closing a shift and final reconciliation, required an internet connection.
Larger controls for use on the move
We observed accidental presses on small payment controls in the existing system. Our initial radio-button design was also unsuitable for interaction on a moving train, so we gave payment options more space and larger selection targets.
Less manual entry for excess fares
Excess-fare sales were more frequent than I expected. Seeing conductors make mistakes when entering ticket codes led us to prioritise scanning the original ticket to retrieve fare information.
For ticket-office staff, we focused on repetition. Features such as repeat fares made frequently purchased tickets quicker to sell. The design priority was to reduce effort across tasks that staff might complete hundreds of times.
For ticket-office staff, we focused on repeated tasks. Features such as repeat fares were designed to make frequently purchased tickets quicker to sell and reduce the effort of recurring sales.
Across both experiences, research helped us decide which complexity the interface needed to expose and which the system could handle in the background.
AI usage
Working through complexity
Across six workstreams, AI helped us navigate Rail Delivery Group accreditation requirements, test Figma prototypes with synthetic users grounded in research, and understand existing APIs. It sped up checking and surfaced potential gaps earlier, while interpretation, validation and final decisions remained with the team.
Lessons
The system can be complex. The experience shouldn’t have to be.
This phase focused on getting the product through design, accreditation preparation and UAT. The next step is to understand how well it performs in real working conditions. I’d track a small set of measures that show whether the experience is genuinely making rail retail faster, clearer and less error-prone.
01
Task completion time
How quickly staff can complete common journeys such as selling a ticket, repeating a fare or processing an excess fare.
02
Error rate
Accidental taps, incorrect fare selections, input errors and journeys that need to be restarted or corrected.
03
Shortcut adoption
Whether features like quick fares, repeat fares, familiar destinations and barcode scanning actually reduce effort.
04
Offline reliability
How often key conductor tasks can be completed successfully with weak or no connectivity.
05
Accreditation & support issues
The number and type of issues raised during accreditation, UAT and live support, especially where rules or workflows remain unclear.
The aim is not just to prove that the product works, but to understand whether it reduces the operational complexity staff experience day to day — and where we still need to simplify further.
