Kessel Run · Route Calculator
A route and fuel calculator that other Air Force apps plug into, and the interface I designed to test it.
Kessel Run is a 1,000-person software company inside the U.S. Air Force. My team designed and built a route calculator as a microservice: an API that works out an aircraft's route duration, distance and fuel burn, built for other apps in Kessel Run's KRADOS suite to use. One of those apps is Jigsaw, the tanker mission planning tool, which uses it to show missions on a timeline.
I led product design for two audiences at once: the Kessel Run teams who would build on our API, and the airmen who use their apps. Because an API has no screen of its own, I designed a Route Planning Interface to test it, prove it was reliable and show other teams what it could do. Using that interface is how we discovered what the API should do next.
A question planners couldn't answer with confidence
Airmen plan missions (an aircraft plus a task, like refueling, makes a mission). Before they can commit to one, they need to answer:
Can this aircraft complete this mission without running out of fuel?
They didn't have the confidence to answer it, for three reasons:
- Unfamiliar aircraft. Calculating fuel burn felt impossible for aircraft a planner didn't know well.
- Inconsistent data. Aircraft data differed between Air Force units.
- Low trust. Planners hesitated to rely on the fuel calculations they had.
Our plan was to build one API that any KRADOS app could call to calculate route duration, distance and fuel burn, then test and showcase it through a Route Planning Interface.
The calculations planners needed
Talking with airmen and subject matter experts, we quickly learned that planners needed three calculations to plan a mission. Producing them meant pulling together two libraries of data.
Observing planners showed us how they were filling the gap in the meantime: copying mission data by hand and measuring routes in tools that didn't keep their work.
Double-enters mission data from paper into JigsawResearch note
Uses a measurement tool to get an approximate distance and to draw a route (this isn't saved anywhere)Research note
Airspace data already existed in another KRADOS app. Setting up the connection between our teams took several cycles of cross-team collaboration.
Aircraft data was harder. It covers things like weight, fuel capacity, fuel burn and minimum fuel to return, for hundreds of aircraft types and variations. It isn't public, and it wasn't even centralized within the Air Force. We built relationships with aircraft database managers across teams and began piecing together what became the single source of truth for detailed aircraft data in the Air Force.
- Aircraft type
- ████████
- Weight
- ██████ lbs
- Fuel capacity
- ██████ lbs
- Fuel burn
- █████ lbs/hr
- Minimum fuel to return
- █████ lbs
With the data models and real data in place, we had what we needed to power the first endpoints of the API.
Designing the Route Planning Interface
01A test tool that other teams could use
While the developers built the API, I designed a front end for it. It had two jobs: let our team test the API, and close a capability gap across KRADOS, which had no way to visualize routes. The Plan tab takes the same inputs the API does (aircraft, takeoff location, the airspaces to visit and landing location), so every field maps to something the calculator needs. The map drew the result as a static route. That was enough to test with, and it later became the starting point for the dynamic maps I led on Jigsaw.
02Letting testing shape the API
Once we had a real interface to test with, we realized the calculator could do more than we'd planned. If we already calculate fuel burn across a mission, we can also analyze it: show where and when the aircraft will run out of fuel, and how much fuel to request at a refueling airspace. Both became new endpoints in the API, and new components I designed for the interface.
- POST
/demo/route-totalsTime, distance and fuel burn from aircraft and route inputs - POST
/demo/fuel-outWhen and where fuel will run out on that route - POST
/demo/refuel-amountHow much fuel to request at a refueling airspace
03Showing fuel problems and how to fix them
The Route tab lists the mission in time order, with transit time between stops and fuel remaining at each one. When the API finds that fuel will run out, the leg is flagged as insufficient and the landing fuel turns negative, right where the planner is looking. From there, the planner adds a refueling stop by choosing an air refueling track and the fuel to request. The route redraws through the new track and every number below it updates.
The source of truth for route planning across KRADOS
Our key findings came from using and updating the Route Planning Interface while we tested the API. Together with user research, that loop is how we found the more advanced calculations and how to show them to airmen. The API went on to become the source-of-truth route API for every KRADOS app that needs route planning information.
The API now powers route calculations across thousands of missions, which have saved millions of dollars in aircraft fuel. It also set up my next project: I moved to the Jigsaw team to lead Kessel Run's overhaul of its map interfaces, turning this static route map into a dynamic part of mission planning. Read the Jigsaw case study →