The product
GoDirect Flight Bag Pro is a Honeywell iPad application for business aviation pilots. It streamlines flight planning, letting pilots view, update, and file flight routes, and provides real-time weather updates, NOTAMs, and Temporary Flight Restrictions for pre-flight checks and route adjustments.
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.
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.
What changed
Steven reworked several flows and screens based on the combined findings. The structured task failures from usability testing pointed to specific interaction problems. The open feedback sessions added context that helped the team understand the reasoning behind the changes, not just the symptoms.
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.