Notification Center for Crew App
ROLE & TEAM
Principal Designer on a team with
a PM and 2 iOS Devs at Schedaero
SUMMARY
We designed and implemented a way for pilots to see trip changes without constantly refreshing their app for an update, and then limited it to relevant trips.
Problem Statement
Our app had only one push notification: an alert you’d been assigned to the trip. When we asked operators what their crewing workflow looked like, we heard repeatedly that you added the pilots last, even if that meant keeping track of pilot assignments using external software. The reason? If a pilot saw an itinerary with empty logistics, unknown passengers, a missing crewmate— they’d immediately call dispatch to ask about it, annoying the very person who was in the middle of adding those logistic details.
Research + Discovery
In-app feedback indicated pilots would worry if a trip’s details weren’t complete, and one even described a scene of a pilot sitting on their hotel bed refreshing the app over and over again until the details filled in.
Pendo usage indicated high refresh rates when pilots were away on overnight trips
We asked customers to describe their current workflow and saw workarounds— they email the pilots the itinerary with the subject line indicating the latest change and what details would come. They kept track of which pilots were flying on trips in a custom excelsheet.
Ideations & Iterations
When I joined the project, the tech teams had already had a solution infrastructure in place. A change listener would observe the logistical updates of a trip and send a push notification to the pilot’s crew app for each change.
Having seen the way schedulers and dispatchers work, I predicted this would get unusably noisy, quickly. I proposed a 5 minute delay before the notification sent off. Every new change restarted the timer, so it gave the schedulers time to come in and update several fields, which would all get grouped under a single push notification.
Once the pilots got this notification, they needed a place to examine the individual updates. We found the need for a new tab, called Notification Center.
My early ideation featured different sorting methods — we tested versions sorted and grouped based on Trip Departure and by Aircraft, but ultimately found pilots were most comfortable when the notifications were grouped and sorted by how long ago they were received.
This is also where we ideated a pattern for ‘New!” which became very important later as we wanted to notify pilots what data had been changed since their last visit.
Too Much of a Good Thing
Upon launch, the feature had wide-spread adoption. But as feedback started to come in from some pilots — we saw they were complaining that there were too many notifications now. Many of them were irrelevant to the pilot. The effect was so pronounced that many of the pilots suppressed all push notifications through their iOS settings. Oops.
Interviewing customers with negative feedback, we realized how ‘relevance’ can vary depending on the operator and the scenario.
One operator might have the pilots handle catering, whereas another operator might have a special team to handle catering at homebase. One operator might handle pilot transportation and lodging, where another uses those fields to store their rewards codes. So not every logistical update is useful.
A common theme was that nearly any change on a trip set to depart within an hour was deeply relevant, but that changes on a trip 3 weeks from now meant basically nothing to the pilot besides noise… unless the change was drastic enough that they might need to change their personal plans.
Fast-Follow: Suppress Notification until Near Departure
We considered several options for how to solve the customer’s problems.
At first I proposed pilots have the ability to choose which categories they wanted to receive. Operators weren’t happy with that — they were worried they would turn them all off and miss something important.
We realized that the operators themselves would want to control what notifications the pilot received, at a company-wide level. I came up with a design that let the admins pick and choose what elements triggered a notification. But due to that shifting relevance, they had trouble picking a set that worked for every trip.
Ultimately, we decided to add a setting to suppress change notifications until the trip was within a certain time frame near to departure. We chose a reasonable default (2hrs) but gave users the ability to customize it to be within minutes or days of trip departure. We rolled the setting out site-wide.
I did decide to keep SOME notifications on regardless of time, the ones we deemed crucial because they could affect the pilot’s travel or packing plans. The design explains which ones are always sent.
Outcomes & Impact
x # of companies adopted the crew app
We saw a % increase in pilots using the app.
Negative feedback completely stopped after our time-suppression improvement.