As the lead designer on our team, I was responsible for the entire design process, from research to solution generation and evaluation as we built a new feature for Jigsaw, the Air Force’s Tanker Planning Tool. Through this project, I experienced significant growth, as I was exposed to new challenges and learned valuable lessons. For instance, I learned the importance of involving engineers early in the process and accounting for unforeseen complexity.
Jigsaw is the tool that changed the way the Air Force develops software and later resulted in the creation of Kessel Run. Jigsaw started with the goal of solving the specific problem of tanker planning and was wildly successful. After growing quickly as an organization, Kessel Run turned its sights on deprecating the old legacy system that was being used in Air Operation Centers. This would require Jigsaw, which was not originally built to integrate, to fit into a larger suite of applications and adapt to the new process of the users.
Note: All sensitive information has been removed from this case study and it has been approved for publication by the Kessel Run Security team.
As a team, we decided to start by targeting the airspace domain. In the current interface, users were required to enter five data fields for each airspace created and manually calculate all route times. I determined that we could automate three of the five data fields with an integration with Spacer, Kessel Runs Airspace Management. Think of airspaces as big racetracks in the sky that aircraft use to refuel during missions. In addition to the needed integration, Jigsaw would also need toconsume additional data that would enable an automatic calculation of the route times.
We began migrating our data sources from our internal backend to consuming directly from the external airspace tool, Spacer. We took this opportunity to address significant user pain surrounding the process of managing and interacting with airspaces.
Before ideation, I conducted user interviews with 5 tanker planners and created this user journey map to illustrate the process the users follow to create an airspace and plan tanker missions using it. From this, I identified two major pains to solve: Jigsaw relied on manual "route" calculation and heavy data entry from the user to properly calculate mission data.
Now understanding the users problem space, I began designing and testing potential concepts. After a few rounds of iteration, I felt I had a good solution that addressed the users’ pain, providing more automation, a more visual map interface and achieved the business goal of integrating with the Spacer application. I was stoked and users loved it!
Although the solution had great support from the users, we quickly ran into feasibility issues with integrating a map into a classified environment. Working with my engineers and product manager, we adjusted the scope of the feature to delay the map integrations but still allow users to benefit from a more modern UI, reduced data entry and automated calculations.
The integration with Spacer was completed in four months. The solution met or exceeded all but one of our success metrics. Unfortunately, the automation of transit data entry was deprioritized due to technical and timeline constraints. Our team moved on to the next domain area to integrate within the suite, taking lessons learned from this first iteration with us.
My biggest takeaway from this experience was to seek out engineering feedback early and often.. If I had brought my engineers into my design process earlier, they would have been able to give me the feedback that would have saved time, allowed for better user expectation management, and kept me focused on the problems at hand. It is good to have a long term vision for what the ideal state would be, but feasibility is an important factor to consider so that we can provide user value as soon as possible. This is something that I have continued to reflect back on during my career and has allowed me to create more effective and feasible designs.
