top of page

Work List

The all-in-one scheduling tool for railroad superintendents. 


Service Planner Mockup.png

Train operators and conductors make up the backbone of the railroad industry. Their daily tasks directly allow large goods to traverse the country reliably and with minimal fuel usage. The current software utilized amongst Class II and Class III railroads received constant feedback of poor usability and frustrating mechanics. We wanted to design a modernized solution for railroad crews to improve the quality of life for the hard-working me and women in the railroad industry. 


Interaction Design

Visual Design


User Testing


July 21 - Dec 21


1 Designer (Me)

1 UX Researcher

1 Product Manager

5 Developers




Adobe Creative Suite




Too much effort, too little value.

A railroad crews need to know two things to perform their job:

1) Where they are going and;

2) What equipment needs to move.


While moving railcars, conductors and crew members record their progress by utilizing a tablet-based software called mCrew. The software garnered a reputation of being confusing and difficult to use. Some frustrated crew members would refuse to use the tablet altogether, opting to fax in a hand-written summary and relying on customer service to digitize their records. 

A rule of thumb in logistics is that real-time data is king. Delayed data entries can create confusion when trying to track shipments. Many customer disputes occur due to rental rates beginning or ending at the wrong time. (Imagine if you rented a car and getting charged an extra day because it got scanned in a day after you returned it.) If we could address the crew member's pain points, we could encourage more software engagement and get closer to real-time tracking. 


Design System - Limited to company's themed Google Material design system's component library.

Offshore Development Team - Added layer of complexity in communication and sprint planning. 

Wooden Hut

Research &

Our team (me and 1 UX Researcher) started by interviewing internal stakeholders and subject matter experts. For two weeks, we gathered information about the internally known issues with mCrew and the characteristics of folks who regularly used the software. 

We then took our findings to a holding company that partnered with us on this project. This company represented the needs of 100+ individual railroads and helped us understand the various kinds of problems a railroad could face. Once we confirmed our internal findings with the holding company, we synthesized two personas.

Crew Persona.png

Crew member persona developed from subject matter experts and prior research.

Trainmaster Persona.png

Trainmaster persona developed from subject matter experts and prior research.

Key Insights

The user interviews, focus groups, and prior internal research uncovered additional pain points in the existing software. These identified issues provided clear objectives for the design phase of the project. 

Difficult Navigation


There are too many accordions and non-linear paths making navigation unintuitive. 

Exception Handling


Correcting an accidental data entry requires a lot of time and a confusing number of clicks. 

Device Rotation

Device Rotation.png

The current system is locked in landscape mode. Users would like to maximize the number of railcars on the page.

Color Palette


The system uses a variety of colors and conflicting hues, often breaking the rules of color hierarchy and selection affordances.

User Flow

I first set about mapping out an intuitive workflow to address concerns around navigation. The existing software prioritized moving equipment one at a time. After many iterations, I opted to create a linear workflow focused on completing specific tasks. Each task would logically separate groups of railcars, thereby allowing crews to complete car moves in bulk (saving time and effort). 

User Flow - Work List.jpg


Next, I began sketching the new product. I took inspiration from other tablet-based logistics software and sought to maximize data presentation with ease of use. 

I needed to test these designs with actual crew members. I started by validating my prototypes with the holding company every week. After a few iterations and virtual user testing sessions with the holding company, I conducted in-person user-testing with train conductors. 

ork Lists - Sketch.jpg
ork Lists - Low Fi.jpg
ork Lists - Mid Fi.jpg

Final Design

A modernized, streamlined mobile application that simplifies the railcar tracking process.

On the whole, crew members approved of the updated designs and flow. A few conductors mentioned they appreciated having their opinions heard. I took note of interactions that seemed unfamiliar to the crew members and attempted to address residual pain points in the following design iterations. 


A few key learnings from this project:

Fight for the voice of the end-user. 
Scheduled weekly cadences with a holding company provided a vast amount of knowledge and expertise. Over time, it felt comfortable to rely solely on the opinions of the holding company representatives (many of whom once were end-users). Nothing compares to talking to the individuals who will use the software. 


Value of in-person user testing.
The global pandemic made conducting in-person interviews very difficult. Today's technology helps bridge the social distance gap, but nothing compares to face-to-face conversations. Many facial expressions and body language cues get lost over a screen. I'm excited for the day when in-person interviews can be conducted safely without concern. 


Test in the real world.
I conducted many sessions with the client over pdf documents and prototypes. Even though I sized my artboards/canvases to the appropriate device size, nothing compared to purchasing a Samsung tablet and mirroring the prototype on the physical device. When testing the printed components of the product, physically printing out worksheets uncovered readability issues that were invisible on a crisp digital screen. 

bottom of page