01Lead PM & UX
Real-Time Decision Support for LNER
A control room tool that pulls in every relevant data source so staff can see the network clearly enough to replan it.
Nine years leading complex operational products, on top of fifteen in design, programming and systems. I run the discovery, write the roadmap, do the research and the UI work, and lead the team that ships it — dashboards, apps, portals and real-time tools built with the people who actually use them.
For the last nine years I've built complex products and systems for a wide range of clients and users — from the first ideas and discovery sessions through data analysis and prototyping, working alongside designers, programmers and systems engineers to deliver products that hold up in daily use. I've built everything from control-room SaaS tools to mobile apps and data analysis software, and spent enough time in control rooms, on platforms and in depots to understand the environment from the ground up, not just from a spec.
Most of my job is translation: turning what users and the business actually need into something a delivery team can build, then staying close enough through delivery to catch where it drifts. I run discovery with real users, write the roadmap myself, and design the screens directly when that's the fastest way to get to clarity — then stay on long enough to see whether it worked.
Roadmaps that survive contact with an operations director.
Contextual interviews, field work, usability testing.
Interaction design, design systems, accessible components.
Shipping in slices with engineering, in regulated environments.
Instrumentation, success metrics, honest post-launch reads.
Time spent with the people who use the system, so the product reflects their needs, not assumptions about them.
Operations, commercial and safety in one room, one decision.
Clickable prototypes that settle arguments before a sprint starts.
User stories and specs a delivery team can pick up and build from, unambiguously.
A selection of products that shipped and are still in daily use. Open a project for the full story and the rest of the screens.
A control room tool that pulls in every relevant data source so staff can see the network clearly enough to replan it.
When something disrupts the network, control room staff need one clear picture, not five systems open at once. This tool brings together the outside data sources they were previously reconciling by eye, and turns that into a single view of what's happening and what's coming.
It gives early warning of developing problems rather than just reporting them after the fact, and lets staff replan stock and crew directly from that view instead of working the change out separately and typing it in elsewhere. I worked closely with control room staff and management to understand how a shift actually runs, then led the design, programming and systems engineering teams to build it around that.
It's in daily use in the York Rail Operating Centre, where it now sits at the centre of how disruption is managed and communicated — replacing a slower, more manual way of piecing the same picture together.
An iOS app for the Elizabeth line, built for the platform and the ticket gates rather than the sofa.
Passengers need different things depending on exactly where they're standing — deciding on a journey at home is a different problem to working out what's happening on the platform right now. This app was designed for that second moment.
It covers journey planning and ticket prices alongside a live train map, live departures and disruption information, so a passenger at the gates or on the platform gets the same real-time picture as someone watching the boards. A companion content system lets station and control staff keep that information current.
I led the discovery and design work end to end, translating what staff and passengers actually needed at each point in the journey into a single, coherent app rather than a collection of separate features.
An Android app for depot screens that replaced paper notices with something driving staff actually read.
Depots ran on paper notice boards — safety bulletins, union notices, speed restrictions, compliance updates — pinned up and easy to miss. There was no reliable way to know who had actually seen what, which matters when the notice is about safety.
This app puts the same notices on screens in the depot, with mobile sign-on over NFC so staff are identified the moment they walk up. Each notice has to be opened and marked as read, so there's a real record of who has seen it rather than an assumption that the board was noticed.
The design challenge was making something driving staff would actually engage with in the middle of a shift, not just another screen to walk past — quick to sign into, quick to read, and clear about what still needs acknowledging.
One system for communicating on-the-day timetable changes, so customers and staff work from the same facts.
On-the-day changes to train plans have a habit of reaching different audiences at different times, through different systems — so customers and staff end up working from slightly different versions of the truth.
CEIS was built to close that gap: a single system that communicates revised plans and timetables to customers and staff together, so there's one point where a change is confirmed rather than several places it might quietly disagree.
My focus was on the handoff points — where a plan changes, who needs to know first, and how that reaches a passenger in language that actually helps them, not just an internal update repeated verbatim.
A real-time dashboard that catches the gaps in service a timetable alone won't show you.
A single late or cancelled service is usually manageable. Two or three in a row at the same stop is a different problem for passengers, and one that's easy to miss if you're only looking at the timetable rather than what's actually running.
SID measures the real-time gap between services at any stop on the network and compares it against what the timetable promises, alerting customer experience and control room staff the moment more than one service in a row has been cancelled at a particular stop. It works on mobile and desktop, so it's usable equally from a control room screen or a phone on the platform.
The design problem was surfacing a pattern — repeated gaps — that's obvious in hindsight but easy to lose inside a list of individual delay and cancellation events.
A dashboard that checks whether passengers were actually told about a change before it happened.
Knowing a train was delayed is one thing; knowing whether passengers were told about it before it mattered is another. Those two data sources — the actual arrival time and the platform announcement — had never been compared directly.
CIS pulls arrival times from two independent sources, Darwin and TRUST, and lines them up against the platform audio announcements for the same service. That makes it possible to see, service by service, whether a change was communicated with enough notice to actually help someone standing on the platform — for example, before the original train was due.
The interesting part was designing a comparison that stayed honest about two data sources that don't always agree with each other, without drowning the real question — were people told in time — in the discrepancy.