Fulfillment Planner
Empowering railroad yardmasters with an integrated scheduling tool.
UI/UX DESIGN
Yardmasters responsible for coordinating railcars and maintaining efficient fleet operations are constantly juggling incoming demand with railcar availability. Fulfillment Planner aims to take the questions out of yard management by validating incoming orders with railcar specifications, generating accurate railcar request forms, and allowing yardmasters to plan railcar switches several days in advance.
Disclaimer: Due to non-disclosure agreements with Wabtec Corporation, I am limited in the amount of work I can show.
ROLE
Interaction Design
Visual Design
Prototyping
Design Audit
DURATION
September 2019 - February 2020
TEAM
1 Designer (Me)
1 Researcher
1 Product Manager
5 Developers
TOOLS
Sketch
Whiteboard
Adobe Creative Suite
Invision
Miro
PROBLEM
Shipper operations grind to a halt when their yards fail to have the exact number of necessary railcars on their tracks.
Produced goods that get stuck at a production plant can lead to delayed revenue, product spoiling, or costly plant shutdowns.
Yardmasters who are responsible for planning and ordering railcars need a way to fulfill incoming orders while avoiding bottlenecking the railroad tracks with too many railcars.
TONY STEDGE
SOLUTION
Provide a customizable yard scheduler tool with built-in validations so that Yardmasters can easily plan railcar movements.
Fulfillment Planner gives the Yardmaster a custom-built view of their railyard and allows the user to drag orders and railcars to appropriate loading spots. They can assign specific rules to individual locations that restrict product type or railcar type, taking the guesswork out of order fulfillment. Each plan can also generate shift-specific switchlists to order railcars to or from their facility.
My task was to participate in the project research and distill our findings into intuitive designs that aligned with the existing product experience.
PROCESS
Discover. Ideate. Prototype. Test. Repeat.
It's always tempting to jump straight into designs when faced with a new project. This feeling becomes amplified with external factors such as commercial promises and oversimplified project scopes. That said, starting the project with adequate research is critical for making informed design decisions.
DISCOVERY & KEY INSIGHTS
At the start of this project, the product and commercial teams provided me and the UX Research Lead with introductory information about the Yardmaster's workflow. The information we received didn't give us a complete picture of the user's wants and needs. Several phone calls and a site visit later, we gathered information that provided the backbone for my designs.
Some of the main pain points:
Building a yard plan from scratch every day because there is no "roll-over" system for railcars from shift to shift.
Manual validations between loading spots, railcar types, and quantities are a heavy mental burden.
Duplicative work to build a yard-plan and then create a switchlist.
No built-in warnings to prevent ordering a car to a loading spot that is down for repairs.
Lack of visual cues makes it difficult for anyone besides the Yardmaster to understand yard operations.
IDEATION
One of the significant challenges consisted of diagramming the existing user workflow. Before diving into the project, we assumed that Yardmasters followed a linear process. In reality, users would complete Steps A-Z in every permutation imaginable.
This discovery prompted ideation sessions as we tried to map out a flexible yet understandable workflow.
Mapping the process ultimately revealed the need for an additional inbox-type module that allowed users to perform global actions on each plan made.
With the workflow established, I started white-boarding potential mockups. I focused on allowing flexible interactions wherein the user could step into any part of the railcar-planning process and complete their task. Several iterations later, I felt the designs captured the primary workflow.
PROTOTYPE
Next came prototyping. This product was joining a software platform that already existed, which limited my design palette. Because I could utilize only a few colors, I leaned on component placement, font weights, and intentional color usage to indicate interaction hierarchy.
Overall progression of the design from sketches to customer prototype.
TEST
Main Findings:
-
Additional Feature Request
In addition to placing orders, users wanted to black-out loading zones,
add comments, and other tasks.
-
Validation Differentiation
Users wanted to set which parameters would trigger warnings versus errors.
Interactable objects should also dynamically filter based on selection criteria.
The UX Research Lead and I presented the initial designs to internal experts and customers and asked them to attempt real-life scenarios in the prototype. This process led to several discoveries that elucidated a richer understanding of the user's task flow.
ITERATE
Next, I iterated my designs and integrated newly requested features into the prototype. The user begins by creating a new plan or selecting an existing one. Once the user opens the Planner, they can drag and drop either railcars or orders onto preconfigured loading spots. The system validates the order-car-spot combination and ensures that railcars from the previous shift roll over to the current plan. Users can add comments, then publish completed schedules to auto-generate a switch list to send to the railroad.
Due to the unpredictable nature of the user's workflow, I diagrammed every possible interaction to provide engineering with a clear map of expected behavior.
OUTCOME
A flexible planning tool to assign and validate railcars, orders, and loading-spots with roll-over data and export functionalities.
I worked with engineering to troubleshoot around tech-stack limitations and performed a design audit after the MVP release. The product was well-received internally and externally, leading to new customer acquisition and 54% of target revenue on quarter-release.
As a result of this experience, I learned about the importance of project scoping. At the start of the project, what appeared to be a straightforward design problem turned into a multi-faceted tool that contained features that the customer didn't realize they needed at the start of the project. Next time, I need to insist on clearly defining the project scope with the commercial and product teams to fully understand the customer's needs before designing a product that only meets 70% of their requirements.