What a freight railroad taught me about designing from the field
BNSF was modernizing mainframe systems older than most of its workforce, governed by federal rules and union agreements written in the 1860s. I co-led the UX strategy and built the playbook three flagship programs ran on. The instincts I now bring to AI strategy were formed on the floor of a network operations center.
The hardest part was the knowledge trapped in people's heads
A freight railroad runs on decisions that live with dispatchers and clerks, not in the software. The software showed the data and left the judgment to the operator. My job was to get that judgment into the system without taking it away from the people who held it.
Crew handling is one of the railroad's largest expenses after fuel, and scheduling it is nothing like finding an available driver. Federal Railroad Administration rules, union agreements that date back to the 1860s, geography, traffic, and bridge and track maintenance all constrain who can move a locomotive and when. Moving one train can require two or three crew under the agreement signed with the local union.
The systems managing all of this were mainframe and mid-tier applications built decades ago. They were comprehensive and unreadable. The knowledge of how to actually run the railroad well, which crew to pull, when to rest them, what a taxi from the next terminal costs against the delay, sat with the people, while the screens displayed every field and recommended nothing.
I had no authority over the programs. I had a playbook
I came in as a Senior UX Designer and co-led the UX strategy for a multi-year IT modernization. I had no direct authority over the legacy solution architects, the business analysts, or the product owners spread across the programs. The users I designed for sat in network operations centers and on track miles from any design studio. Influence had to come from method and evidence.
So I built the leverage I did not have. I developed a UX playbook the modernization could run on, a repeatable way to move from a legacy mainframe to a tool people trusted, and then I proved it on three flagship products: crew scheduling, workforce planning, and field asset management. The playbook is the through-line. The three programs are how I know it works.
Four practices, run on every program
The playbook came down to four bets about where good enterprise design comes from, and they held across desktop operations and mobile field work alike.
The same bets, applied three ways
Each program took the playbook into a different corner of the railroad. The depth of each, the search mechanics, the resequencing interaction, the column reductions, lives in the individual case studies. Here is what each one proves about the method.
Scheduling a federally regulated railroad meant holding FRA rules, union agreements, geography, crew availability, and maintenance windows in one view. The legacy tool showed all of it in a dense grid and helped with none of it. Dispatchers carried the actual decision in their heads.
I cut the data clutter and built a Decision Assist layer that turned dispatcher tribal knowledge, FRA rest policy, taxi versus crew cost, train priority, into a recommendation the operator could accept or override. Chart and map views let the schedule be read over time and across geography instead of column by column.
Crew clerks, dispatchers, and yardmasters managed the workforce across 10 divisions, 350-plus stations, 1,000-plus boards, and more than 250 data points. One clerk described the daily reality plainly: running eight different mainframe sessions just to begin finding the problem. Location data was trapped in grids, so people kept paper maps on their desks to reason about upstream and downstream effects.
I designed a single dashboard as the source of truth, a freeform typeahead search that let users group data naturally across the hundred-plus combinations they actually used, and a geographic component that retired the paper maps. For the resequencing exception that the legacy system handled in 40 to 60 minutes, I borrowed the school bus: a sandbox where records get picked up, reordered, and dropped at their final position.
Track and bridge foremen inspect and repair on FRA-mandated maintenance windows. On paper the day was a checklist. In practice a four-hour window got cut to two mid-shift, defects appeared that were not on the list, and a foreman on vacation meant routine work simply lapsed.
Two half-day ride-alongs produced a journey map and a set of job-to-be-done stories I shaped into one narrative leadership could commit to. The mobile app put tasks on a map by milepost so foremen reached the location without hunting for it, let them report partial work when a window shrank, and let them log a defect they spotted themselves so they were never penalized for unplanned work.
The result was a method that outlasted any one program
Dispatchers, clerks, and foremen sat inside the work, in field research, validation, and idea sessions, so the tools were built for the user group rather than presented to it. The Crew Scheduler overhaul earned recognition in the railroad community.
Three legacy modernizations shipped across the operation: scheduling, workforce planning, and field asset management, spanning dense desktop tools and a mobile field app.
A reusable UX playbook, field immersion, physical prototyping, knowledge codification, reduction, and validation, that any program in the modernization could run on without me in the room.
2.5 million lines of legacy process decommissioned, decisions made faster against one of the railroad's largest cost lines, and scheduling and reporting time cut by half or more.
The new tool cut the time to identify a schedule problem and fix it by half.
Crew Scheduler outcome, railroad operationsWhat I carry forward
The field trip was the design tool, and I treated it as my habit before I made it the team's requirement
The highest-signal input on every program was time on the floor, but early on that depended on me showing up. The playbook existed partly to fix that, to make immersion something a program required rather than something a single designer happened to value. I am still working out how to hand that down without it degrading into a checkbox.
Reduction is harder to sell than addition
Taking a 50-column tool to 14 read, to people who equated density with control, as taking power away. Arguing the principle did not move anyone. Bringing the before-and-after and the measured task time into the room did. It is still the hardest move I ask a stakeholder to sign off on.
Codifying tribal knowledge is where I started designing for AI
Decision Assist was a rules engine, not a model. But the instinct, surface the expert judgment the system already implies and let the user keep the decision, is the same one I now bring to AI strategy. The honest limit is that a rules engine ages badly. The next time, I would design the knowledge layer to learn.
See how that instinct became an AI strategy at Smartsheet →