All sensitive information has been removed from case study. Due to security processing, all product screenshots are still under review by Kessel Run Security and will not be shown until approval. However, please feel free to ask more questions though!
Background
The Air Force plans complex time-sensitive missions, coordinating aircraft, refueling, and airspaces to generate into an Air Battle Plan (deliberate planning). These missions are planned daily in 72 hour cycles, under strict timelines and with changing operational constraints. Kessel Run’s enterprise mission planning system, KRADOS (Kessel Run All Domain Operations Suite), was intended to replace legacy systems that aided in the warfighters’ deliberate planning cycle.
I owned product design across three key applications within the suite: Slapshot (mission planning), Triton (ATO production), Jigsaw (air refueling).
I led the research, workflow mapping, and strategy. This included defining the scope and principles, creating the roadmap, and coordinating work across multiple products and teams.
Problem
Early research revealed a major capability gap:
The system could not support package planning—the orchestration of multiple aircraft and capabilities toward a single mission objective. KRADOS only supported tagging missions with the same ID in order to show association, lacking decision-making support, visibility into dependencies, deconfliction, and workflow structure
Without it, planners manually stitched together data in a fragmented workflow, limiting situational awareness and slowing down planning cycles that needed to be completed within 12 hours.
TLDR Result
We transformed a known capability gap into a scalable, user-validated workflow that enabled faster, more coordinated multi-mission planning and set direction for future modernization.
Research
context understanding
We reviewed product decision history and technical constraints to enable alignment around realistic goals
User Research
We reviewed prior research and conducted additional interviews (in person and virtually) to re-validate original assumptions that were previously defined
competitor analysis
We evaluated legacy systems to understand the core task flows users were expecting, pain points that prevented faster task completion, and other capability gaps they lacked that KRADOS could potentially solve
workflow analyis
We mapped the end to end planning workflow, identifying areas to simplify and provide clarity to provide decision making support.
Insights
Planning workflows were highly fragmented
Fragmentation introduced delays, increased cognitive load, and created risk of mismatched timing or aircraft assignments. KRADOS needed to unify critical information in one place.
Dependencies were invisible until late in the process
Late discovery of conflicts caused rework and slowed planning cycles
Legacy tools provided more structure than KRADOS
We needed to preserve familiar anchors while reducing friction, not introduce a totally new paradigm
Planning required iteration, not linear steps
KRADOS needed to support rapid iteration, not rigid, form-driven workflows
Manual rework was a significant time sink
Providing bulk actions and suggestions became key levers for reducing planning time.
Strategy & Scope
Below were the prioritized outcomes that determined our roadmap for this initiative. Work streams were prioritized based on operational criticality, technical feasibility, and time to value.
- Package Building workflow
Create a unique workflow for package building
- Package Visualization
Support for constructing and editing coordinated missions and improve decision-making facilitation, not just data entry
- Package management
- Improve situational awareness
- Bulk approval workflows
- Create parameters to bulk apply to missions
- Provide suggested mission options
- Package Deconfliction
Identify and resolve conflicts across aircraft, timing, and refueling
- Supporting Capabilities (Extra)
- Variable mission creation
- Reusable mission actions
Constraints and Roadblocks
Designing package planning required navigating significant technical, organizational, and workflow constraints. These shaped both the strategy and the sequence of what we delivered.
Legacy code and architecture limitations
Prior to the refactor, KRADOS lacked the foundational structure needed to support multi-mission workflows. Even post-refactor, engineering bandwidth and ongoing technical debt limited how much structural change we could introduce at once.
Impact:
We had to scope features into incremental slices that aligned with existing architecture rather than designing an ideal end-state all at once.
Data dependencies across products
Package workflows touched Slapshot, Jigsaw, Mai Tai, and Spacer — all of which had different data models, update cycles, and engineering owners.
Impact:
We designed shared components and workflows that could function even before full integration was complete.
Limited access to planners
Operational schedules, security clearance, and time zone differences meant we couldn’t always speak with users when needed.
Impact:
We validated assumptions using a mix of SME input, prior research, and proxy workflows, and ran lightweight validation sessions whenever planners were available.
Tradeoffs & Decisions
Familiarity vs. Innovation
Legacy systems had flawed but familiar workflows, and we needed to improve them without alienating planners.
Retain key mental models (e.g., how missions are grouped) while modernizing navigation, editing, and visibility.
Depth vs. Time-to-Value
Package planning is inherently complex. A “perfect” solution would take years.
Deliver incremental value:
- Start with structured workflows
- Then add visualization
- Then conflict detection
- Then supporting tools
Flexibility vs. Guardrails
Planners need freedom to adapt to evolving mission constraints — but too much freedom risks errors.
Design flexible workflows with built-in guidance (e.g., surfacing conflicts automatically) rather than enforcing strict rules.
Ideal UX vs. Technical Feasibility
Some desired capabilities (e.g., real-time multi-user editing across products) weren’t immediately feasible.
Design the UX patterns and interactions in a way that could scale to those features later, even if the first version was simpler.
Designs
- Used side panels and progressive disclosure for clarity
- Reinforced mental models from the legacy system while reducing complexity
- Structured workflows to reduce cognitive load and highlight conflicts automatically
- Balanced flexibility for complex scenarios with guardrails for newer planners
Results
Despite incomplete delivery, the capability generated immediate value:
- Package creation < 30 minutes, planning time across the 12-hour cycle
- Improved situational awareness
- Improved task completion comprehension
- Increase in coordination efficiency
- Reduction in handoff errors
- Positive user sentiment
- Validated approach and feasibility
Although the system was later deprioritized due to shifting organizational focus, the work demonstrated feasibility and value, establishing direction for future modernization efforts.
Reflection
What I learned through this initiative was that:
- Iterative delivery reduces risk and builds momentum
- Documentation is a strategic artifact, essential when multiple teams share a capability.
- Design leadership is often systems leadership: aligning dependencies, sequencing work, and removing ambiguity.
- Tradeoffs are inevitable — and the designer’s job is clarifying the rationale behind them for the entire team.
This project deepened my ability to work across complex ecosystems, guide multi-product alignment, and drive clarity under shifting constraints.
