Project Overview
TL;DR: Southwest's Ops technology group builds the internal enterprise tools that Network Ops, Ground Ops, Tech Ops, and Crew Planning run the airline on: flight following, gate management, crew turns, schedule changes. Four teams, two front-end stacks, and, since the org's original 2014 pattern library had quietly fallen out of use, no shared foundation between any of it. Design was led on the projekt202 pod that built the business case, the foundations, and the governance model for a shared Ops Component Library.
Role: Design Lead, projekt202 pod, engaged on Southwest Airlines' Ops Tech account. Timeline: Strategy through Build, 2017 to 2018. Scope: Foundations, Components, Governance.
The Challenge & Context
Interviews with the designers, developers, and a design manager working across these teams surfaced the same handful of themes over and over: nobody had a common language for the patterns they were all rebuilding independently, nothing forced consistency between an onsite team's work and a vendor team's, and no one owned the problem enough to fix it. "You get a website that's a Frankenstein monster with everything looking different," one developer put it. A re-platforming effort meant to let teams "change once, update everywhere" had quietly become the opposite, because the process to make that true had never been built alongside it.
The Process & Decision-Making
Before a single component was designed, the case had to be built for why the org should fund a real one. Design-system-mature companies (Airbnb, Salesforce, IBM, Atlassian) and close industry peers (Sabre's Spark system, FedEx's component library) were benchmarked for how they treated their systems as staffed products, not side projects.
Licensing an existing system, Sabre's Spark chief among the options, got a real look before the case for a custom OCL was made. Spark was built for airline reservation and distribution, not for a dual-framework Ops environment with accessibility built in from day one. Buying would have meant retrofitting it to fit, which was the exact cost the build was meant to avoid.
Then came a model of what a system would actually be worth at Southwest: time saved on asset handoff, on component compatibility between teams, on art direction that no longer needed reinventing per screen, on rework that never should have happened. That model became the pitch: a roughly $190K, three-month build staffed with an Experience Director, UI Architect, UI Developer, and UX Designer, against a projected $1.65M in annual savings. It's the number that got a dedicated, cross-functional pod approved.
The Solution & Final Design
Accessible by default, not by retrofit
With the pod funded, an alignment workshop inventoried every pattern already floating around the org (including a Sketch library marketing had quietly built on its own) before a single foundation was defined to build everything else on.
Ops screens run around the clock, often in low-light control-room settings, so light and dark UI were both first-class from day one, with explicit rules for which layered surface and text colors paired together in each mode. Accessibility followed the same rule: WCAG contrast ratios and ARIA markup were built into every component as it was designed, not audited in afterward. It was the only defensible approach on a system shipping in two frameworks at once, where fixing it twice would have meant fixing it four times over.
Accessible components identified correctly to assistive technologies, from the first component out. That was the OCL's accessibility principle, applied per-component from day one.
Color didn't ship as a swatch sheet, it shipped as a token architecture: named values with hex references and usage notes attached, so "SWA Orange" meant the same thing whether a developer was styling a button in React or Angular, and updating the token updated every consumer of it instead of every screen that happened to reference the hex code directly.
Shipped twice, designed once
The OCL had to serve four teams that had already committed to two different front-end stacks, so it shipped as parallel React and Angular implementations built off the same foundations and the same component specs (buttons, form elements, date pickers, tables, modals, tooltips, drawers, and more), documented on matching sites so a developer on either framework saw the same rules.
Four Ops teams (Network Ops, Ground Ops, Tech Ops, and Crew Planning) were supported by two parallel libraries, a React Component Library and an Angular Component Library, both built on the same OCL foundations.
Parity wasn't a one-time build milestone, it was an ongoing discipline. When a component drifted between frameworks, a state that rendered correctly in React but not yet in Angular, or the other way around, the fix went back to the shared spec first, not the individual implementation. That's what kept a two-framework system from becoming two systems that happened to look similar on launch day and diverge from there.
What keeps a system from becoming the next 2014 library
A design system without an owner is just a snapshot of the day it shipped, which is exactly what had happened to Southwest's last one. So governance got designed alongside the components, not bolted on after: a dedicated pod, a defined intake process, and a release model that respected teams that couldn't drop everything to upgrade.
The pod's four roles:
- Scrum Master / BA: runs Scrum of Scrums, RAID, triage; owns release & versioning comms; manages backlog, writes stories; leads Scrum ceremonies.
- Design Lead: approves component lifecycle; champions the OCL across teams; owns the Sketch library, versioned in Abstract.
- Developer Lead: helps groom & deliver the backlog; consults on current & future components.
- Developer: builds to standard, in both frameworks; keeps API & docs site clean; flags reuse across consuming apps.
Design wasn't a stakeholder the pod consulted, it was one of the four seats making the call. The Design Lead's sign-off sat next to the Developer Lead's in every lifecycle decision, so craft judgment, not just technical feasibility, decided whether a pattern was ready to leave the backlog.
That authority sat with the pod itself, not a cross-org steering committee. The Design Lead's sign-off on a component's lifecycle, moving something from proposed to adopted to deprecated, was a pod-level call, made against the intake criteria rather than escalated for consensus every time. That was deliberate: a governance model that required broad buy-in for every decision would have been exactly the kind of process overhead that helped kill the 2014 library's momentum in the first place.
Component request → release: Program team request → Design review → Jira backlog → Prioritize backlog → PI planning.
A status-badge pattern built for Ground Ops got promoted into the shared library once two other teams asked for their own version of it independently. That repeat, unprompted demand, not a design review alone, was what moved it from local pattern to OCL component.
A gate-map visualization built for Network Ops stayed local on purpose. It depended on data and interactions specific to that one team's workflow, and generalizing it into the shared library would have meant building configuration options nobody else needed just to call it global.
Releases followed a defined change log and communication plan, with QMO involved early rather than at the end. Critically, consuming teams could review a new version and opt out of it: a small governance decision that mattered a great deal, given the library shipped in two frameworks that both had to stay usable without forcing every team onto the same clock.
That optionality was a direct answer to where resistance was most likely to show up. A team mid-sprint on a release of their own wasn't going to welcome a mandatory version bump on someone else's timeline. Letting consuming teams review a release and opt out of it, rather than forcing adoption on the OCL pod's clock, was what made the model something teams would stay inside of instead of routing around.
Impact, Outcomes & Learnings
The ROI model became the thing that actually changed the org's behavior. A projected $1.65M in annual savings against a roughly $190K build cost is what turned a vague sense that the org probably needed a design system into a staffed, funded pod, and once it existed, four previously disconnected Ops teams on two different frameworks had a shared source of truth for the first time since 2014.
The signal that it was working wasn't a survey, it was the intake process actually being used: program teams routing component requests through the pod instead of quietly rebuilding their own patterns again, and consuming teams engaging with new releases, accepting some, opting out of others on their own timeline, rather than ignoring them outright. A system nobody requested components from, or one where every team opted out of every release, would have told a very different story.
Reflection: This project sharpened the case for design systems as organizational infrastructure, not a component kit. Southwest's teams weren't short on components: marketing had its own Sketch library, dev had already gone component-driven. What was missing was governance: a shared owner, a defined process, and a funded case for why any of it mattered enough to staff. Building that case turned out to be the real design work, and the pod is what kept the system from quietly becoming the next abandoned 2014 library. It also sharpened the sense of what "accessible by default" actually costs and returns when it's designed into foundations from the start: on a system spanning four teams and two frameworks, retrofitting WCAG compliance later would have meant redoing that work four times over instead of once.