We recommended removing it. They said no. Then the real design problem started.
Union Pacific’s Atlas platform held location and status data for assets across one of the largest rail networks in North America. Thousands of employees used it daily — operations managers, engineers, and field crews in active railyards.
The problem wasn’t missing data. The problem was the opposite. Atlas had accumulated years of features: some actively used, some obsolete, some duplicated across three different systems, all treated as equally relevant. Users had learned to navigate around what they didn’t need. They’d built workarounds. They always do.
22 interviews. 7 departments. Including field crews on active floors.
The research goal was 25 interviews. We hit 22. The gap wasn’t indifference — three departments were field crews working active railyards, and pulling someone off the floor for an hour requires timing and trust that takes time to earn. 22 across 7 departments, including those crews, is a number worth defending.
What we were listening for wasn’t feature requests. It was friction — the moments where the tool interrupted the work instead of supporting it. Where people had invented a workaround. Where they’d stopped using a feature not because they didn’t need it, but because finding it cost more than the benefit.
Six domains. Same expectation everywhere.
Before touching the interface, we needed to understand what users already knew — not about Atlas, but about mapping tools in general. The analysis covered six domains: navigation, food delivery, recreation, real estate, field services, and logistics.
For each, we broke the UI down to functional anatomy: where search lived, where filtering lived, how layers surfaced, how users moved between macro and detail views. We mapped those patterns onto a color-coded wireframe overlay and ran the same analysis on two existing Union Pacific internal tools.
The finding was consistent: users carry strong spatial expectations from consumer apps into enterprise tools. The gap between what Atlas users expected and what Atlas was asking them to learn was significant — and largely unnecessary. This competitive analysis method became a reusable research tool for the broader team.
Nothing could be removed. The constraint was the design problem.
The client’s position was clear: nothing gets deleted. Data that hadn’t been touched in years stayed. Functionality that had migrated to other systems stayed. Duplicate access points stayed. The constraint wasn’t negotiable.
That changes the design problem entirely. When you can’t reduce the content, the interface has to create the perception of clarity through organization and hierarchy. Every decision becomes about what surfaces first, what recedes, and what stays buried until someone specifically goes looking for it.
The solution was a layered filtering and toggle system built around the research hierarchy. High-frequency data on by default. Secondary layers behind filtering. Legacy data accessible but requiring deliberate intent. No data removed — but for the first time, the interface reflected a point of view about what mattered. Redundant access points made consistent in labeling, behavior, and visual treatment regardless of location.
Cross-departmental alignment on a system that worked for both office and field.
For the first time in the platform’s history, the interface reflected a clear point of view about information priority. Cross-departmental alignment was achieved on a filtering system that worked for both office users and field crews in active railyards — two groups with fundamentally different contexts and usage patterns.
The competitive analysis method — breaking consumer mapping apps down to functional anatomy — became a reusable research tool for the team. Stakeholder buy-in on a constraint-based solution was achieved after the initial removal recommendation was declined. The pushback was part of the process.