When the interface is the hazard
The US Navy tore the touchscreen controls out of its destroyers and went back to physical throttles after the USS John S McCain collision. What that says about complexity, human error and designing software people can actually use.
A story I read recently has stuck with me. The US Navy has decided to tear the touchscreen controls out of its destroyers and put physical throttles back in, after the investigation into the 2017 collision between the USS John S McCain and an oil tanker near Singapore, in which ten sailors lost their lives. The National Transportation Safety Board did not point to a broken part or a single bad call so much as the system the crew had been given to steer the ship with, which it found overly complex, and which left the watch team unsure who was actually in control of the helm at the moment it mattered most.
I studied psychology, and human error and the way people deal with machines was the part that stuck with me, so a warship being handed back its physical levers because the screens were too confusing is about as pointed an example as I could ask for.
Complexity as a failure mode
What struck me is that nothing had failed in the engineering sense. The screens worked. The throttles responded. The problem was that the design offered so many ways to do the one job - throttles that could be split between stations, control that could be passed around the bridge - that under pressure nobody was certain where the authority actually sat, and the single indicator that would have told them was not where anyone was looking.
That is a far more interesting kind of failure than a snapped cable, because you cannot fix it by making the part stronger. The complexity is the hazard. Every option you add to an interface is one more thing the operator has to reason about, and reasoning is exactly what deserts a person first when they are tired, or frightened, or watching a tanker close in at night.
What this means for business software
None of this is confined to warships. I build web applications that run businesses - the admin panels, dashboards and operational tools that people sit in front of all day, often the ones that replace a tangle of spreadsheets - and the same trap is everywhere. Software gathers features over time. Every release adds another button, another setting, another clever option that someone asked for, and each one is defensible on its own. The sum of them is a screen where the thing you need to do in a hurry is buried three menus deep, sitting next to four things you must not touch by mistake.
The person using it absorbs that cost, usually invisibly, until the day someone confidently presses the wrong control because it happened to be where they expected the right one to be. So when I design these systems I try to keep asking the unglamorous question the Navy is now asking in hindsight: when this goes wrong at the worst possible moment, what is the person actually looking at, can they tell at a glance what state things are in, and do they know what is in control. Fewer paths through the tasks that matter, the critical state made obvious, and the dangerous actions kept well clear of the routine ones.
There is a strange comfort in watching an organisation as sophisticated as the US Navy reach for the same lesson the rest of us keep relearning, which is that the interface that wins is the one a real person can still read correctly when it counts, however much cleverness you could have crammed onto it instead. If you have a system your team leans on every day and you are not sure it would pass that test, I would be glad to take a look.