FLIGHT TRACKING & ALERT SYSTEM

In compliance with NDAs, some confidential information has been generalized or omitted.
All info below is my own, and does not necessarily reflect the views of the company.

OVERVIEW

As the first designer hired at this engineer-driven software development company, I was brought on to work on a turn-key, permissioned, web-based alerting dashboard providing 100% global, real-time aircraft tracking (through a 66 satellite constellation system), with minute-by-minute 4D aircraft positions and customizable alerts. These are based on user-set criteria to alert when the aircraft is in distress, which is especially important over polar, desert and oceanic areas where regular coverage is sparse.

PROJECT TIMELINE

We spend one year developing the MVP (which included a 3-month beta), and second year on V2 (with another 3-month beta).

The product was tested in a production environment (for both betas) with commercial airlines. We provided them with a detailed product guide and followed up with surveys and open feedback calls.

THE PROBLEM

The Global Aeronautical Distress and Safety System (GADSS) was developed by the International Civil Aviation Organization (ICAO) and EUROCONTROL following the lost Air France and Malaysia Airlines flights in 2009 and 2014 respectively.

This product is a GADSS-compliant, global alerting and flight tracking system for airlines and aircraft operators.

PROJECT CONSTRAINTS

This was a completely new and unique software in that it was developed to alert when an aircraft is in distress. It was a legitimate hurdle convincing beta users to adjust their alerts, even as a staged distress in a production environment in order to test it.

The user base for this product was also a new persona type compared to the company’s other products. There existed no previous research on their job descriptions, work environments or day-to-day duties.

---

PROCESS

We followed the design thinking process created by the d.school and endorsed by NN/g and the IDF.

EMPATHIZE:

We had a commercial airline partner we leaned on heavily during the discovery/research period. Multiple fact-finding sessions and 1-on-1 interviews were held.

LEARNINGS ALONG THE WAY

One key finding was that depending on the size
of the airline’s dispatch department, end users
could be a single employee or a team of 2-3 people.

The users’ environment is busy, high-stress, loud and the product will be one of multiple screens being managed at one time. We needed to consider how to incorporate all this into their workflow.

As mentioned, the principle function of the software is to alert when an aircraft is in distress. This type of software was unique in that when triggered, it signified an immediate, reactive scenario.

DEFINE:

As a team we conducted a Product Vision Statement Workshop and gathered requirements (user, design, technical) and iterated through the design phase. The product suite would consist of:

• Up-to-the-minute flight tracking dashboard that includes a configurable alert notification system
• An internal admin tool for customer service reps to manage an airline’s account and add their aircraft
• Web portal to drum up hype around the project, showing the progression of the satellite launches and visualization of how satellites would track aircraft

IDEATE:

We created user flow diagrams and task analysis documents and workshopped amongst the internal dev team. Then interactive sessions were facilitated to find edge cases and the team iterated through sketches and on whiteboards to tweak things as we went. Wireframes were created in Adobe Illustrator and prototypes were built in InVision.

PROTOTYPE/TEST:

We used paper prototypes of the wireframes internally, then tested with our user partners with interactive, animated prototypes built in InVision. Prototyping was conducted on iPads, laptops and desktops. iPad prototypes verified designs would work on a device, but also cemented that this software was meant to be used on larger screens and devices.

LEARNINGS ALONG THE WAY

Prototyped with our partners and internal team
on iPads, laptops and desktops. iPad prototypes verified
designs would work on a device, but also cemented
that this software was meant to be used
on larger screens and devices.

IMPLEMENT:

The MVP was completed and used for the first beta. Based on feedback from that beta, design changes were implemented before the second beta. In terms of the visual design, the second version was very close to the initial iteration.

More than 10 airlines participated in the 1st beta. We created an in-depth product training guide that was delivered with the airline’s test account. Test accounts consisted of the list of aircraft received from them. At the end of the beta, a required survey was sent out, and an option for an open feedback call.

For the 2nd beta more than 40 airlines participated. The survey was longer and more comprehensive, based on what we learned in the first round. We also provided live administrative and customer support through the company’s Customer Service Team.

---

OUTCOMES

Due to the varied nature of the airlines, their size and their personnel, we realized that the Customer Service Team would need an administrative tool to manage accounts. Once we created it, we trained them on it.

Another necessary component was a demo of the product that the Sales & Marketing Team could use with prospective buyers. This had all the functionality of the original product, only with a fictional airline and fleet and featured more of the company’s branding.

In general, users asked for more comprehensive flight tracking within the product. While this was not part of the project’s scope, we decided to pair it with another existing software as a new product offering for the company.

To see more info about this product click here.