The working name for this conceptual product comes from the nickname of heavy freight locomotives used in Germany. Ludmilla is an app for managing emergency passenger transport in cases of unexpected accidents on railway tracks and train malfunctions. It also handles the management of removal or repair processes.
TIMEFRAME
10.2020 - 12.2020
TOOLS
Figma
Google Meets - interviews and testing
DISCIPLINE
UX research
UX design
RESPONSIBILITIES
Rail traffic management is fragmented into many different processes, each using specific procedures, software, and personnel from various specializations. One of these processes is emergency transport for passengers experiencing issues on railways. Currently, it's managed through numerous manual tasks that could be automated. The process relies on outdated software with a primitive interface that's not user-friendly. Every new person in this position requires extensive support from other experts to be properly onboarded.
The Railway traffic controller (EVU, Eisenbahnverkehrsunternehmen) is the most involved person in this process. Their journey begins when they receive a phone call from the Train driver reporting an issue. The controller then inputs this data into the system. However, the flow in the current software stops at this point. Subsequent processes are managed through phone calls, which are difficult to track and manage efficiently.
EVU controllers must call each Bus Company Owner (BCO) separately to ask about bus availability and capacity. In most cases, EVU receives direct calls from Bus Drivers seeking clarification on the issue location. There's no dedicated software for EVU to track required buses or manage planned bus routes to replace disrupted train journeys.
The customer, who was professionally involved in railway traffic management, presented a detailed proposal to address this problem, showcasing the results of his research. There was a clear need to improve the current workflow, as defined by potential end-users. The main objective was to develop desktop and mobile apps for three distinct user types:
Based on available resources from:
We could devise ways to automate key processes, reducing manual tasks and enhancing the tracking and management of railway incidents—from initial report to full restoration of railway traffic. The product will potentially launch only in the Bavaria area.
The initial face-to-face meeting with the complete product team and customer's stakeholders took place at Silevis's office in Kielce. During this meeting, we reviewed the entire idea and outlined all project goals and expectations. The main objective was to prepare a design prototype with high-fidelity, interactive app screens to represent the product's key flows and features without functional development. This prototype should effectively communicate the product vision. Its primary purpose was to present a proof of concept to stakeholders and secure funding for full development.
I ran a UX design workshop where we used idea generation activities, primarily based on sketching with a "note and vote" process, to encourage discussion and gather more insightful input from different perspectives. I presented the idea of writing down scenarios for all types of users that the product's key features should cover. We then revised these scenarios and decided which ones should be included in the design prototype.
The next phase involved specifying design directions and discussing user flows in depth, including dependencies between users and potential branches. We examined specific content and actions across crucial screens, which helped us define more details.
I started creating a detailed user flow in Figma, using my personal resources to mock up each screen with content, actions, decisions, and connections. This foundational version facilitated UX sync meetings with both the product team and the customer, including potential end users. During these meetings, we reviewed the flows in depth, refining the interactions and identifying potential improvements.
This was an iterative process. Based on the feedback, we ended up with a complete guideline to start working on high-fidelity wireframes.
Initially, I suggested basing the wireframes on an existing design system. I proposed using Ant Design for several reasons: it's open-source, which is a significant advantage for potential development; it provides a basic UI that makes the prototype look more like a working product; and the developers in our product team are familiar with React and TypeScript, making it their preferred option.
After designing and validating wireframes, our final goal was to create an interactive Figma prototype for the client. I also recorded walkthroughs of the prototype on both desktop and mobile devices. This approach makes the content more accessible, particularly for those unfamiliar with Figma navigation, and enables versatile uses such as presentations.
