01. Overview

Locomotive Management is a suite of applications that allow for the streamlined management and maintenance of a locomotive fleet. The suite consists of three applications that work together using a bespoke UI laid over an SAP backend. The suite consists of three applications one for Fleet Managers, one for Shop Manager, and one for craft personnel.

The Fleet Manager app allows the user to track the locomotives health and status before it ever arrives as well as plan and manage the shop capacity across the entire fleet.
The Shop Supervisor app helps to plan how to handle the locomotives once they arrive on site which includes - What maintenance is needed, what parts need to be ordered/replaced, and priority of repairs.
The Craft Persons app allows for tracking the work performed on the locomotive, by allowing users to clock in/out on a Work Order, expense repair parts, and detailing scheduled maintenance needed for that locomotive.

02. Problem

The Client was facing multiple issues which left both the leadership and craft personnel feeling frustrated in their ability to perform their daily tasks. Their existing software was outdated and was unable to be migrated over to a new backend. This as well as:

Lack of Reliable and accurate fleet information
No clarity in the lifecycle of a locomotive in a single application
Incomplete inventory management across applications
Better visualization of a shop layout and a locomotives status within that facility needed
Inconsistent brand standards resulting in every app looking and feeling different
Inability to track tasks performed within a single application

03. Process

Discovery and Delivery

The client on this project worked using a Dual Track agile process of Discovery and Delivery. The goal was to do all of the discovery out front (Research, Interviews, CJM’s, Low Fidelity Designs, Information Architecture, and User Testing) and get buy in from all of the key stakeholders in this case Upper management, the PO’s, and the technical architecture teams, before transitioning the work to the Deliver Process. Once in the delivery process we would then further refine the agreed upon flow and designs from the discovery track to patch any holes and expand on any missing details. This process was done by working closely with the lead UI and backend developers to ensure what was created was feasible in an SAP backed environment. The out come was a clear vision for the product before it ever reached the hands of the development team, and that work could be queued up in the backlog and picked up with minimal churn at a designated time.

Research

We conducted multiple sessions with the end users during the creation of these applications. We traveled to key identified shops in Alabama and Tennessee as well as worked with users in the main office in Georgia. When we were unable to conduct in-person interviews we did teams calls with the users. Through these sessions we were able to drive out what challenges they were facing as well as we were able to document their as-is workflows. During the documentation process we actively worked to capture not only what they did in a day but what applications they used to accomplish those tasks. This information was critical when we would work with the SAP technical architects to establish our proposed flows and was leveraged to identify what pieces of data were needed and where they would come from.

Conceptual Design

Once we had concluded the Research portion of the Dual Track process we would move into the Conceptual (Low Fidelity) design portion. At this stage we would take the As-Is workflow and begin to try and map it against the over arching vision of how the application and all its parts might come together. This was in essence a 3,000-foot view of how the application would work. We would map the touch points together to identify when the user might be transitioning between one application to another, what key pieces of data need to be called and when, and what the roles and entitlements that are required for this part of the application. We would also vet these low fidelity flows with Users and SME’s to ensure accuracy and a balance between what they needed versus what was technically feasible. The result of this would be a defined journey that could be then taken to the leadership team to get buy-in and transition to the delivery side of the dual track process.

Detailed Design and Delvery

The next stage in Dual Track was the detailed design phase. We would take the conceptual design and begin to plug any missing bits of information it that might be needed. For this stage we would work very closely with the UI team and the backend team. The goal was to ensure that we knew where each piece of data on the screen was coming from, how it would be used, and what was needed to get it there. We would also apply a unified brand standard to the visuals to ensure it looked and felt consistent with all other applications within the suite. Once we had polished and finalized the look and feel of the screen we would circle back with the end users to ensure what we had put in was what they expected to come out.

Power - Servicing Screen Example - Fueling

04. Results

While this project is still ongoing the result of the R1 and R2 release was a series of products that helped to ease the workload of shop supervisors and craft personnel.

The Craft Users app was able to reduce the overall time spent by a craft user dramatically by taking something took hours of their day and reducing it down to minutes. They were able to check off and track their work right where they worked rather than trekking back and forth to a workstation to input their information. This also helped to improve inventory management by allowing them to directly order what they needed as they worked.
For the Shop Managers app we were able to establish a process for representing a complex interactive map displaying position, status and key details for 3,200+ locomotives in 33 shops. This was a new process that was not being used anywhere else in the industry. There was much excitement among the end users to get this in the field across all shops not just the test locations.
Planned for an R3 release the Fleet Managers app was set to enable a total view of all of the shops, their capacities and all of the locomotives with that shop. This would improve the efficiency of the Fleet Managers as they balanced their work inside of their shop against the locomotives coming to them.

Feedback

“From the discovery process, the team is very involved by asking questions about the whole process so that nothing is missed or overlooked. The team supports all ideas brought to them by the business. The designs are always clean and well thought out, if there is an issue or we need a change, the team is all in with no complaints. Our ideas are what the team produces, I have never received a " we can't do that or that's impossible " your team makes it happen. I usually don't look forward to team meetings, but if I know it's a UX meeting I am excited to take part.”

“UX designers do a great job putting the user first in their design approach to SP&E, in particular the work done on [Locomotive Management]. Meetings with stakeholders was instrumental in learning business needs and implementing designs with form and function in mind. Within the team, changes based on user feedback created many discussions on possible solutions, and the UX group did a good job vocalizing the user’s pain points to come up with workable solutions.“

“Working with the UX team was by far the best aspect of my new job. To take a visual conception and see the Lo-Fi screens come to life was fun. I enjoyed the openness and creative environment that was encouraged. We were able to progress a vital aspect of [Locomotive Management] that will revolutionize modern day railroading.”