< Back

NASA

Overview

As a designer at NASA in the HCI department, I had to work with pilots to test conceptual aircraft displays, specifically the PFD (primary flight display) to conduct research on aircraft capabilities.

The Problem

Aircraft are getting more advanced than ever, and we have to be able to help pilots understand what airplanes are capable of. With better technology, some aircraft can still safely be flown. But in some instances, we also have to alert pilots when there are risks associated with taking a flight path.

Case Study - Qantas Flight 32

The study we will be referencing is the Qantas flight 32, where a plane had taken off from Changi Airport in Singapore headed to Sydney, Australia. Four minutes after takeoff at 7000 ft, the flight crew heard two loud bangs. This was the result of engine number 2 failing and caused significant damage in airplane systems and fuel leakage.

The pilots had held a holding pattern for 50 minutes, trying to investigate the issue. Engine 1 was still running, and was able to get the plane back to safety at the airport they took off from.

Diagnosing engine failures can be complex, and airplane systems do not outright tell pilots that there is an engine failure. Pilots have to use a checklist to determine the issues presented on the EICAS (Engine Indicating And Crew Alerting System).

The holding pattern above shows the aircraft headed towards Sydney, Australia, but had to route back to the origin airport. The pilots held a holding pattern for 50 minutes to diagnose the issue.

Time could have been saved

There could have been a better way to display information. The only information that pilots can reference is within the EICAS system shown to the right. This displays all malfunctions, but pilots have to diagnose the problem.

Aircraft capabilities unknown

There are limits in which aircraft can do when there's a failure. Without having the understanding of aircraft capabilities, pilots are left in the dark on what they can do to maneuver the plane to saftey.

Diagnostics are tedius

Pilot handbooks are what pilots use to diagnose issues. They use a checklist to identify the problems and then come to a conclusion without the system outright telling them what is wrong.

What The Qantas Flight 32 Pilots Saw

On the right, we are presenting what the pilots of Qantas Flight 32 saw on their display when the engine disintegrated midair. It's almost as vague as a "check engine light" on a car when driving. Pilots have to find out what's wrong with the aircraft.

Qantas Flight 32 had more than 80 messages at once

45% of users hire manually

Based on a survey, we found that small business owners still manually use physical paper to hire employees. This involves having employees come to sign documents in person.

Errors delay hiring process by hours

Many new hires may be applying for their first job, and don't know how to fill out forms. When this happens, hiring managers need to resend the hiring forms.

Data Pulled Into Disclosure

Data from the documents are pulled into the disclosure for you using tagging technology.

Quick Reference Handbook

This is an example of how to fix just one malfunction on the aircraft. The pilot would have to go through all 34 messages to diagnose the issue.

The Opportunity

How can we reduce time and pilot error during malfunctions?

Create an automated system

Instead of having the pilots go through the whole checklist, we can have the pilots diagnose the malfunctions through the UI.

Simplify error handling

Messages dont outright tell the pilots what's wrong. They have to determine from the messages on what the errors are.

< Back to Home

Next Project >