U.S. Air Force · Enterprise Platform · DAF Modernization
From Operational Fog to Readiness Clarity
Three disconnected systems. Four user roles. One platform that 4,000+ Airmen — and their commanders — could finally trust.
A 20-year-old training system was costing the Air Force millions annually — while leaving Airmen with no reliable source of truth for their readiness status.
Orchestrated end-to-end modernization of the ETMS platform — developed the customer experience blueprint, synthesized stakeholder needs across commands into a unified strategy, and established a governance structure built to outlast the project team.
4,000+ daily users at launch. Delivered 3 months early. Millions in legacy costs displaced. Phase 2 approved and funded.
Millions
in legacy maintenance costs displaced.
Analog "spaghetti" workflows across the DAF were costing the Department millions in annual maintenance — while leaving Airmen and Guardians without a single, reliable source of truth for their own readiness status.
Role
Strategic Designer
Timeline
18 Months
Value Created
Improved Operational Efficiency
01 — Context & Constraints
A 20-Year System That Shouldn't Have Lasted This Long
My role
Systems architect and lead UX strategist — developed the customer experience blueprint, aligned stakeholder needs across multiple commands, and established a governance structure built to outlast the project team.
The real constraints
20+ year-old software
Two decades of patches and workarounds with no underlying design system. The interaction model had never been designed — it had accreted.
Training and personnel records not connected
Separate systems, no integration. Every status update required manual reconciliation — a structural problem no UI improvement could solve.
Non-intuitive class creation process
Creating and managing courses, classes, and rosters required navigating a fragmented multi-step process split across different system modules.
High maintenance costs
Millions annually in maintenance for software that wasn't meeting user needs. The business case for replacement was already made — the brief was to make sure the replacement was actually better.
5-day User Centered Design event with Air Force stakeholders
02 — The Strategic Frame
The lift-and-shift that became an architectural redesign
The engagement started reasonable. We killed it in week three.
The original brief was a lift-and-shift — move the existing system to a modern stack without breaking anything. Not because we wanted scope creep. Because we found the Monolith.
The Air Force's personnel and training records didn't live in the same system. They lived in three separate platforms — an OutSystems layer, a legacy monolith, and an Angular front-end — with the Monolith holding the critical integration between civilian and airmen records. Every training status update required a reconciliation step that was invisible to users but present in every screen. You could redesign the UI and still ship a system where a member's training record contradicted their personnel record.
That's not a UX problem. That's an information architecture problem with UX implications — and it was the actual scope of the work once we named it.
How we reframed the engagement
Rather than designing around the broken data model, we made the architectural problem visible to the client and proposed a path that addressed it: document the Monolith as a dependency rather than a background condition, design explicitly for the three-system data states, and build reconciliation handling directly into the component architecture.
The four-role authority problem
Four user types — Member, Supervisor, UTM, and EDS — all acted on the same training record, each with different permissions, a different slice of the data, and downstream consequences for everyone else.
The interesting design problem wasn't any individual screen. It was making authority visible without making the platform feel like a bureaucracy. A Supervisor looking at “Pending Class Approval” is deciding whether to approve. An EDS looking at the same status is managing capacity. Same label, different action affordances. That constraint drove every component decision on the platform.
Supervisor view — the authority node where individual records become command-level data
A story in two roles
Closing the loop on overdue training.
An Airman has two courses past due. No alert was sent. See how the platform surfaces the gap — and closes it — across two roles.
03 — The Visual System
Atoms Built for Operational Clarity
Every component in the system was designed to reduce cognitive load for users managing compliance data under time pressure. Here are the atoms that power it.
Status Badges — Readiness States
Color never carries meaning alone — each state also has a distinct label and is reinforced by the action available in context. Color-blind users can distinguish states by label without relying on hue.
Data Table — Squadron Roster View
| Airman | Status | Overdue |
|---|---|---|
| MSgt Chen, R. | Ready | — |
| SrA Davis, T. | Pending Review | 2 |
| SSgt Park, J. | Overdue | 4 |
| A1C Torres, M. | Exempt | — |
Numbers right-aligned for scan-ability. Action labels name an outcome ("Update Readiness"), never a mechanic ("Submit" or "Edit").
Input Fields — Filter & Search Controls
Showing 4 of 4 Airmen · 1 overdue
Top-aligned labels with sufficient contrast. Every action states what it produces: "Export Squadron Report" — not "Export" or "Download."
04 — Stakeholder Management
The Hard Part
The honest account — resistance, pivots, and the path to consensus.
The initial resistance
Initial stakeholder response to early concepts was skeptical — not of the designs, but of change itself. A 20-year-old system builds deep muscle memory even when that memory is painful. Unit Training Managers knew every workaround. The new system asked them to trust that the workarounds wouldn't be needed.
How consensus was built
We pivoted to a high-touch engagement model: low-fidelity designs shared early and often, a consistent feedback loop through monthly testing sessions with up to 25 testers per session, pass/fail plus written feedback reviewed for every product decision. By month six, the stakeholders who had been most resistant were advocating internally for the new system. They weren't sold on the design — they were sold because the design reflected their input.
The feature I had to kill
I pushed for a comprehensive training calendar view that would let Airmen see all upcoming requirements in a single timeline. Users loved it in testing. The problem was the underlying data — course scheduling lived in a separate system with no reliable API, meaning the calendar would have been perpetually stale. I killed it rather than ship something misleading. We documented it for Phase 2 once the data integration was in place. Phase 2 was subsequently approved and funded.
From the field
I had Airmen with approved training that didn't show up as approved. Every week, calls. Now it just shows.
05 — The System, Not Just the Screens
At Staff/Principal level, the deliverable isn't a set of screens — it's the system that makes the screens possible and the governance model that makes them maintainable.
Component architecture
Two-archetype model (operational vs. administrative) eliminated duplicated component definitions across the platform.
Design token system
Color, spacing, and typography tokens structured around two contexts: standard workstation and low-bandwidth field. Same tokens, different resolved values.
Documentation standard
Joint design–engineering docs for every component: usage spec, anti-patterns, and technical notes — the first co-owned component documentation on the platform.
Governance model
Contribution process (proposal → review → adoption) with a named design system owner on the client team. Active six months after project closeout, no design team involvement.
06 — Business Impact
4,000+ daily active users
A unified platform serving 4,000+ Airmen and Guardians daily — users who previously navigated a fragmented 20-year-old system.
25% reduction in development cycles
Co-creation sessions aligned design intent with engineering constraints before a single sprint began, eliminating the rework cycles that had plagued earlier phases. Delivered 3 months ahead of schedule.
Millions saved annually
Displaced a legacy system costing the DAF millions per year in maintenance. Modern Angular architecture, improved load times, reusable components.
Phase 2 approved and funded
Project outcomes directly resulted in Phase 2 approval — including the features deliberately deferred from Phase 1.
Final interface designs on the MyVector platform
The four roles, in the platform
Member
Enrolls in classes, tracks status. Funded courses auto-generate a pre-populated SF-182 routed for approval without manual entry.
Supervisor
Approves class enrollment and SF-182 requests. The node where individual records become command-level readiness data.
UTM
Manages supply: class schedules, capacity, availability. Doesn't touch individual records.
EDS
Manages the catalog: course lifecycle, compliance requirements, institutional administration.
The SF-182 flow connected all four roles automatically: Member selects a funded course → system pre-populates the form → Supervisor approves → higher authorities sign off → training record updates. A workflow that was previously manual across three systems, handled end-to-end by the platform.