The product
GoDirect Flight Bag Pro was a Honeywell iPad application for business aviation pilots. It streamlined flight planning, letting pilots view, update, and file flight routes, and provided real-time weather updates, time-sensitive safety notifications and Temporary Flight Restrictions for pre-flight checks and route adjustments. Honeywell discontinued the Forge Services platform that included Flight Bag Pro in 2025.
We had an early build in development and an opportunity to get it in front of real pilots before it shipped. I organized an on-site research session at a corporate aviation FBO connected to Vancouver International Airport — a working environment where pilots came and went between their actual flight duties.
The research design
Eleven pilots participated across the day, coming in on scheduled slots between their flights and other duties. I deliberately split them into two groups, making sure each had a cross-section of newer and more seasoned pilots based on years of flying, years in corporate aviation, and aircraft type.
Group 1 — Usability testing: I led structured usability testing, observing pilots as they attempted specific tasks with the app and gathering feedback on workflow, design, and potential new features. This group only received access to the early build after completing their session, so their reactions were uninfluenced by prior use.
Group 2 — General feedback: Steven led open-ended conversations with pilots who had already been using the early build, exploring overall impressions of usability and functionality. Running both methods in parallel let us triangulate — the structured task failures from Group 1 gave us precision, while the open feedback from Group 2 gave us broader context.
I invited the product owner to join us for the sessions. She was a trained pilot and former dispatcher, which meant she understood the domain at a level most product owners don't. Her presence during testing was valuable — watching pilots struggle with specific tasks in real time is a different experience than reading a findings report, and it shaped how she prioritized what came next.
What we found
The usability testing surfaced workflow issues, design problems, and several critical bugs that hadn't been caught in prior testing rounds. The video below shows one moment that was hard to ignore: a pilot attempting a straightforward task in the app and not being able to complete it.
Beyond the bugs, we heard consistent feedback about specific flows that weren't matching how pilots actually thought about their work. Steven's general feedback sessions added texture — where the usability tests showed us where pilots got stuck, the open conversations told us why.
Cruise mode surfaced a different kind of problem. Selecting it required a swipe gesture, and pilots didn't discover it on their own — the video below shows the pattern we saw repeatedly.
The fix wasn't to explain the gesture better. It was to stop relying on it. We introduced a small visual peek — a sliver of the next panel visible at the edge of the screen — so pilots could see there was more content without needing to already know a swipe would reveal it.
Prioritization
After the sessions, the product owner, Steven, and I debriefed on findings from both groups. I brought a prioritization framework to the conversation: issues were rated by how frequently they were encountered across participants and how significantly they would impact the usability of the product if left unresolved. High frequency plus high impact went to the top of the list. That framework gave the product owner a defensible basis for deciding what the team would address first, and Steven reworked the flows and screens behind each fix as we worked through the list.
We started with bugs — those were features that should have simply worked, so they came before any usability fix. From there, a few items were quick wins: the icon that opened the trip kit wasn't labeled, and several pilots didn't recognize it until they were prompted to click on it, so we labeled it with the words trip kit. We also moved the weather overlay control to the lower right of the screen, which is where pilots expected to find it.
A separate, bigger trip kit problem was next, and it was the highest remaining priority because it was the one thing every pilot struggled with. Pilots would add documents to their trip kit, move on to something else, and come back to find their additions hadn't actually saved — several told us the old app had been easier because it asked them directly what they wanted included when they generated it. The fix was a confirmation step before generation, showing pilots exactly what was in their trip kit and letting them add anything else from that same screen.
Not everything made the cut. One pilot used a third-party app to annotate flight plans with typed text and asked for the same in the trip kit. It was a real idea, but it had come from a single pilot, and I wanted to see more interest in it before committing the team's time. The framework's value wasn't just deciding what to fix — it was giving the team a defensible reason to say not yet to something real.
Cruise mode's swipe problem came after all of that. Once the trip kit and the quick wins were shipped, we came back to the discoverability issue and replaced the swipe-only interaction with the peek treatment.
What I learned
Getting a product owner into a research session is worth the effort every time. Reading a findings report is one thing — watching a pilot you've just met fail to complete a task you thought was straightforward is another. The product owner's aviation background meant she could connect what she was observing directly to how that failure would play out in a real cockpit context. That made the prioritization conversation after the sessions much faster and more grounded.
Running two different research methods in parallel with the same user group is something I'd do again. The usability testing gave us precision — specific tasks, specific failure points. The open feedback gave us the broader picture of how pilots felt about the product overall. Neither method alone would have given us the complete picture we came home with.
Structuring access deliberately — keeping the usability test group away from the early build until after their session — was a small decision that mattered. Pilots who'd already been using the app came in with formed opinions. The usability test group reacted to the app fresh. Both perspectives were valuable, but for different reasons, and mixing them would have muddied both.