Railways administration tool design

Redesign a complete administration tool for railways, to manage from the trains schedule, to the chicken sandwich you will order during your next trip.

Projects you don't take to their term may feel frustrating or amazing, depending on how far you explore and learn from what you discover. This project has never been finalized, probably because of the risk factor for our company. But for the design team, it was a great opportunity to explore new areas.

My main challenge was to sew the pieces together, and define the missing ones.

A one year project, and what a year! The team started a few months earlier with the customer, to draw the outline of what this administration tool would be. It was big! But on both side, customer and provider, we had existing pieces. My main challenge was to sew the pieces together, and define the missing ones for a more efficient network administration, and a better traveler experience.

The context

- The customer had to switch to a new system the next year because their core tool provider will stop the developments.

- Also the competition with the plane and other rail companies was getting tough!

- The objective was to ease the Inventory management so operators can save time on low value tasks to focus on what matters: ensure a better quality service on disruption management and improve the traveler experience.

- Big pressure, but also a good opportunity to change for the best.

- Two teams working in parallel: business and architecture on the customer's side and core operation engine development on our side.

But in reality it was more than two teams, because the existing modules on our side were designed and developed in different places on the globe, by different teams, with different technologies...

The challenges

- Redefine the user journey in a BtoBtoC context for a large number of user profiles.

- Automate as much as possible the disruption management for a better traveler service.

- Keep a flat architecture to remain modular and flexible.

- Build a unified and seamless UI out of heterogeneous modules.

My contribution

1. Redefining the user journeys / scenarios for each user category (persona)

2. Prototyping the scenarios

3. Support the architects and development teams in their research

4. Adjust our design system to this specific context

1. Redefine the user journeys

Several workshops with the different teams help to complete this kind of one page story:

- Customer services

- Product team

- Solution team

Here you can see that we are still missing the architecture team's feedback for the system behaviour.

2. Prototyping each scenario

An example of a centralized dashboard to manage disruptions

Different view mode of the same information

Aggregated information on the same page to ease the user understanding of a complex context.

3. Support the architecture and development teams in their research

This last screen highlights one of the big challenge, as it aggregates information coming from the different modules in the backend.

The frontend was first designed as a layer on top, that gives a complete overview on a specific service (=train number). But this layer could rapidly lead to a bottleneck, as the different teams working on the modules should follow a strict and synchronized schedule.

Also the different modules where developed with different technologies. This could lead to compatibility issues and different patches to allow the communication between the modules.

The research lead us to the Webcomponents opportunities. Of course we could not use them to rebuild a complete UI, but it seemed that it could be a good alternative in some critical cases.

4. How to convert our existing components to Webcomponents?

So what do we do with all our existing components built in Angular? A new research with the design system team demonstrates that there were some adjustments to make, but in the end it was feasible to use Webcomponents and Angular components to build our UI and these could coexist, following certain rules.

We had great material to build an agnostic branch to our design system!

Conclusion

This is a good example on how a user need can lead to technical improvements, at least at research level.

As the project stopped quite suddenly, the research has not been implemented, but the whole team had a good idea on where to go for further similar problematic.

It also started a reflection on adding some other technologies to our design system. First it was a NO GO, but as it was finally not so complex, we opened a breach in the wall :).