Federal Aviation Administration

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.

National Airspace System Status (NAS Status)

Schedulers gathered around a desk with several monitors. The middle one shows OIS.

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)

Context: Old Systems, Event Streams & Publicity

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.

Screenshot of OIS from 2001, identical to today's layout minus the date.
OIS August 2001. It looks almost exactly the same, down to the table headers and color.

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.

User Research & Prioritization

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.

A user interview screenshot. They have pulled up the ops plan, a status update and forecasting report. Out of their 20 bookmarks, 4 are to separate fly.faa pages.
Watching a user decipher the ops plan. Four separate FAA products are highlighted on their bookmarks bar because in-app navigation is so obscure.

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.

The double diamond diagram on a whiteboard. Each round of interviews has corresponding insights and action items.
Plotting our discovery insights on a double diamond.

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.

Prototyping Progress

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.

The prototype shows all available airspace information in a readable layout, but there's too much information at too granular a level to process.
Top left: The home page. Top right: An event's details. Bottom left: The event's advisory displayed as an overlay. Bottom right: Two airports' events shown after a search.

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.

The prototype now displays seven events instead of three.
The home page with more events, but less top-level information. TEB aiport's details is displayed in sentences with clear links.

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.

Hand-drawn UI sketches on the left and the Figma version on the right. Turnaround from tepid to positive user feedback was 16 hours.
Pre-covid, we tested a simplified airport details view at the annual Scheduler & Dispatcher conference. We got feedback the first day and heard there was too much info in the detail view. We sketched on paper that night (left), and re-tested the prototype the next day (right) to positive feedback.

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.

Sticky notes from user interviews.
A research synthesis in Miro (iteration 4). Users said "looking really good" and "easier to read, for sure" when they saw the home page for the first time.

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.

The first release of NAS contains three main sections: airport events, airspace events, and upcoming events.
The first release of the front page featured a minimum amount of info per airport card, maps for weather, and upcoming events.

Designing Around the Data

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.

JX7 and PV1 images are on a separate page accessed through a tiny link.PV1 is literally just a picture of an unlabeled blue sea and a superimposed triangle.
Legacy OIS first requires a user to know what an FCA is and click the FCA link in the table. They then decipher table data and a contextless picture of the ocean.
The home page with two FCA events. Each FCA has an interactive map depicting the event's location.A closeup of the FCAPV1 zoomed in with embedded map controls, displaying a triangle over the Turks & Caicos airport.
An interactive map and human-readable language are key to understanding whether a flight is affected, and if so, what they can do about it.

A busy day with 10+ events depicted in NAS.