Research and design on an account-based ticketing system — the software behind fare payment on a rail network, covering both the back office that staff use and the app that passengers use. The product runs in two cities in Asia today and is being sold into further regions.

The current system was built to be accurate systematically. Fares are correct, gates open in a fraction of a second, and the money reconciles. It is organised around the parts of the software that do that work: the back office, the payment gateway, device management, customer service. Staff screens, reports and permissions all follow that structure.

People's jobs do not. Handling a broken gate or a refund means moving across several of those parts, and the screens do not travel with the person. When something goes wrong, four staff roles find out separately, each from a different screen, and each can reach a different conclusion about what happened. Passengers hit a smaller version of the same problem. Because taps are bundled and charged later, a line on a bank statement rarely matches a single journey — so a passenger who has been charged wrongly gets little explanation and a slow route to challenge it.

We reorganised the staff side around tasks rather than software parts. A broken gate, a refund or a rule change now has one record that every role works from. When the control room passes a fault to a station engineer, the engineer sees what has already been checked instead of starting over. Each role opens the system to the work waiting for them, with enough context to act on it. On the passenger side, we put the answer next to the question: balance on the first screen, each fare openable to show how it was worked out, and a way to report a problem on the journey it happened on. None of it needed new data. The system already had it.

The product is sold to different cities, so anything that varies between them is now a setting rather than a fixed design. The lists of cards a network blocks or flags, for example, differ from city to city. A design system hence shows an adaptable set rather than a fixed approach.

Due to NDA with ST Engineering, this case study has been anonymised. For the full project discussion, leave your details: