Modernizing a 29-Year-Old System That Still Runs 4,000 Flights a Day

The situation

The 7th attempt at fixing a 29-year-old system.

SWIFT has run Southwest's flight operations since 1995 — six prior attempts to replace it had already failed.

SWIFT has been part of the backbone of Southwest Airlines' daily flight operations since 1995, coordinating over 800 planes and 4,000 daily flights. Its core job is capturing and surfacing the downstream effects of flight disruptions: when a flight is delayed, canceled, or rerouted, SWIFT notifies Superintendents of Dispatch (SODs) of the ripple effects across crew scheduling, ground crew, and maintenance. It also tracks legally mandated crew duty-hour limits, flagging when crew members are approaching the maximum consecutive hours they're permitted to work under federal regulation. Stellar Elements was brought in to design SWIFT's replacement — a modernized tool named WOLF, built to serve that same core purpose with a system that could actually keep pace with the business. This was the 7th attempt at solving this problem.

The stakes went beyond the product itself. In December 2022, Southwest suffered a widely reported operational meltdown, canceling nearly 17,000 flights over the holidays and stranding millions of travelers. Public reporting attributed the collapse primarily to a different, separate crew-scheduling system, overwhelmed trying to reassign crews at the scale the disruption demanded. The fallout triggered a Senate Commerce Committee hearing, where Southwest's COO told lawmakers, "we messed up." Southwest was later fined $140 million by the DOT — the largest fine of its kind in the agency's history — and committed to a large-scale technology overhaul, including over $1 billion in IT infrastructure investment. SWIFT wasn't the system named in that event, but its job sits directly adjacent to it: an airline under public and regulatory pressure to prove its operational systems could be trusted, with a congressional commitment that meant the usual latitude to slip a software timeline wasn't really available here.

Southwest also has an established internal design system — Jetstream — built and maintained by Stellar Elements, already supporting 7 applications across the company. Starting in 2025, Southwest mandated that all new applications adopt it, so WOLF wasn't just a modernization project — it was one of the first real tests of Jetstream applied to one of the company's most complex, highest-stakes tools.

The challenge

Real constraints, not hypothetical ones.

Four things made this project genuinely hard, independent of the design work itself. We couldn't load or interact with the live SWIFT system due to regulatory constraints, so understanding its real functionality meant relying entirely on meetings with SODs and recorded video walkthroughs. Nearly three decades of institutional habit had formed workflows that didn't always align with modern UX practice — but SWIFT's user base is small, highly specialized, and deeply practiced in the existing system, so every proposed change had to be weighed against genuine disruption cost, not just theoretical improvement. The third-party dev team's default platform choice aligned with neither Jetstream nor Southwest's broader direction, and they had a history of working in silos with no prior experience collaborating with a UX team — the collaboration model itself had to be built, not just the product. And there was no initial roadmap, but a fixed external deadline: design work had to stay a full Program Increment ahead of development, while still tracking against Southwest's public commitment to Congress.

The approach

Reconstructing 29 years of institutional knowledge before designing anything.

Every feature decision anchored in how SODs actually handle disruptions.

With no direct access to SWIFT, we relied on a 10-year prior relationship between Stellar Elements and Southwest to get up to speed quickly, drawing on existing project history and documentation, and met with three SODs for an initial deep-dive interview — the people who manage the daily flight schedule and handle Irregular Operations (IROPs), the disruptions that make or break a functional flight-tracking tool. Because IROPs are the highest-stakes, highest-frequency problem SODs deal with, supporting them well was close to the whole point of the redesign. SWIFT was responsible for surfacing when a flight change put a crew member at risk of exceeding federally mandated duty-hour limits — a real legal compliance issue, not just an operational inconvenience — and WOLF had to preserve and improve on that, not lose it in the rebuild. That constraint shaped how urgently and how clearly disruption-related information needed to surface throughout the redesign, not just in a single feature. Requirements gathering with product owners and SODs was shared across the three of us on the WOLF team, rather than owned by any one person.

That same discovery work surfaced a smaller but consequential finding: SODs operated in darkly-lit rooms, where a standard bright interface was genuinely jarring rather than just a preference. That observation pushed a dark-mode component initiative for Jetstream — WOLF wasn't just consuming the design system at that point, it was identifying a real gap in it and contributing the fix back.

1.0A SOD's actual working environment — dim lighting, multiple monitors

We used Jetstream as a foundation rather than a constraint to work around, meeting biweekly with Stellar Elements' dedicated design-system team to align on new patterns and evaluate what should be incorporated back into it. Those governance sessions also kept us aligned with everyone else building on the library: we were three designers on WOLF, but nine designers were working across Southwest's tools at any given time, with two to three other projects running alongside ours, so a new pattern had to hold up in tools we weren't designing. Early design work focused on re-skinning WOLF's basic framework to align with the existing system, deliberately sequencing new features and workflows into a later phase rather than trying to solve consistency and new functionality simultaneously.

Building the collaboration model the dev team didn't have.

Since the third-party dev team had no prior experience working with UX designers, part of the work here was procedural, not just visual: establishing new workflow diagrams collaboratively with product owners and SODs to validate the basic journey before any screens were built, and holding design review meetings up to three times a week so the team could catch misalignment early rather than discovering it late. Handoff couldn't be a document dropped over a wall, either — we created a dedicated "Dev Ready" Figma file with full documentation for every story, ran handoff meetings where designers walked the dev team through that documentation directly, and performed follow-up desk checks to confirm each story was implemented correctly before final approval.

1.1Dev-Ready documentation — IROP Multi-Hold flows

Craft highlights

Efficiency, not decoration.

In an operations tool where every flight adjustment has real downstream consequences, speed and efficiency weren't nice UX qualities — they were paramount. Three examples of what that meant in practice:

Pop-Out In-Panel

⇕

1.2Hold Flight in-panel / pop-out windows (drag the divider)

The in-panel/pop-out approach was a solution the three of us on the WOLF design team proposed together, then worked with the dev team to pressure-test what was actually feasible — exploring the difference between a floating window and a new browser tab, and how a floating window could be positioned and sized within a particular area of a SOD's monitor. We also worked directly with SODs to determine dismissal behavior case by case: which floating windows should close automatically once a user exited a flow, and which needed to persist and require a manual close — a distinction that mattered in a high-density, multi-monitor environment where a lingering or a too-early-closing window could cost a SOD real time during a disruption.

1.3Stepper inputs across time- and date-based fields

Stepper input fields were introduced across time- and date-based fields to maximize efficiency for users making frequent, similar adjustments throughout a shift.

1.4Canceled Flight List — anatomy of the dialog

Table functionality was extended to support bulk actions across multiple aircraft lines at once, filterable search, expandable accordions for additional detail, and a toggle to soften how intrusive auto-updates felt during active use — each aimed at reducing friction for SODs managing many flights simultaneously under time pressure.

Outcome

Not a measured result — a test of operating inside real complexity.

There isn't hard outcome data available for this engagement — the design work was completed and handed off to development, but visibility into what happened after that point wasn't something the agency engagement gave access to. Southwest's design phase was also shortened due to a companywide cost-cutting effort tied to a revenue shortfall — worth naming honestly as context for the timeline, not as an outcome. Despite that, all new features outlined in the roadmap were completed and successfully handed off to development, including all major patterns, unique workflows, and components the dev team needed to build.

What this case study demonstrates isn't a measured business result — it's the ability to operate inside real institutional complexity: a regulated system I couldn't access directly, a user base with 29 years of ingrained habit, a third-party dev team with no prior UX collaboration experience, and a deadline tied to a public commitment to Congress, all navigated by a 3-person design team working inside a much larger, harder-to-move organization. That's a genuinely different kind of difficulty than the other work in this portfolio, and it's presented here on those terms.