Two legacy tools.
One modern platform
built from scratch.
Before CCS+, United Airlines pilots managed their schedules across two separate tools: a legacy internal system and a third-party app called Crew Companion. Both were non-responsive, built on 90s-era UI patterns, and deeply frustrating to use. Neither communicated with the other, forcing pilots to constantly context-switch to complete a single workflow.
United's answer was CCS+, a single, modern, mobile-responsive platform built in-house to replace both. I joined the project from day one, before it had a name, when the team was still designing and building the foundational components from scratch.
The Trade Center is the most critical and highest-traffic feature of CCS+. It is where pilots trade trips, pick up open trips, manage requests, and check schedule legality. For a pilot, a wrong trade doesn't just mean inconvenience. It can mean a compliance issue or a missed paycheck.
"Before CCS+, the tools were so outdated that pilots had to switch between two separate apps just to complete one task. There was no trust in the system. They were scared to click things."
I flew to Houston, Denver,
and Chicago to find out
what pilots actually need.
In-person research wasn't optional for this project. Pilots operate in high-stakes, time-pressured environments where a wrong tap can have real consequences. To understand that, I needed to be in the room with them.
I traveled to Houston twice, Denver, and Chicago, sitting with pilots, watching them use the legacy tools and early CCS+ prototypes, and listening to what made them hesitate. What I found wasn't just a list of feature requests. It was a trust problem.
Pilots would hover over a button and pause, visibly unsure whether clicking it would trigger something irreversible. They were not confused by the interface. They were scared of it. That shifted everything about how I approached the design.
The key insight was that experience level changed everything. Frequent traders had muscle memory and tolerance for ambiguity. Trainers and infrequent users had none of that. They needed explicit signaling, clear reversibility, and visible confirmation at every step. Designing for both meant building a system that was efficient for power users without being intimidating for everyone else.
From requirements
to shipped code.
Every feature in CCS+ went through the same four-stage process. Not as a formality, but because each stage catches something the others miss. Skipping one almost always created rework downstream.
Before sketching anything, I read the user story carefully, then had direct conversations with the business analyst, stakeholders, and the lead designer. The goal was to surface ambiguity early. What does done actually look like? What constraints exist that are not written in the ticket? What are stakeholders optimizing for versus what the user actually needs? Misalignment at this stage is far cheaper to fix than misalignment after designs are presented.
Paper first, always. I sketch fast and broadly, getting every possible direction out before evaluating any of them. The point is volume, not quality. The early trade board sketches below show this: multiple layout approaches for the same dashboard, different ways of surfacing the engine run timer, different structures for the calendar and pay summary. Nothing is precious at this stage.
Before moving a sketch into Figma, I check it against four things simultaneously: Does it solve the actual user story? Does it align with existing design standards and Orion components already in the app? Is the technical lift reasonable given the sprint scope? Does it fit the page or flow it needs to live in? If a direction fails more than one check, I go back to sketches rather than investing in a Figma mock that will get rejected.
The strongest sketches go into Figma for higher-fidelity exploration. I iterate until the design is ready to present, incorporating feedback from design review and stakeholder sessions before final approval. On CCS+, I also implemented approved designs in Angular and SCSS, which meant I caught edge cases before engineering did and resolved them in the same sprint rather than opening new tickets.
Early sketches
These are from the earliest exploration phase of the Trade Board, before anything went into Figma. You can see the dashboard structure being worked out, the engine run timer concept forming, and the timeline color-coding system for seniority windows taking shape.
Trade Board overview: navigation structure, trade pool table, and pay summary accordion taking shape in first pass.
Engine run timeline with color-coded seniority windows: green for all pilots, blue for line holders only, purple for reserve windows.
Calendar layout iteration: exploring how to surface pay summary, engine run info, and schedule in one scannable view.
Engine run detail state: in-progress timer, processing message, and next-run scheduling details alongside the calendar view.
From legacy chaos
to structured clarity.
The before state wasn't just visually outdated. It had no information hierarchy, no visual language for trip data, and no way to scan across multiple items efficiently. Every screen required the pilot to read, not scan.
Dense legacy table, no visual hierarchy, no data prioritization, no trip visualization.
Modernized Trade Center with visual trip bars, horizontal and vertical scroll to surface all data in a single row, and clear hierarchy.
Static column configurator with no live preview and minimal usability.
Live trip bar preview, drag-and-drop column reordering, multi-breakpoint support, reusable template component shared across multiple views.
Raw data dump. No grouping, no visual structure, no way to orient quickly by date or position.
Date-grouped, collapsible sections, searchable filters, consistent with the table system used across CCS+.
The decisions that
mattered most.
Every major decision on CCS+ had downstream consequences. The platform shares components across features, so a change to one pattern ripples through the entire system. These were the calls I made or advocated for that had the biggest impact.
Designing inside
real constraints.
CCS+ wasn't a greenfield project. It was built on an established design system, with an engineering team managing complex backend business rules, a compressed timeline, and stakeholders with strong opinions and limited UX fluency. Navigating all of that simultaneously was part of the job.
All UI was built using Orion, United's official design system, with Angular Material components aligned to Orion standards. Change requests that required new component variants meant frontend rework, backend integration changes, and regression testing everywhere those components were used. We frequently redesigned within existing constraints rather than requesting new components.
Trip trading is governed by union contract rules, FAA regulations, and United's scheduling logic. A pilot can only pick up a trip if it's schedule-legal, and "legal" involves dozens of overlapping constraints around rest periods, flight hours, and position qualifications. Every UI decision had to account for these rules without surfacing their complexity to the pilot.
Decisions affecting 15,000 pilots were sometimes made by a single stakeholder acting on personal preference rather than user data. We worked to counter this by bringing user testing findings into every design review, documenting rationale formally, and proposing phased releases that let us validate with real users before committing to large changes.
CCS+ was one of several concurrent projects. I was simultaneously working on FA CCS features, the Trade Board Engine Admin App, and contributing to Orion extensions. Scope cuts were frequent and often painful. Features I had designed and tested were cut before reaching production. Knowing what to fight for and what to let go was a constant judgment call.
End-to-end ownership
across multiple workstreams.
CCS+ was a large, multi-team effort spanning 30+ people. Here is an honest accounting of what was mine, what was collaborative, and where I took a leadership role beyond the design work itself.
| Feature / Area | Ownership | Notes |
|---|---|---|
| Trade Board Pool Display redesign | Sole designer | End-to-end design and Angular / SCSS implementation |
| New Request complete overhaul | Sole designer | Full redesign from scratch, designed and implemented |
| Customize Trip Modal | Sole designer | Live preview, drag-and-drop reordering, reusable template component |
| Trade Board Filtering | Sole designer | Filter modal pattern reused across multiple CCS+ views |
| Admin Communications App | Design lead | Owned from discovery to delivery; mentored a junior designer through this project |
| Trade Board Engine Admin App | Sole designer | Designed from scratch, no prior reference; extremely data-heavy audit tool for scheduling operations |
| Orion Design System CCS+ extensions | Collaborative | CCS+ required Angular Material components rather than native Orion components due to platform constraints. We built a CCS+-specific layer that aligned visually with Orion standards while meeting the technical requirements of the application. Contributed to dark mode implementation and extended the system for use across other United employee apps. |
| In-person user research | Active participant | Traveled to Houston (x2), Denver, Chicago; sat with pilots, facilitated sessions, brought findings back to design |
| Acting design lead | Interim leadership | Stepped in as primary design resource during team lead's maternity leave; reviewed designs, led standups, managed design priorities |
What I learned
building from scratch.
I have been with CCS+ since before it had a name. I've watched it grow through dozens of iterations, two major releases, and collaboration across 30+ people. That continuity, from blank canvas to production, shaped how I think about product design at scale.
In-person research was non-negotiable for this type of product. Watching pilots hesitate in real time gave us insights no survey would have surfaced. And building in code, implementing our own designs in Angular, meant we caught problems before engineering did, and shipped faster.
Organizational design is as hard as product design. The biggest friction was not technical. It was navigating stakeholder decisions that prioritized preference over evidence. Learning to document rationale, propose phased alternatives, and pick battles strategically was as important as the design itself.
Earlier and broader user pilots. We got great signal from power users but caught some edge cases late that trainers and infrequent users would have surfaced sooner. Broadening the testing group earlier would have saved rework in later iterations.