Mission support application

Overview

As a UX Designer and Product Owner, I led design for a mission-critical application on a 25-person interdisciplinary team to deliver a high-stakes application for the United States European Command.

My role extended beyond interface design. I used my subject matter expertise and direct access to users to translate operational needs into product decisions, guide development, and keep the team aligned on how the application should work in practice.

I traveled internationally to observe users in their working environment, led stakeholder and usability sessions, reviewed development builds against design intent, and worked directly with engineers to resolve implementation issues.

I can’t share details of this project, but I can walk through the parts of my role that best represent how I work.

Confidentiality note

Due to the nature of this work, I can’t share the application’s underlying mission details or interface. The examples below focus on my design decisions, workflows, and approach.

Research, validation, and enablement

Because the application supported different user groups and complex workflows, I treated research as ongoing input rather than a one-time discovery phase. I worked directly with users and stakeholders to understand how the application needed to support the mission, including small-group sessions with senior leaders and hands-on familiarization sessions with operational users. I also ran one-on-one usability tests with new users to identify where the interface required prior knowledge or specialist support.

The findings fed directly into design iterations, while the same real-world tasks became the basis for user guides, training sessions, and instructional videos.

Design process

The team works in a rapid-prototyping environment, so I moved quickly from problem definition to design and iterated continuously with users, stakeholders, and developers.

I created hundreds of screens to map the full interaction modal for a myriad of complex workflows. My specifications accounted for interactive states, required fields, system status, navigation, and edge cases so developers were not left to fill in the gaps.

I also established a design system, which included a style guide with a color palette and typography rules, as well as reusable components for buttons, toggles, form fields, modals, and in-app navigation, so the interface stayed consistent as the product expanded.

Designing across three operational contexts

Planning

The problem: Planning required users to manually build tables one row at a time and repeatedly open modals to edit and save information. The workflow also required users to navigate a large number of fields and constraints, making it difficult to complete efficiently. Through observation, I identified an opportunity to make data entry more intuitive.

The design decision: I reduced unnecessary data entry by introducing auto-population, using information the system already knew about the mission set. I mirrored the interface after source material users were already familiar with. I also separated planning into distinct pages with clear status indicators so users could understand what was complete and what still required attention.

The result: The goal wasn’t simply to reduce clicks, but to make the workflow faster while reducing opportunities for incomplete or incorrect information.

Operations

The problem: Users needed to understand what had already happened, what was happening now, and what was coming next. The existing visualization made operational progress difficult to interpret at a glance.

The design decision: I replaced the donut chart visualization with a linear progression model using steps and icons that mapped more directly to the sequence of real-world actions.

The result: The redesign represented the operation as a sequence of events unfolding over time, making mission status easier to understand at a glance.

Crisis Management

The problem: During a crisis, senior leaders needed to quickly scan and understand the operational picture, but different users valued different information from the same system, so information priority was a challenge.

The design decision: I designed a strategic dashboard around information priority: what leaders needed to understand immediately, what provided useful context, and what could remain available elsewhere in the application.

The result: The challenge was deciding what information earned attention first, and what information would only slow users down.

Leadership and decisions

The tool’s planning, operations, and crisis management workflows each came with its own set of users, constraints, and success metrics. I made design decisions by balancing user needs, operational impact, implementation considerations, and product priorities.

Newcomers, experienced users, and senior decision-makers all depended on the same system in different ways. A change that improved one workflow could create friction somewhere else, so I learned to evaluate each design decision in the context of the broader product and mission. Rather than bringing forward solutions in isolation, I learned to surface the tradeoffs behind them and make those tradeoffs part of the design conversation.