10 things to learn about product design from the Boeing 737 max
Something I have been fascinated with for a long time has been the aviation industry, and in particular how these giants in the skies are built. It’s interesting to see the innovation and creativity that is going on behind the scenes and the symbolism of aircraft bringing together people from all walks of life.
However, sometimes within this industry, things don’t go necessarily to plan. I watched a program recently here in the UK called “10 Mistakes: 737 Max” of which it goes over the 10 fatal mistakes that led to the crashes for the Lion Air and Ethiopian Airlines a couple of years ago. As the show explains, each element that resulted in these tragedies were preventable.
Although we as Product Designers most likely won’t be involved in products as higher risk as the mistakes identified within the program, we are still responsible for making sure the product keeps everyone safe and is built with people at the forefront.
Below is the 10 mistakes the show covers:
1) Not starting from scratch
To keep up with demand within the aviation industry and with the announcement of the Airbus 320 Neo helps provide more fuel efficiency, Boeing needed to stay competitive. In order for the new design being good, it needed to match the standards of Airbus’ new release of giving airline’s lower operating costs and reduce fuel costs.
The plan was to remodel from an earlier model that has already been approved by the US Aircraft authority, called the Federation of Aviation Administration (or FAA) and provided a quicker way to keep up with competition and reduce costings and timings to build new aircraft.
However, within this method, they forgot “The changed product rule”, of which reviews how one part of the product functions change can influence other parts of the system, were ignored and considered in isolation rather than looking at the whole aircraft and the effects this would have on how it worked.
Lessons to learn from this: Although we as Product Designers might not always be creating new products, when adding something new is adding (no matter how big or small), and when developing products, we must remember to use “The changed product rule” and make sure to test the old one features must still work as well with the new feature that’s been added.
2) Cutting testing time
In order to increase the advancement of building a new aircraft, Boeing introduced a Countdown time called an “Excitement generator”. Whilst the purpose was to increase productivity and reduced costs and the testing process by 2000 hours, it actually put vast amounts of pressure on fastening the build process, whilst putting quality and safety in the background.
Although Boeing does have a strong safety record, utilising the “Excitement generator” meant that the development process was rushed and meaning safety was ignored.
Lessons to learn from this: Causing the pressurisation on timings to complete a project, will more likely lead to faults and technical debt being discovered by the user. Instead, work backward and work as a team to find out more about the issues with the product and estimations of timings of the product build.
3) Unbalancing of the new engines
One key feature that was changed on the Boeing 737 Max was the change of the existing engines from previous models. Since there was no room in the previous position, they moved them forward towards wings in order to improve the balancing of the aircraft. However, during initial testing, this changed the way plane behaved in flight, which affects how the plane pitches in the air. If the nose pitched up too much, then it would cause too much lift and bring the plane down.
Lessons to learn from this: Review the effects on how the product change will effect the existing product and performance.
4) The Deadly Software
Following from the previous point about the new engine option, in order to prevent this pitching, a new software called MCAS was created to help with information from censors plane flighting at and check the Gforce. If the nose pitched at a certain angle, the MCAS software would kick in to help push down the aircraft nose. However, it only used one censor, which provided false data in terms of the pitch and altitude.
On most modern planes, you need at least two of every key feature in order to make sure it doesn’t fail. As one of the experts highlighted, “Look if you had one thermometer it says 30oc one minute and -5oc, you wouldn’t think that it quickly got cold. You would think that its not pushing the right data and would need another thermometer to compare it against”.
It was this incorrect data saying the plane was going to stall, pushed its nose towards to ground and caused two identical accidents involving Lion Air and Ethiopian Airlines.
Lessons to learn from this: Double-check the data that is being produced by the system is vital to ensure the systems are working as they should. Having two methods of recording data can sometimes be necessary in order to avoid these faults.
5) Allowing Boeing to test their own products, rather than through relevant authorities
Due to the timescale, the number of changes, and resources to keep tab of the changes with the Max aircraft, the FAA gave the majority of the sign-off to Boeing during development practice, assess changes, and effectively sign off work (also known as Self-certify process.)
However, this provides a conflict of interest, and as one commentator noted it’s like “letting the fox guard the chicken pen,” leading to key safety mistakes.
Lessons to learn from this: Although its ok to let stakeholders or internal users to do user acceptance testing (UAT) in order to review changes, ultimately the user of the product needs to be the key person to test and see if the product is viable for them.
6) Inadequate training
The initial selling point of the Boeing 737 Max was that because it was deemed “similar” to previous models, pilots of other 737 did not need training. This would in turn be attractive to airlines to say that they can go in without additional training, which in turn would lead to saving costs for both sides.
Instead, training was done via 2-hour I-pad training rather than simulation training, which would provide an overview of the key feature changes of the aircraft.
Tragically, Lion Air requested simulation training before the aircraft would be handed over to them, but if Boeing agreed, this would go against the initial benefit of pilots going into the aircraft and knowing what to do.
Lessons to learn from this: Training needs to happen once the product is delivered to the user, regardless of how well versed they are with the previous version of the product. Investment in thorough user training and guidance to simulate how to use the product with the new changes.
7) Missing information from the flight manual
Because there was a rush to get this certified to fly and needed sign-off from the FAA, key new features were deemed “similar” to the previous 737 models. Also, they agreed that the MCAS software was costing time and left it out as avoiding seeing as a new feature.
However, this proved fatal as none of the pilots of the aircraft in question had no idea how to deal with problems with the aircraft and why it wasn’t easy to control. If pilots knew about the situation and information, they might have known how to deal with this.
Lessons to learn from this: Users need guidance in terms of information regarding this change, no matter how small the change is. Ensure that product release documents outline every change that is due to release and communicate to users if training is required on unfamiliar features.
8) Failure to pass on vital information
Before the Lion Air crash happened, unbeknown to them this wasn’t the first time these issues happened. The day before the nose responded to malfunctioning data from the sensor for the MCAS software. Overriding the software manually, reported to ground staff but nothing was logged within the maintenance documentation for that aircraft, leading to a failure of communication.
Lessons to learn from this: Ensure communication between the development process and the user feedback is logged. Also, ensure this communication is logged in a tangible manner.
9) Blame Pilot error
When the first crash with Lion Air happened, Boeing accepted that pilots were to blame. Unfortunately, this fact was heightened due to Lion Air having a poor safety record.
Besides, if the aircraft was deemed at fault then stock price fall, and profits are reduced for Boeing.
However, both pilots from Lion Air and Ethiopian Airlines had more than 6,000 hours of flight training, which is very experienced, in particular for the 737 models.
If Boeing focused on planes rather than pilots before the next crash happened (Ethiopia Airlines), this crash could have been avoided.
Lessons to learn from this: Sometimes it’s easy when designing products to blame the user rather than the product. However, this does not solve the systemic issues behind the fault of the product. Focus on feedback from key faults from the user, understand how the fault is happening, and design a solution with them in mind.
10) Didn’t take into account the human factor
When reviewing the safety systems within an aircraft, the FAA highlights that it should take 4 seconds for pilots to be able to handle a critical situation; any more and the safety systems would not pass inspection.
However, when the MCAS software was reviewed and created simulated a fault in testing, it took 10 seconds to resolve the nosedive issue, which should have not been approved.
Boeing failed to take account of the “Stress performance curve”, which considers the stress levels a pilot can perform under to rectify a problem.
For both the Lion Air and Ethiopian Airline crashes, the issue happened within 4–6 minutes after take-off and the pilots were frantic in trying to solve the issue. From the black box data that was gathered from both crash sites, they lost and gained control 3 times, but tried to take over manual control they found it difficult to do so.
Lessons to learn from this: Take onboard the startle effect, which is used to identify physical and mental responses to a sudden unexpected stimulus. Through research and testing, make sure to design technology for how people connect with the product and the emotional impact of how to deal with unexpected situations whilst using the product.
If you’re interested in receiving mentorship from me, whether it’s for a one-off call or for short-term or long-term membership in UX Design, feel free to book a 30-minute consultation with me through my Calendly link. I look forward to helping you grow in your UX Design career!
