The FAA created its first ever product team in 2020, where I led design and enabled 2 new designers. We built OIS's replacement, NAS Status, in just under six months.
OIS is the FAA's real-time display of events like airport closures and delays. The dashboard relies on mainframe legacy data and its code can't be updated more than twice a year.
We're seeing immediate user adoption of OIS's replacement, NAS Status, thanks to iterative user research. The new process, delivery speed, and community feedback convinced the FAA to fund a second product team and retire OIS in 2022.
National Airspace System Status ↗ (Beta)OIS is a dashboard display of all events that could cancel or delay flights. It was first created in 2000 and unnecessarily resided on system-critical infrastructure, which the FAA wanted removed immediately.
The org also believed a better user experience would engage the "flying public" OIS users. If we could create more value for frequent flyers and have them give us feedback, those changes could filter down to the private versions of OIS used by airlines and internal FAA ops.
By reaching out to active users through mailing lists and word of mouth, we determined within a week that the "flying public" doesn't use OIS. We continued to reach out for participants on social media, user recruitment platforms, and word of mouth, but never found a "frequent flyer" persona.
Insteady, fly.faa.gov users are typical of a rarely changed, little-advertised industry app. Most public version users of OIS are actually in business aviation (BA). Unlike airlines, piloting and scheduling private jets is flexible. The depth and scope of OIS is very helpful for last minute prep and changes.
During our initial discovery research, we interviewed 10 BA schedulers and pilots in two weeks.
Private flight schedulers use OIS to answer "how does this event affect me?" At the start of the day, schedulers pull up the ops plan, a list of likely future events, to get a sense of how busy they will be. Lots of weather will mean lots of rescheduling.
Schedulers were alarmed that we might change OIS. "I've been using this for 15 years. I know exactly where everything is. I can glance at this table and know what's going on," a NetJets operator explained.
But watching schedulers use OIS told a different story. It was hard to answer "how does this affect me?" when information was buried in other FAA products and users didn't know how to navigate the website. Even experienced schedulers had trouble interpreting acronyms and how long delays would last.
We then interviewed several BA pilots, who find OIS useful because it helps them give up-to-date information from the cockpit. If OIS shows flights to SFO grounded for 40 minutes due to thunderstorms, they can relay that. Multiple pilots stressed the importance of "sounding intelligent when I update my client."
However, OIS displays poorly on tablets and phones, which are the only devices in the cockpit. Pilots care a lot about navigating around airborne events, but had no idea where said events were without a graphic. One user said he didn't share OIS with other Delta Private pilots because he knew he would have to constantly translate terminology.
Our initial discovery focused on two personas. By asking users to both tell and show their process, we were able to differentiate their attitude (I am familiar with OIS, I like the OIS data) from their experience (I have trouble navigating OIS, I have trouble interpreting the data). We were able to focus on solving real user problems while keeping in mind what users liked about the existing system.
Based on interviews and personas, we hypothesized that business aviation would switch to our version of OIS if it was readable, navigable, and helped with decision making. We heard users talk about priority airports, regions, and routes rather than isolated events. We theorized that a dashboard grouped by airport, rather than type of event, would be well-received. We believed pilots would see immediate value and schedulers would find the benefits outweighed the process change.
Our first prototype also surfaced data hidden in other FAA products. We included reroutes (where can't I go), restrictions (how can't I go), and advisories (why is this event happening) within an airport. We believed this told the full story of what was going on at a given location.
Pilots and schedulers mentioned seeing events for the departing and arriving airport side-by-side is more helpful than putting that "route" together manually. So we tested a search engine that filtered events down to two airports.
Users were confused. They didn't understand how the number of reroutes and restrictions affected them. They had trouble navigating to the advisories overlay. There was too much reading and too few events on the screen. Schedulers in particular did not like the new layout and wanted the tables back.
We took this feedback, condensed, reorganized, added features, then tried again. We heard enough positive feedback around the "side-by-side" view that we still believed in our core hypothesis.
This time, pilots liked the changes. They focused on more airports per page, useful contextual links, and how the app looked in mobile view. In the words of a Google company pilot, we had created "a real dashboard I can use". There was "no hunting, everything's where I need it."
Schedulers were still skeptical. We started surfacing more data hidden in FAA apps - weather maps, advisories, real-time runway data. Several seasoned schedulers with years of FAA app use, upon seeing the weather maps, asked us "Wow, can you get this in OIS right now?" (Yes.) We continued to test with power users that truly didn't know what information was in the system or how to access it. When we confirmed that they could make more decisions with these features, we committed to building the prototype. The value of being comfortable with tables did not outweigh the increased awareness, safety, and time savings made by surfacing this data. We kept testing until schedulers found a layout and density of information they still liked.
Over the course of 8 rounds of research with 50 users, we iterated on our minimum front page for release. Through think-make-check cycles, we made high-impact, low-complexity visual changes. Scheduler feedback turned positive and initial impressions of the prototype focused on the page content rather than its layout.
Beyond the airport events, we added internal and external links in a new header so schedulers could keep NAS Status up as their main page and use fewer bookmarks. We brought the operations plan front page so that current and future events could be cross-checked.
Legacy FAA buries critical information and then obscures it behind flight control jargon. I learned how to design clear events that are still sourced from text-heavy data. "Flow control" events (FCAs) were particularly difficult. FCAs streamline airborn traffic in a given area, say, delaying and rerouting around a hurricane in SE Texas. Users see a static map, several columns of data, and are told to call for more information.
I used historical FCAs to become an expert at what acronyms meant and tried translating the events myself into a new design. I check my accuracy with FAA experts and then tested our new FCA's value with users in our weekly interviews.
In December 2020, the FAA issued FCAPV1 and FCAJX7, two "flow control" events to streamline airborne traffic in a given area. In the legacy system, 1 out of 20 users understood FCAPV1. The map is meaningless, it's unclear what's restricted, and a user has to know that PV1 means "the islands of Turks and Caicos' Providinciales airport." FCAJX7 was better understood by pilots as "slowdowns near Jacksonville, Florida." However, pilots had trouble interpreting jargon. They didn't really understand the direction and intensity of the delays, or when they were occurring.
With an interactive map and human-readable language, schedulers and pilots were able to pinpoint and plan for the delays. In our user testing, BA pilots and schedulers of all experience levels were able to explain FCAPV1 back to us.