systems

Who would turn off the wrong engine?

In designing user interfaces there’s a lot we can learn from systems where failure to consider human factors has resulted in terrible consequences.

On 8th January 1989 British Midland Flight 92 crashed whilst attempting an emergency landing. There had been a fire on one of the engines which led to its malfunction. The captain reacted by shutting down the engine.  Only he shut down the wrong engine. With no power, approaching East Midlands airport the captain manged to glide the Boeing 737-400 to avoid Kegworth village but crashed short of the runway.  47 people died.

The investigation into the Kegworth air disaster identified engine malfunction (the engine used in the aircraft was an upgrade of an existing engine and had not been field-tested) as causal factor, however the report concentrated upon the failure of the flight crew to respond accurately to the malfunction.  Human error was the primary cause.

The truth is a little more complicated than that.  Why does a captain with over 13,000 hours flying experience and a first officer with over 3,000 hours experience shut down the wrong engine?

A number of human factors contributed to the disaster including organisational issues (refer to this paper for discussion of the role of managerial failures in disasters) and cognitive overload.  But of equal importance (and indeed buried in the appendices of the Investigation Report appendices) is the issue of design. Around 50% of accidents and incidents in the aircraft and nuclear industries have a root cause in design (source).

Take a look at the cockpit controls (taken from the investigation report). The left image is for the earlier 300 series and the right for the 400 series aircraft on which the captain had only 23 hours experience after a one day training course.

The actual cause of the engine malfunction was a broken turbine, itself the result of metal fatigue caused by excessive vibration (source).  Had the Captain noticed the Vibration Warning display he probably would not have made the wrong decision.

The Vibration Warning display on the new 400 series was in a different place to the 300 series, but more critically it was designed to be significantly smaller “the dial on the vibration meter was no bigger than a 20 pence piece and the LED needle went around the outside of the dial as opposed to the inside of the dial as in the previous 737 series aircraft” (Source: Wikipedia).  Take a look at the arrow on the left hand image, the display dials on the 300 series use mechanical pointers. On the 400 series they were redesigned with short LEDs rotating around the numbers. These, as the investigation report noted “are much less conspicuous than mechanical pointers, acting more as scale markers, and providing less immediate directional information).

The report criticised the layout of the instrumentation and helpfully suggested an improved layout.  The layout was (and as far as I can tell, remains in 737s) split into primary instruments and secondary instruments.  The issue with this layout is that the dials are not spatially aligned with their associated power levers.  If the pilot is focussing upon the primary instrumentation, the secondary instrumentation is in peripheral view.  This layout will lead to attention based around specific instruments rather than engines.

Compare this to an alternative design that the report provides where the dials are aligned to their associated power levers.  The report recognises the design trade-offs here but concludes that to break the left-right mental association with the engine position was probably not the most optimal solution.

This paper describes the issue well:

The 737 involved in the East Midlands crash had flight deck engine information that lead to confusion under mental pressure. Placing the secondary information sets for both engines to the right of the primary set broke the implied rule set by all the other engine information, that the left engine had left hand controls and indicators (and vice versa). If one assumes that the optimum positioning of indicators is the one that requires the least mental processing then a simple symmetry about the aircraft centre line seems appropriate. The actual positions required a mental spatial transposition of one set of dials to the other side… The readability of the indicators had been reduced by the substitution of electro-mechanical readouts with electronic readouts, but which simulated the old design. Possibly the redesign to electronic readouts should have taken the opportunity to use a rather different layout, possibly with linear indicators rather than rotary ones.

OK, so lots of words, but what is the point of this to what I usaully blog about?  The issue is one of design and layout and who’s responsibility is it.  In designing user interfaces UCD is often seen as a luxury, developers believe that they can design a GUI as well as anyone, and stakeholders (especially on internal projects) will question the value that a UCD person can bring to the project.  Does a developer or an engineer by training and instinct stop to ponder the human factor and the human consequences of the GUI layout? What are the consequences of this?  As can be seen from Kegworth, seemingly minor changes to the control layout can have a signficant impact on the safety of a complex system.

What do you really need?

A couple of clients I’ve worked with recently have been consolidating their application space, decommissioning old technology and replacing it with a new single application with a core user interface. I’ve written about this before but it is worth revisiting.  All too often the starting point is the functionality and the features of the existing applications.  The client states we must at the very minimum maintain feature parity, and where the business needs, enhance functionality.  Starting with the existing applications and as-is processes is a good start, but never where the focus should lie.  The focus should be around the business intent; what are the business goals the system is helping the user achieve?  Spending time with the end users of the system is enlightening.  It is a crude picture, but this shows what the truth often looks like.

Three systems, duplicate functions, redundant functionality

There are three systems that have been developed over the years, commissioned by different business stakeholders with different budgets and different delivery teams. Of each of these systems only a fraction is ever used.  (This is especially true of vendor products that have requirements rooted in the market rather than the specific needs of that organization.  Think about how many of the features in Microsoft Word you use).  If there is significant functional redundancy in the applications, there is also duplicate functionality that results from the different development legacies.  It is not unusual in such a landscape for the user to enter the same data into each system.  Not something you would wish to replicate in a new world.

In building a new application, the place to start looking for requirements is not so much the as-is processes or existing applications.  The place to start is the business intent and what the business actually wants the system to do.  More importantly, that means starting with an open mind and challenging notions of process complexity.  Is the process complex because it really is, or because the current systems make it that way? In my experience, more often than not, it is because of the former.  Spend time with end users, see what they do today.  By asking seemingly stupid questions, taking a starting position that the process is simple and challenging ‘why not?’ can yield valuable insights.  By all means consider the as-is world, but don’t let it cloud your judgment in designing ‘to-be’.

What is your business?

Should “the business” care about IT? Should an investment bank trader know anything about XML, or a marketeer know anything about SQL? Probably not. Even less so should they be talking to their IT colleagues of their requirements in these terms. The business should speak to IT in a language of value driven requirements rather than implementation detail. Yet in many organisations (where IT has historically had a track record of failure), the business has taken a greater interest in IT delivery. They start talking the language of the techie. When this starts to happen business operations no longer see the clarity of their business. They see systems. In an investment bank setting: the trade is booked in Zeus. Settlements are handled by Minotaur, payments by Socrates. Corporate actions are handled in Hades. Depending upon the geographic region, client management might be handled by Tomsys, Dicksys or Harrysys. You ask a business person what do they do and they talk in terms of systems. Getting down to the underlying requirements of what they actually want to do is hard. Innovation and creative thinking are hard because we always return to what the limitations of the current systems are. Why there is a requirement for a Reconciliation System rather than asking why there needs to be any reconciliation in the first place.

So here’s a suggestion. Act dumb. Forget everything you know about the way you do things and go back to first principles. How would things be if we were starting from scratch. How would you describe your business intent (not the what you do now, rather what would you do) if you had to explain it to a novice who was starting a competitive business to put your business out of business. I doubt the word system would come into the description.

System Obituary

Talking about workshop icebreakers with Prashant and here’s an idea: participants write their own tombstone or obituary. “Here lies Jack. A life spent comparing numbers on an excel spreadsheet”…. You could even use Tombstone Generator to bring them to life:

Tombstone

Hmmmm, maybe not the strongest icebreaker (indeed it could kill your workshop before you’ve even started… If you don’t consider cultural sensitivities you could receive some rather blank looks, if your audience doesn’t have a dry sense of humour or doesn’t “get it” you’ll be in trouble…)

So maybe it won’t work so well with people, but how about systems? If you are looking to understand the current system landscape, why not ask the participants in your workshop to list out all the systems they can think of and ask them to write the inscriptions that would appear on the tombstone.

For example…

+

Customer System RIP
1997-2007

Dearly beloved wife of Position System and bastard child of Excel spreadsheet (1991-date).

Threw tantrums and refused to give the right answers when it really mattered
Grew bloated in size due to unwanted change requests
Lost self worth due to non-business value changes
(Died in the loving hands of Indian Outsourcing Company)

She will not be missed

+

Here Lies Position Reconciliation Spreadsheet
1991-2007

Father of Every Conceivable Problem

A real handful to manage but usually got there in the end
Local resident of Sarah’s Desktop, he never got out much
Prone to occasional lapses of judgement that were rumoured to cost the bank millions

He has gone to a better place (recycle bin)

And why restrict this to the current state. It could be a useful exercise in understanding what benefits a new system could be remembered for…

+

Here lies New System
2007-2017

Saviour of the Back Office

Banished reconciliation breaks to history
Defeated the multi-headed Legacy Dragon, bringing peace and harmony to the Ops team
A single voice of truth
Beautiful to look at, easy to get on with, she gave such joy to customers and added such value to the business

Without her Ops can no longer function