IBCS - Northrop Grumman
Modernizing a Legacy Command & Control Interface
The interfaces I designed for IBCS are classified and cannot be shown. What I can share is the problem space, my process, and what drove my decisions. I'm happy to go deeper on any of it.
The Short Version
A legacy C2 interface that hadn't kept pace with how operators actually worked. A system redesigned around operator behavior rather than system output. A fielded product still in use by the U.S. Army.
Soldiers of the 3-6 Air and Missile Defense Test Detachment operate IBCS workstations inside an Integrated Collaborative Environment (ICE) during a live intercept test at White Sands Missile Range, N.M., December 2019. Photo: U.S. Army (publicly released).
The Problem
IBCS is the U.S. Army's primary air and missile defense command-and-control platform — the system operators use to detect threats, coordinate assets, and make intercept decisions in real time. The operator-facing interface had been built on legacy standards that no longer reflected how users actually worked or what current usability guidelines required.
Operators — soldiers working under significant cognitive load in time-critical environments — were using a system that hadn't kept pace with modern interface conventions. The goal was to bring the interface up to current standards while meaningfully reducing the mental effort required to complete core tasks. In an environment where slow or incorrect decisions have real consequences, that's not a polish problem. It's a safety problem.
My Role & Process
I was on a team within the IBCS program — serving as the sole designer and providing design support to a second. IBCS is structured across parallel teams, each responsible for different operator-facing capabilities within the broader system. I owned the full UX process on my primary team: research, IA, task flows, UI, and delivery into engineering.
I started with research — understanding how operators actually used the existing system, where friction existed, and what the legacy interface got right that we needed to preserve. Conducting research in a classified environment meant adapting standard methods: limited user access, controlled observation settings, and documentation requirements that differed from typical research ops. I worked within those constraints without letting them become excuses.
From there I worked iteratively with engineering, translating findings into interface updates that aligned with current design standards while staying within the technical constraints of the system. A significant part of the work was advocating for the user inside a team where design was not always the primary lens — making the case for UX decisions in terms that engineers and systems engineers responded to: operator performance, error reduction, and task completion time.
What I Learned
Working in a classified, requirements-driven environment sharpened a specific skill: communicating design in terms of risk, not aesthetics. When your audience is systems engineers and program managers, "this is clearer" doesn't land — "this reduces operator error in a degraded-comms scenario" does. That translation skill has changed how I advocate for design decisions in any environment.