Creating software may at first seem as similar to civil aviation as apples are to asteroids, but there is actually quite a bit of overlap. Both endeavors involve providing a highly arcane and technology-driven service. Both require the integration of multiple technologies and disciplines. And both depend on human factors for their success. The main difference, of course, is that when civil aviators get it wrong, people’s lives are jeopardized.
The only thing jeopardized when Software Designers get it wrong is your bottom line.
But isn’t that enough jeopardy to consider this comparison a little more closely? If pilots, air-traffic controllers and airplane designers got it wrong as often as PM’s, QA staff, and UX Designers do, airplanes would be coming down all over the world and no one would ever want to fly.
Airline pilots are in near constant communication with air traffic controllers. Both disciplines follow rigorous procedures at all times and have a checklist for almost everything they do. Airplane designers are always innovating, but build rigorously on the fundamentals and consider every possible side effect and unintended consequence whenever they change anything.
What if those of us who design software held ourselves to such high standards? Some of us do. But entirely too many Software Designers don’t. Not by a long shot.
I must at this juncture confess a newly-acquired weakness for a National Geographic television series I’ve discovered on YouTube called ‘Air Crash Investigations.’ Each episode tells the story of one, usually fatal, avionic catastrophe and the search for what caused it.
An episode I watched recently points up why I feel this comparison is worthwhile. Tragically, more than half the passengers aboard a Singapore Airlines 747 lost their lives in October 2000 when it hit an obstacle on the runway during an attempted takeoff from Chiang Kai-shek Airport in Taiwan at night during heavy rain and wind. As investigators discovered, the pilots had attempted to take off from the wrong runway. The one they were on was under construction and they had hit equipment that had been left on its surface.
How did this happen?
Its two root causes can be perfectly analogized to two key struggles in User Experience.
Misalignment of the User Experience
Every User Experience is entirely comprised by an intention someone, somewhere has for you, the User. They have created this UX because they cannot be there for you in person to facilitate this intention. They cannot be there to open a door for you – so they make you a doorknob. They cannot stand at the foot of a damaged runway in the dark and wave you off it – so they build you an instrument. They cannot be there to type the arcane lines of code needed to get a computer somewhere in California to send you your new lawn furniture – so they make you a User Interface. It’s like leaving someone a note: “Sorry I can’t be there for you right now, but here’s what you need to do.” That’s all a User Experience is. When it succeeds in facilitating your User’s needs and you didn’t have to be there in person to open a door, direct a plane, or type complex code, it has succeeded as a User Experience. When it fails to do this one thing, if it requires the User to think about it, if it requires the User to call someone or consult some other resource, it has failed as a User Experience. It has failed no matter how many lines of code have been written to create it. It has failed no matter how much money was spent in its construction.
One of the reasons a User Experience will fail is because it is sending you inconsistent messages. This happens in software design when the intention is one thing, but the UX is another. This happens all the time, unfortunately. When the designer wants you to stay on their Web-site and look around, but fails to make plain the means or even the motivation for you to do so. The designer has failed to connect their intention to your deeds. Instead of leaving you a doorknob with which to open this door, they may as well have left you a cupcake in the hopes that perhaps consuming it will give you the strength to figure it out for yourself.
Most of us designers are smart enough to not leave a cupcake. But what if the UX design is a team effort? And what if every member of this team had the key intention clearly in mind? All except one? The stage would be set for an inconsistent User Experience.
The User Experience designed to facilitate the collective intention of keeping aircraft away from runway 59R was just such a team effort. And unfortunately, all it took was one team member to drop the ball. The airport communications department contributed by making sure a memo about the runway got into the hands of these pilots before takeoff. The air-traffic controllers couldn’t contribute because of the weather conditions – they couldn’t see Flight 6 from the tower. The designers of the Boeing 747 contributed by providing instruments that showed the beacon at the end of the runway being slightly off-center, an indication to the pilots that they were near, but not ON the runway they were supposed to be using. The airport grounds crew contributed by clearly labeling the runways. But unfortunately, this grounds crew is also the team member that dropped the ball:
- The runway lights were on -- just as if it were in service.
- There was no sign or barricade at the foot of the runway that said ‘Under Construction.’
On a dark, rainy and windy night the runway labeling and cockpit instrumentation was ignored by a flight crew distracted by weather reports in favor of pure, visual muscle memory: “The lights are on. This must be the place.” The grounds crew of Chiang Kai-shek Airport may as well have left a cupcake at the foot of runway 59R.
Every contributor to the User’s experience of that runway contributed in such a way that the core intention of keeping airplanes off of it at all costs was foremost in their minds. Every contributor but one.
The commentary of aviation writer Jeff Wise is featured throughout the episode on Flight 6 and a phenomenon he identifies as a major contributing factor is what he refers to as “Confirmation Bias.” Wise says:
“The human brain is always trying to convince itself it has a complete picture of what’s going on. And so that when contradictory information comes in, there’s a tendency called ‘Confirmation Bias’ to ignore it and concentrate on what you think is happening.”
The crew of Flight 6 were distracted Users of Runway 59R. They were distracted by the weather and the steps they were taking to account for it. Your Users are distracted, too. They are distracted by the television or the meal they’re taking at their desk or the chat they’re having on facebook. When you need them to regard a page they encounter on your Web-site as a place where they should do one thing, but it comes in the context of something else, the more likely they are to let habit and muscle-memory be their guide.
A recent debate that erupted at my present place of employment was how we were going to get Users to stop using the ‘Back’ button in their browsers to navigate a particularly data-heavy sequence of screens. The data-drag was just too big a challenge for our middle-tier people at the time. There were those who were arguing in favor of somehow disabling the ‘Back’ button’s functionality. There were those who preferred a “tough-noogies” approach and let them start their search all over again –essentially letting the data fall. Some others felt sure we could label our way out of the dilemma.
But of course, the best answer was none of these. Everyone uses the ‘Back’ button. Everyone. It’s a usability fundamental. Our propensity to use it is as habitual as breathing. Its meaning and importance are as indelibly written into the engrams of our minds as the meaning and importance of runway lights on a runway:
This is how I back up.
This is where I take off.
The only effective way to solve this problem was to re-shape the flow by disincentivizing the user from ever wanting to use the ‘Back’ button. Giving them someplace better to go than back. You had to invent a new narrative for their minds to walk down and get habituated to. If one button means Yes and the other No, you don’t make them two different shades of grey. You make the former green and the latter red. When one runway is for landing and taking off and the other is for staying the hell away from at all costs, you don’t let them appear to anyone as anything but completely dissimilar. Say what you will about Chicago politics, but when former Chicago Mayor Richard M. Daley closed a lakeside runway post-911, he knew how to get the message across.
When distraction is an expected factor, Confirmation Bias will subsume your User and context will rule the day. Never be so immodest as to suggest your User has nothing better to do than be curious about how you think they should use your Web-site.
So the next time you find yourself in a position to wonder why your software is not performing, pretend someone’s life depended on the answers to these questions:
- Did everyone contributing to any given UX have, at the forefront of their mind during its creation, the relevant core intention of your product?
- Do key workflows account for Confirmation Bias. When encountered individually and in sequence, do the screens confirm or confound the User's expectations?
The crash of Singapore Airlines Flight 6, like all major air disasters, caused a total overhaul in standards, procedures and training.
If only this was what happens in Software Design.
Here is the Air Crash Investigation episode descibed in this post.