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.

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.

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

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.

My Role

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.

My Role

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.

My Process

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.

My Process

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.

My Process

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.