Project Overview
TL;DR: Southwest's Ops technology group builds the internal 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.
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.
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.
What keeps a system from becoming the next 2014 library
A component kit 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.
Component request → release: Program team request → Design review → Jira backlog → Prioritize backlog → PI planning.
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.
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.
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.