U.S. Air Force · Enterprise Platform · DAF Modernization
Modernizing Mission-Critical Training at Scale
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 — new interaction model, standardized design system, legacy data model reconciliation, and 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
Lead Designer
Timeline
18 Months
Daily Active Users
4,000+
I orchestrated the full modernization of the legacy ETMS on the MyVector platform — standardizing the interaction model and component architecture, reconciling fragmented training and personnel records across three disconnected legacy systems, and implementing a governance structure built to outlast the project team. Delivered 3 months ahead of schedule. Now serving 4,000+ daily active users, with Phase 2 approved and funded.
01 — Context & Constraints
The organization
A mission-critical training and readiness management platform for a major branch of the U.S. Armed Forces, operating at scale across multiple installations. Users ranged from front-line personnel completing required training to program administrators managing compliance across thousands of records.
My role
Systems architect and lead designer responsible for orchestrating the end-to-end interaction model and standardizing the component architecture across the platform. I owned stakeholder relationships across multiple commands, facilitated a cross-functional design and research team, and served as the primary bridge between design intent and engineering constraints — including legacy data model decisions that no UI layer could paper over.
The real constraints
20+ year-old software
The existing system predated modern UX practice entirely. The interaction model had accreted over two decades of patches and workarounds with no underlying design system.
Training and personnel records not connected
Airmen's training records and personnel records lived in separate systems with no integration. Every status update required manual reconciliation — a structural problem that no amount of UI improvement could solve.
Non-intuitive class creation process
The core task for Unit Training Managers — creating and managing courses, classes, and rosters — required navigating a fragmented multi-step process built across different system modules.
High maintenance costs
The legacy system was costing the Department of the Air Force millions annually in maintenance for software that wasn't meeting user needs. The business case for replacement was already made — the design 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 actual problem under the stated problem
The client brief described a UI modernization. The real problem was organizational: no shared definition of what "training readiness" meant across commands — which meant every downstream system was tracking different things under the same label. You cannot design a good interface on top of a broken data model. The design work had to be preceded by a definitional alignment exercise across stakeholders. That's not a UX project. That's an information architecture project with UX implications.
How the d.MBA framing shaped the engagement
Coming in with a business lens meant asking questions not in the original brief: What is the operational cost of the current friction? What decisions does the readiness data actually inform? What would it take for this system to scale to additional installations? Those questions shaped product strategy, not just design direction.
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
Junior designers document the ideal flow. This is the section that makes everything else credible — the honest account of 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
This report used to take a full day; now it takes 15 minutes.
05 — Technical Constraints as Design Inputs
The technical environment wasn't a background condition — it was an active design input. Understanding the constraints precisely is what allowed us to design solutions that could actually be built.
Designing for the data model, not the ideal model
The three-system fragmentation meant our information architecture had to accommodate data states that wouldn't exist in a greenfield design — specifically, a "reconciling" state where data across systems disagreed. Every component needed to handle that state gracefully. Designing for it honestly, rather than assuming clean data, was a non-trivial creative and engineering challenge.
Engineering collaboration mechanism
Weekly design–tech syncs with a shared "constraint ledger" — a living document where design decisions and their technical dependencies were tracked together. When a constraint changed, the design team was notified before it affected a sprint. This prevented the two-week rework cycles that had plagued earlier project phases.
Security-first interaction design
Every feature touching classified record types required a security review before user testing. I built this cycle in as a fixed checkpoint rather than treating it as a blocker — which meant we never had a feature that passed design review and failed security review.
06 — 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
Standardized the platform's foundational component library — forms, data tables, status indicators — by implementing a two-archetype model (operational vs. administrative users) that eliminated duplicated component definitions across the system.
Design token system
Implemented a color, spacing, and typography token system structured around two display contexts: standard workstation and low-bandwidth field environments. Same tokens, different resolved values per context.
Documentation standard
Established joint design–engineering documentation for each component: a usage spec, an anti-patterns doc, and a technical notes field co-maintained by design and engineering — the first co-owned component documentation on the platform.
Governance model
Implemented a contribution process (proposal → review → adoption) with a named design system owner on the client team. The system was in active use six months after project closeout with no design team involvement.
07 — Business Impact
4,000+ daily active users
Launched a unified platform now serving 4,000+ Airmen and Guardians daily across the Air Force — users who previously navigated a fragmented 20-year-old system.
3 months ahead of schedule
The agile design-to-development workflow we established delivered the full project scope three months ahead of schedule — a direct result of the constraint-first process and early stakeholder alignment.
Millions saved annually
Displaced a legacy system that was costing the Department of the Air Force millions per year in maintenance. The new platform runs on a modern Angular-based architecture with improved load times and component reusability.
Phase 2 approved and funded
The project's outcomes directly resulted in the approval and funding of Phase 2, expanding the system's functionality and feature set — including the features deferred from Phase 1.
Final interface designs on the MyVector platform
Second-Order Outcomes
The data model reconciliation pattern created during this project was subsequently referenced in a separate platform modernization initiative within the same organization — an unplanned reuse that validated the architectural decision. The design system documentation standard became the template for how the client team structured component libraries in subsequent projects, an outcome well outside the original scope.
08 — What I'd Do Differently
If I had it to do again, I would have run a structured technical constraint workshop with engineering in week one — before any concepting. We lost roughly two weeks to designs that couldn't be built given the legacy data model, and a half-day session at the start would have surfaced those constraints earlier.
I'd also have brought the security review team in during the concepting phase rather than the review phase. Their perspective shaped several final decisions regardless — the only thing that changed by involving them late was the timeline.