Take Off: Seven Lessons from the Aircraft Industry for UX Designers

These past few months have seen me following shows about air crash investigations on YouTube. It’s not the macabre fascination for death and destruction that keeps me glued but the seemingly minute design problems that lead to these catastrophic events. Sometimes these were insanely complicated and sometimes as plain as day. What was interesting were the parallels I saw between the design of aircraft and that of the user experience (UX) design of software. So here’s a list of the seven lessons that I took away from the aircraft and airline design industries:

One: Success is when nothing happens

This is probably the most important lesson that I took away from watching these videos. No one complains when a bomb does not go off on an aircraft. No one talks about flights that land at their destinations without incident. And absolutely no one mentions a flight that arrives on time.

In UX design too, most people don’t usually remark when things work well. They are just happy using it and focus on getting their work done. Moreover, the new experience quickly becomes the baseline expectation from the software.

When designing systems in airline industries and also in user experience, the lack of a positive response from customers cannot be deemed as failure. Instead we must use other measures for evaluating success. Better measurements of success are repeated engagements, frequency of use, high numbers of referrals or number of conversions.

Two: Things are made better over multiple iterations

An aircraft is a very delicate balance of a lot of different systems that have been perfected after their interaction and dependencies on other systems were learnt over time. Take for instance, the airspeed indicator on an airplane. Early models carried a single gauge. When people recognised that the gauge is a simple mechanical device that can fail, they added another indicator for the sake of redundancy. Then in one incident, one of the gauges wouldn’t work properly and showed an incorrect reading. This made pilots of one aircraft spend an inordinate amount of time trying to figure out which of the two gauges was showing the correct reading and this resulted in the plane crashing. After that incident, the human behaviour of pilots was taken into consideration and a third gauge was added so that pilots could look at all three gauges if required and decide quickly.

It is nearly impossible for any human being to design an aircraft that takes all of the factors of failure into consideration right in the beginning. In fact the primary objective of the National Transportation and Safety Board’s (NTSB) and their counterparts across the globe, is to identify such design flaws and communicate it to the airline industry as a whole so that good solutions could be adopted by all.

In UX design too, an iterative approach is the best way forward. It is sometimes possible to anticipate some problems ahead of time based on the experience of the designer. However, it is best to find a way to put the product in front of real-users and carefully optimise it after studying real-world behaviour. In the digital space it is especially easy to do and one can even simultaneously release multiple versions at the same time bringing down the cost and time required for these iterations.

Sometimes inexperienced designers (and clients) try to make the leap and create what should be the third version of a piece of software in the first attempt. This is a huge waste of time because no matter how carefully we design the application in the lab, we learn the truths of our designs only only in the real world as we may have made false assumptions or find that customers are actually willing to pay for something we didn’t anticipate. It is best to break up the design task into smaller chunks and find the fastest paths to get that chunk released. In fact, the best designed software out there, which has to include Google Maps among them, followed this very approach.

Three: Experienced professionals make all the difference

While I argued that it is best to release things over multiple iterations, there is a lot to be said for experience. A seasoned aircraft designer will understand amongst other things, the implications of placing an electrical line over a fuel supply line, the need to place the cock-pit voice recorder far away from the data recorder or that the primary driver of the aircraft systems design isn’t cost reduction but the safety of passengers.

Similarly, an experienced UX designer would be able to identify features that are critical to the business proposition, the dependencies of design decisions on the customer service teams or how future modules can be added on top of existing ones with the least amount of code revision by a development team, and so on. The more experienced the design team is, the more likely they will be able to anticipate such interdependencies between the various modules of the application.

Furthermore, any design team that works across multiple industries will tend to evolve faster than a design team that only works in a single vertical simply because they would have seen solutions that may apply to one while working with another. For instance, we worked on the design of a breast cancer scan app that interfaced with a handheld scanner over bluetooth. The app needed a review feature that would allow a user to easily go through all the scans she had done previously to identify growth of red spots. We adapted a reviewing method that is similar to scrubbing through videos in movie players as the method that would help identify growths in multiple scans. While this is just one example, it occurs all the time.

Four: Be very discerning about why you need the user’s attention

On Delta Air Lines Flight 1141, the air plane was equipped with a Take-off Warning System (TOWS), an alarm that indicated the incorrect configuration of the aircraft for take-offs whenever the plane began to move. While it had good intentions, the alarm was designed to sound as soon as the airplane began to back away from the terminal gate and would sound all the way until the airplane achieved enough velocity to take off.

At busy airports, it is not uncommon to have many aircrafts ahead queuing to take off which meant that the alarm would be sounding for much longer. To circumvent this, pilots frequently popped the circuit-breaker that would shut off the alarm. This led to the aircraft crashing as pilots attempted to take off while the aircraft was in fact not at a speed that allowed it to climb. After the disaster, the National Transportation Safety Board (NTSB) issued directions to the aircraft manufacturers to fix the threshold for the alarm so that it would only sound an alarm when a bonafide low-speed take-off was attempted.

In UX design too, it is important to exercise restraint when showing error notifications lest we desensitise our users to the notifications. For example, we see apps that display an error stating that a valid email address is required as soon as the user focuses on such a field on a form. This is a bad pattern as the user is yet to make the mistake that the error is warning him or her about. A better time to show this error would be when the focus shifts away from the field or if that’s not possible for any reason, use any algorithm that more closely resembles the event that identifies that the user actually made such an error before warning them. Otherwise, they will be desensitised to the error notifications and can end up round-tripping multiple times through a workflow not realising the mistake they may be making. This is a sure-fire way to leave the user frustrated with the app.

Five: Know your points of Inspection

It is almost impossible to examine every aspect of a complex system on a routine basis. But inspections are necessary before every flight to make sure passengers can fly safely. To deal with this, pilots are taught to do pre-flight checks which include walking around the aircraft looking and feeling for any cracks or fatigue marks on wings, the points at which they attach to the main fuselage, oil and fuel for contamination and proper levels, the lights and finally the wings for ice formation. These pre-flight checks in-fact cover the points which could indicate failure of sub-systems. While this is never as good as a complete and thorough examination of an aircraft, they are good points of inspection which can indicate the proper functioning of an aircraft.

The idea of having points of inspection is critical in UX design as well. There are specific points of failure for every application that should be examined on a frequent basis as they indicate the health of the user experience. These points of inspection may include the number of customer service requests, number of returns or exchanges, amount of time spent within an app, amount of time spent performing a function, etc. and will differ depending on the nature of the application. Experienced designers can spot these points during the design stage itself and track them so that future versions of the app can be optimised based on this information.

Six: Averages can be misleading

On January 8, 2003, a US Airways Express Flight 5481 crashed to the ground after only 37 seconds of flight time. On it perished 21 passengers. The investigation revealed that the plane was in fact overweight by a total of 264 Kgs more than the maximum allowed Federal Aviation Authority’s (FAA) standards. The cause of this overloading was in fact the miscalculation that arose from working with the average weight to be considered per passenger based on the FAA guidelines set based on the average weights of people set in 1936. Recommendations were made by the NTSB to load air planes based on actual weight of passengers rather than an estimated average.

In UX design too there is the notion of personas which are essentially a typified set of the users. While this makes it simpler for us to design systems to serve these types of users, it must be kept in mind that they are not substitutes for actual users. Persona’s are useful when designing the first version of a heretofore non-existent system, but we must stop relying on them as soon as we have real data from real users because they are far more indicative of the reality than what we may have imagined in labs while designing the systems.

Seven: Design more satisfying workflows

In one of the most famous air-crash investigations, US Airways Flight 1549 flown by Captain Sully, the air plane landed in the Hudson river. All lives were saved in this crash but an investigation was conducted by the NTSB as the dual-engine failure was unheard of before that incident and it suspected pilot error to be one of the contributing factors for the crash. While the pilots were acquitted for any wrong-doing, they were commended for having the presence of mind to turn on the auxiliary power unit (APU) as soon as they lost power instead of following the quick-reference-checklist for handling bird-strikes put that step much further down the list of tasks for the pilots to complete. Amongst other recommendations, the NTSB also made recommendations for the redesign of the QR checklists to make APU engagement one of the first steps for pilots to perform.

In other incidents, the QR checklists were very long and spanned multiple pages. The checklists didn’t take into consideration the state of mind of the users or the possibility of them making mistakes and having to repeat the steps in the checklists all over again. An examination conducted by researchers from MIT revealed these problems with the checklists and made recommendations to keep them as a collection of short tasks rather than a long process.

In UX its useful learning as designers are tempted to build workflows that combine a whole lot of steps together. Even the creation of “wizards” for achieving a number of tasks together should be reconsidered if usability is ever a matter of concern. Chunking them into smaller steps will make them much easier to handle, create a sense of completion and also lead to satisfaction in the user’s minds.

— Sharan Grandigae, Founder and CEO of Redd Experience Design