Overview
Research
Solution
faster release
cycles
automated validation
checks
Involved
Lead Dispatchers | Product Manager | Compliance Officer
Kick-off
Defining Success: Through the HEART & GSM Frameworks
Week 1
Research
Identifying the Issue in the Current Workflow
Week 2-3
The Compliance Audit: Finding the Number
I ran a Compliance Audit on past flight releases to obtain a cold, hard number for the current error rate (the baseline). A baseline 8% error rate. This proved the current system
was a genuine liability. This gave us our "North Star" metric.
Contextual Inquiry: Watching the Struggle
To understand why 8% of releases had errors, I cleared 3 days for Contextual Inquiry, where I observed 5 dispatchers and watched them work in their actual environment - phones ringing, multiple monitors glowing, dozens of browser tabs open, manually copy-paste data between five different tools.
The Journey Map: Mapping the Stress
I synthesized everything I saw into a Journey Map to visualize the dispatchers' experience from start to finish. This did two things:
1. Tracked the Clock:
It confirmed exactly why it was taking an average time of 45 minutes to get a single flight cleared.
2. Measured the Mental Load:
I used this to track "Stress Points" and estimate a SUS (System Usability Scale) score. It mapped out the "manual loops" where dispatchers felt the most anxious about making a mistake.

What the Researched Revealed
The revealed that dispatchers were operating under extreme time pressure, they were manually cross-referencing data across five disconnected systems including weather, fuel plans, and NOTAMs. The fragmentation of tools and manual data transfers was a primary driver of critical errors and cognitive fatigue.
Error Rate
Time on Task
SUS Score
Ideation
Engineering a New Workflow
Week 3-6
01
Sketching
This challenge kicked off an intensive sketching phase. I filled pages with different interface patterns, trying to find the best way to organize the chaos. These early wireframes quickly pointed us toward the "Wizard Model." Instead of one overwhelming screen, we moved to a progressive, step-by-step framework. It was a strategic way to consolidate data and ensure no mandatory safety check was ever skipped.
02
User Flow
Our research had already exposed the "manual loops" that were killing efficiency. To kill that friction, I moved into flow diagramming. I mapped out every compliance rule and potential error state to see where the system could do the heavy lifting for the human. This deep dive led to the Real-Time Traffic Light Status Panel. By building this logic into the flow, we gave dispatchers immediate, fail-safe feedback, shifting their job from "hunting for errors" to "making confident decisions."
03
Prototyping for Proof
Once the logic was solid, we were ready to build. I gathered everything—the sketches, the flows, and the data rules—and packaged them into a low-fidelity, interactive prototype. We didn't need a finished product to start testing; we needed a tool that simulated the real-world experience.
Bringing this prototype to the Compliance Officers and Flight Leads allowed them to feel the new workflow for themselves. It made the safety and speed benefits obvious immediately. By validating our "Wizard" and "Traffic Light" concepts early, we fast-tracked the design process and saved a massive amount of development cost before a single line of code was ever written.
Solution
The Flight Release Wizard
Week 6-8
Let’s Connect











