iOS App · Flight Schedule Pro · 2018–2021
Pilots were struggling to understand whether they were legally allowed to fly, especially across time zones, leading to anxiety, heavy FAA fines, groundings, and high support volume. I was hired as the first and only Product Designer at Coradine, later Flight Schedule Pro, to build a design function from scratch and tackle this problem head on.
Aviation is one of the most heavily regulated industries in the world. Each pilot must self-manage and update their legal status for duty limits, certifications, and recent flight hours per aircraft type. Failure to do so can result in FAA penalties including heavy fines, certificate suspension, or full certificate revocation.
LogTen, our flagship logbook product, captured pilot hours and duty time but had no way to cross-reference that data with FAA regulations to alert pilots of impending infringement. Pilots were estimating their own legal status, guessing across time zones, and calling support when things went wrong.
"Only a few major airline companies alerted pilots of their currency. The rest were left to self-manage, which created anxiety, errors, and a lot of support overhead. That gap was the opportunity."
The design team did not previously exist when I joined. One of my initial priorities was to establish a research practice from scratch. I began by interviewing pilots and FAA knowledge experts to identify top-priority customer requirements and establish brand advocates who could support growth.
I followed the initial interviews with a one-day discovery workshop attended by members of our FAA advisory board, developers, a customer service lead, and active pilots. The competitive analysis confirmed a clear market gap in logbook software support for legal status visibility. This gave me enough signal to form three assumptions worth testing.
By providing real-time status visibility, pilots could reduce estimation errors. If this assumption was wrong and pilots actually trusted manual calculation, the solution would have been ignored. That was the risk I was testing against.
Allowing pilots to self-serve their future legal status would help them avoid flying illegally and plan ahead with confidence, reducing reliance on manual calculation or airline dispatch.
By supporting pilots to self-manage their regulatory risk, we could alleviate airline companies from expensive and time-consuming rescheduling caused by unexpectedly grounded pilots.
Pilots receive a Flight Bag containing all necessary forms, checklists, and an iPad for each flight. They cannot substitute the iPad, but they carry personal phones and often wear smartwatches on duty. Those personal devices were the right surface for a quick, ambient status check.
I designed a scalable status system starting with simple iOS widgets showing whether a pilot was safe, at risk, or not legally eligible to fly. The key design trade-off was detail versus speed. Rather than exposing complex FAA rules upfront, I focused on simple status states with detail available on demand through progressive disclosure.
When a pilot selects a widget, the LogTen app comes to the foreground and displays more detail through progressive disclosure. A pilot can then move a timeline to see what their legal duty eligibility looks like at any point in the future, allowing proactive planning rather than reactive scrambling.
RolloutI launched the feature to an initial 10% of the user base. After 4 weeks I expanded to 25%, then 50%, monitoring carefully at each stage. Post-launch user interviews confirmed reduced reliance on manual calculations, fewer grounded pilots, and lower support query volume among users on the challenger build.
Quarterly business review data reported increased daily app engagement, higher customer acquisition, fewer repeat support queries, lower overall support volume, and faster response times. The feature was pushed to the full remaining user base.
Unexpected outcomeAs Covid grounded most pilots, the company faced a real threat: users cancelling or not renewing subscriptions in the coming months. I ran an online workshop with pilots, the advisory board, and the customer service team and discovered that a large number of pilots were pivoting to temporary careers as charter and cargo pilots.
"I was genuinely surprised at how the flight status feature extended into other platforms and use cases once I started looking for where the need existed. The original design had more reach than I had anticipated."
I focused on charter operators since they were the most likely to purchase the product. I led the design and research to build a SaaS application that allowed operators to manage their pilots and fleet using the same legal status logic I had designed for LogTen. I investigated the feasibility of using API calls to populate pilot flight data, medical certificates, and endorsements.
| Pilot | Aircraft type | Day currency | Night currency | Instrument | Medical class |
|---|---|---|---|---|---|
| A. Calzoni | BE20 Bonanza | 0 days | 14.1 days | 18 days | Current |
| M. Shrivastav | Piper PA-46 | 0 days | 14.1 days | 15 days | Current |
| R. Baptista | BE20 Bonanza | 15 days | 19 days | 26 days | Current |
| E. Cordelia | BE20 Bonanza | 32 days | 14.1 days | 14.1 days | Expires soon |
The SaaS product was widely embraced not just by charter operators but also by land and sea operators, which allowed the company to stay profitable throughout the pandemic while supporting pilots pivoting along alternative career paths.
ResultPost-launch interviews confirmed a decrease in grounded pilots among users on the challenger build, validating the core assumption that real-time status visibility reduced estimation errors.
Quarterly business review data showed fewer repeat support queries, lower overall support volume, and faster response times following the full rollout.
The pivot to charter operator fleet management kept the company profitable throughout the pandemic, extending the core status logic into an entirely new product line.
The SaaS product was adopted by land and sea operators beyond the original aviation market, demonstrating that the underlying compliance visibility model had wider applicability.
The flight status feature extended into platforms and use cases I had not anticipated, which was genuinely surprising. One thing I would change is having been more assertive about prioritising the interactive status timeline feature after launch. I made backlog items for future improvements but was not assertive enough at the time to ensure those items were groomed and added to sprint planning. The feature had more potential than it reached in the time I was pushing for it.
I am happy to walk through the discovery workshop methodology, the FAA regulatory research process, the staged rollout approach, or how I built a design function from scratch at an early stage company.
Send me an invite to chat