Clicking the wrong button —

USS McCain collision ultimately caused by UI confusion

CO ordered duties of helmsman split—but all of them got sent to another console.

Enlarge/ Tugboats from Singapore assist the guided-missile destroyer USS John S. McCain (DDG 56) as it steers toward Changi Naval Base, Republic of Singapore, following a collision with the merchant vessel Alnic MC while underway east of the Straits of Malacca and Singapore on August 21. Ten sailors died in the collision.

On November 1, the US Navy issued its report on the collisions of the USS Fitzgerald and USS John S. McCain this summer. The Navy's investigation found that both collisions were avoidable accidents. And in the case of the USS McCain, the accident was in part caused by an error made in switching which control console on the ship's bridge had steering control. While the report lays the blame on training, the user interface for the bridge's central navigation control systems certainly played a role.

Further Reading

According to the report, at 5:19am local time, the commanding officer of the McCain, Commander Alfredo J. Sanchez, "noticed the Helmsman (the watchstander steering the ship) having difficulty maintaining course while also adjusting the throttles for speed control." Sanchez ordered the watch team to split the responsibilities for steering and speed control, shifting control of the throttle to another watchstander's station—the lee helm, immediately to the right (starboard) of the Helmsman's position at the Ship’s Control Console. While the Ship's Control Console has a wheel for manual steering, both steering and throttle can be controlled with trackballs, with the adjustments showing up on the screens for each station.

However, instead of switching just throttle control to the Lee Helm station, the Helmsman accidentally switched all control to the Lee Helm station. When that happened, the ship's rudder automatically moved to its default position (amidships, or on center line of the ship). The helmsman had been steering slightly to the right to keep the ship on course in the currents of the Singapore Strait, but the adjustment meant the ship started drifting off course.

The bridge layout on the McCain, with watchstations labeled. The ship should have had its full "sea and anchor" detail on watch.

The Ship Control Console of the McCain, with helm (at left) and lee helm (at right) stations. Both have trackballs to enter commands into the console through control screens.

As the McCain watch team scrambled to figure out what was going on, the ship overtook and steered across the bow of the Alnic MC.

"This unplanned shift caused confusion in the watch team, and inadvertently led to steering control transferring to the Lee Helm Station without the knowledge of the watch team," the report found. "The CO had only ordered speed control shifted. Because he did not know that steering had been transferred to the Lee Helm, the Helmsman perceived a loss of steering."

At this point, everyone on the bridge thought there had been a loss of steering. In the commotion that ensued, the commanding officer and bridge crew lost track of what was going on around them. Sanchez ordered the engines slowed, but the lee helmsman only slowed the port (left) throttle, because the throttle controls on-screen were not "ganged" (linked) at the time as the result of the switch-over of control. The ship continued to turn uncontrolled to port—putting the ship on a collision course with the Liberian-flagged chemical carrier Alnic MC.

Three minutes later, steering control was reestablished by control from the McCain's Aft Steering station, located near the ship's rudders. The Lee Helmsman corrected the throttle problem, but the recovery didn't come in time. "In the course of 3 minutes of confusion in a high traffic sea channel, the McCain was in irreversible trouble. These actions were too late, and at approximately [5:24 AM local time] JOHN S MCCAIN crossed in front of ALNIC’s bow and collided," the report states.

The report found that the McCain did not have the right type of watch on duty for navigation in congested waters and that watchstanders' training was insufficient. But there was never a warning signal from the Alnic of impending collision or a change of course by the merchant in an effort to avoid the collision. "Despite their close proximity, neither JOHN S MCCAIN nor ALNIC sounded the five short blasts of whistle required by the International Rules of the Nautical Road for warning one another of danger," investigators found, "and neither attempted to make contact through Bridge to Bridge communications."

We in tech make these decisions about UI all the time, sometimes with a lot of thought, sometimes with a little, and most often without much input from the actual people who will use our software. It's worth remembering that a lack of attention to this detail may have real consequences for people we will never meet.

Why the f* would the rudder change positions when steering is transferred from one station to another? It's a trackball for Pete's sake. The new console should just take the current offset, put it on the display, and adjust after relative to the new inputs on the trackball.

Perhaps the parts of the console that aren't controllable from that display should be in a separate color. When control is transferred it should be instantly obvious to everyone.

Also, there should be a master control station that has authority to change any setting at any time just in case there's a communications breakdown.

Thank you for this report. This is the only one I have seen about conditions on the McCain leading up to the crash.I don't know that I have ever seen a Navy report describing conditions on the bridge before. Great stuff.And thanks for not making it a video.

Adding redundancy adds complexity, and may provide new failure modes that were not considered, or even imagined, by designers or operators.

If all you've got is a single wheel and indicator in the pilothouse and an emergency capability in aft steering, this sort of failure could never occur. A loss of responsiveness to the wheel would necessarily indicate a steering casualty. And what did the most senior and experienced men and women on McCain "grow up" using?

There seems to be a lot to learn from this incident, and it's not just "hey dumbasses, stand watch better" as was apparently the case with Fitzgerald.

We in tech make these decisions about UI all the time, sometimes with a lot of thought, sometimes with a little, and most often without much input from the actual people who will use our software. It's worth remembering that a lack of attention to this detail may have real consequences for people we will never meet.

true. but from this article it seems to be that it was not a UI/UX error. It seems to be a human error (well, several human errors) starting with a failure to assign partial control to one station. Are the controls in this particular ship (the McCain) special or unique?

Why the f* would the rudder change positions when steering is transferred from one station to another? It's a trackball for Pete's sake. The new console should just take the current offset, put it on the display, and adjust after relative to the new inputs on the trackball.

I don't understand why you'd even want to transfer controls like that outside of a damage scenario... it seems easier to just switch stations?

I find the articles and forum discussions over at gCaptain, relating to the latest two US Navy, accidents more enlightening and perhaps closer to the truth. For tech news Ars is OK, for maritime analysis a more domain specific site is better imho.

as a digital UX / UI designer, most of what I have to worry about is readability and accessibility, not design that might cause accidents and deaths... in startup, tech, and design culture there's this notion of iterative design— design from research and what you know, put it out there, and then improve on the design.

For human factors, this kind of thinking could obviously cause a lot of damage and deaths. I wonder what processes would need to change to prevent this kind of thing from happening? And I wonder what other usability disasters lie in the system?

As a side note, the interface the bridge is dealing with reminds me less of a Star Trek bridge and more of something like QWOP...

We in tech make these decisions about UI all the time, sometimes with a lot of thought, sometimes with a little, and most often without much input from the actual people who will use our software. It's worth remembering that a lack of attention to this detail may have real consequences for people we will never meet.

true. but from this article it seems to be that it was not a UI/UX error. It seems to be a human error (well, several human errors) starting with a failure to assign partial control to one station. Are the controls in this particular ship (the McCain) special or unique?

I think it is almost impossible to distinguish human errors and UX design problems in situations like this: they are inextricably linked, IMO.

In this case, the watch officer transferred all controls instead of throttle only to a different helm station. That was an accident - it was unintentional. Could be the UI makes that too easy to do. It could be that the officer had poor training. It could be that poor training wouldn't have mattered if the UX or UI worked more clearly.

true. but from this article it seems to be that it was not a UI/UX error. It seems to be a human error (well, several human errors) starting with a failure to assign partial control to one station. Are the controls in this particular ship (the McCain) special or unique?

Why the f* would the rudder change positions when steering is transferred from one station to another? It's a trackball for Pete's sake. The new console should just take the current offset, put it on the display, and adjust after relative to the new inputs on the trackball.

Perhaps the parts of the console that aren't controllable from that display should be in a separate color. When control is transferred it should be instantly obvious to everyone.

Also, there should be a master control station that has authority to change any setting at any time just in case there's a communications breakdown.

Speculating: The new control was at a neutral position so the system obeyed the neutral input to move to a default setting.

OR, and this appears to have some supporting documentation:The ship is programmed so that when steering loss is detected, it automatically returns the rudder to neutral position, so the ship will sail straight and can be safely throttled down until control is reestablished.When the helmsman transferred all control, there was a brief interruption in helm control which the system registered and returned the rudder to neutral. Perhaps had it been noticed immediately, the Lee Helm could have interrupted and corrected, but without new input, the system completed the neutral position movement and waited for Lee Helm to issue a command that never happened.

I'm not a sailor of any sort, and I've never been in any military service, naval or otherwise. So, perhaps the following speculation is based on invalid assumptions. It seems strange to me that a ship that thinks it's lost steering control in a high-traffic area didn't sound an alarm to warn nearby ships that they may be out of control. I imagine there's a protocol for this sort of thing, probably an internationally standardized one.

Is it USN policy to not publicly announce when a ship is in mechanical trouble? I understand it is (or at least was at the time) USN policy not to use automatic locator beacons, presumably for secrecy reasons. On a certain level, it would make sense for operational secrecy to not announce mechanical breakdowns or other problems - don't let anyone know you're at less than full operational capacity and they can't use it against you. However, in this case, the (apparent) loss of steering control created a hazard to the entire sea lane. If it is indeed USN policy to not announce these sorts of problems - and again, this is a layperson who may be extrapolating inappropriately - then wouldn't there be a case to hold the entire chain of command responsible for that policy creating a hazard?

We in tech make these decisions about UI all the time, sometimes with a lot of thought, sometimes with a little, and most often without much input from the actual people who will use our software. It's worth remembering that a lack of attention to this detail may have real consequences for people we will never meet.

true. but from this article it seems to be that it was not a UI/UX error. It seems to be a human error (well, several human errors) starting with a failure to assign partial control to one station. Are the controls in this particular ship (the McCain) special or unique?

I think Wickwick makes a good point. The UI should clearly indicate which controls are active on a station, and which ones are not. Human error because the UI is less than optimal is a UI problem, not a human one. That's what good UI design is all about.

I'm not a sailor of any sort, and I've never been in any military service, naval or otherwise. So, perhaps the following speculation is based on invalid assumptions. It seems strange to me that a ship that thinks it's lost steering control in a high-traffic area didn't sound an alarm to warn nearby ships that they may be out of control. I imagine there's a protocol for this sort of thing, probably an internationally standardized one.

There is, and it appears it wasn't followed. For a long time, it's been naval practice to intentionally *not* automate many features and processes, because there is no more effective multi-purpose backup than a well-trained crewman. He (and it was usually he) can take over many roles at reduced capacity, and can perform other tasks (e.g., damage control) that simply cannot be automated. This led to strange-at-first-glance situations like US nuclear subs having a much larger crew than equivalent Soviet subs. Wait, isn't our US tech obviously cooler and better and more awesome?

This has been changing over the last generation or two, as it becomes more clear that crew size is the life-cycle cost driver in warships (and many other systems). The Zumwalt class of destroyers and Littoral Combat Ships carry much smaller crews than equivalent previous generation designs. But it's not clear that this is working so well (this is a very heated topic of debate, and I don't want to wade into it too deeply).

I think Wickwick makes a good point. The UI should clearly indicate which controls are active on a station, and which ones are not. Human error because the UI is less than optimal is a UI problem, not a human one. That's what good UI design is all about.

Right, and for example, the system should not appear to accept inputs it will not obey. If it had clearly said, "Rudder is currently controlled from Station X" the helmsman would have instantly known why the ship did not respond to his commands instead of struggling to troubleshoot in a situation where every minute mattered.

The whole point of having a ship like this is to use it successfully in high stress and un-optimal situations where precision is important and/or parts of the ship may be damaged.

We in tech make these decisions about UI all the time, sometimes with a lot of thought, sometimes with a little, and most often without much input from the actual people who will use our software. It's worth remembering that a lack of attention to this detail may have real consequences for people we will never meet.

true. but from this article it seems to be that it was not a UI/UX error. It seems to be a human error (well, several human errors) starting with a failure to assign partial control to one station. Are the controls in this particular ship (the McCain) special or unique?

A UI takes human error into account and works to eliminate it.

ESPECIALLY one that controls equipment. Status monitors and crap in the way are pointless on a video screen. Just have the alerts pop up and make sure the alert parameters are set (another pop-up to set them that won't go away until they are). If a console has control active, that should be patently obvious just by looking.

Human error would be "not looking", which, presumably, they were. It's just the UI didn't display its status in a way that made it clear what controls were working and what weren't.

If the indications of what is doing what aren't blatantly "at-a-glance" clear, then it's a fucked up UI.

I think Wickwick makes a good point. The UI should clearly indicate which controls are active on a station, and which ones are not. Human error because the UI is less than optimal is a UI problem, not a human one. That's what good UI design is all about.

Right, and for example, the system should not appear to accept inputs it will not obey. If it had clearly said, "Rudder is currently controlled from Station X" the helmsman would have instantly known why the ship did not respond to his commands instead of struggling to troubleshoot in a situation where every minute mattered.

The whole point of having a ship like this is to use it successfully in high stress and un-optimal situations where precision is important and/or parts of the ship may be damaged.

But that must in turn be fault- and damage-tolerant... it would not be acceptable for one station to declare ownership of the rudder, suffer some failure, and not release ownership. Designing this system is not an impossible task by any means, but it requires thoughtful systems design and FMEA exploration.

This is a lot like the Boeing vs. Airbus issue of pilot captaincy: Boeing declares that ultimately the man-in-the-loop makes the absolute final ruling, and Airbus declares that the flight control software can design out the human weakness. Both approaches have their merits and their faults.

(I take Boeing's side in this war of minds, just so everybody knows where I'm arguing from.)

Why the f* would the rudder change positions when steering is transferred from one station to another? It's a trackball for Pete's sake. The new console should just take the current offset, put it on the display, and adjust after relative to the new inputs on the trackball.

I don't understand why you'd even want to transfer controls like that outside of a damage scenario... it seems easier to just switch stations?

As stated in the article, control was transferred because the total workload on the primary station was exceeding what the sailor could handle so they split part of it off to someone else. They just fumbled and didn't switch over what they intended to.

UI design for something simple with a single function and a few outputs is hard. Designing for something as complex and dangerous as a warship would be a nightmare. The newer ships must have millions of I/O a piece to monitor/control, with a ton of it necessarily being easily (or not so easily) accessible by the crew at any time.

Why the f* would the rudder change positions when steering is transferred from one station to another? It's a trackball for Pete's sake. The new console should just take the current offset, put it on the display, and adjust after relative to the new inputs on the trackball.

I don't understand why you'd even want to transfer controls like that outside of a damage scenario... it seems easier to just switch stations?

The problem here was that one station operator was overloaded and so part of his/her duties were assigned to another station. That's perfectly fine. The ship's controls have a modularity to them that's probably quite helpful in combat / damage control scenarios. But if the UI was designed such that someone at a station can't look at it and immediately detect that they don't have control of some aspect then it's a piss-poor UI. Either the section for the helm controls should look different when it's under control vs. passive display or it should change colors or grey out or something. That's bad UI leading to human error.

We in tech make these decisions about UI all the time, sometimes with a lot of thought, sometimes with a little, and most often without much input from the actual people who will use our software. It's worth remembering that a lack of attention to this detail may have real consequences for people we will never meet.

true. but from this article it seems to be that it was not a UI/UX error. It seems to be a human error (well, several human errors) starting with a failure to assign partial control to one station. Are the controls in this particular ship (the McCain) special or unique?

I think it is almost impossible to distinguish human errors and UX design problems in situations like this: they are inextricably linked, IMO.

In this case, the watch officer transferred all controls instead of throttle only to a different helm station. That was an accident - it was unintentional. Could be the UI makes that too easy to do. It could be that the officer had poor training. It could be that poor training wouldn't have mattered if the UX or UI worked more clearly.

In the words of the immortial Dashiell Hammett:

"The outcome of successful planning always looks like luck to saps."

You don't have to distinguish whether it was a human error or a UX design flaw. The answer is: it was both. You only have to assess how serious an error it was on both sides. On the human side, it sounds like several people made errors that were relatively easy to make. They were certainly errors.

On the UX side, it seems obvious that there are a number of possible changes which would have prevented the problem. Those changes should be made. And UX testing should be improved to catch these issues earlier (e.g. before a collision).

I imagine it might also help if the controls were more physical. I see they have physical controls, but they appear to be mechanical and for emergencies only. I'm talking about something more like this:

That way, handing over throttle control could involve literally handing over the throttle control. It could be the default system when plugged in, and control could switch to the main helm station when unplugged.

That is a terrible idea, and does not address the confusion of who actually had control of what.

UI design for something simple with a single function and a few outputs is hard. Designing for something as complex and dangerous as a warship would be a nightmare. The newer ships must have millions of I/O a piece to monitor/control, with a ton of it necessarily being easily (or not so easily) accessible by the crew at any time.

For as much as defense contractors charge for this sort of work they can afford the usability testing to perfect it. And I'm sorry, while really intuitive UI design might be hard, there are some very simple rules that design engineers are taught in undergrad that apparently weren't applied here. These are the same rules that mechanical designers have considered and optimized since the beginning of the Industrial Revolution. Just because people worry about design for 2D screens now doesn't change the work on human interface that's gone on for two centuries.

1) Something that you're going to do a lot should be in reach all the time. In the case of a computer that's something that's on the screen all the time.2) Something that's rarely done and/or might have bad consequences if done at the wrong time should require several steps. E.g. break glass THEN pull lever, flip of cover then hit the abort button, etc. The best example I learned of was a toilet stall design in a shopping center that had a flip-down shelf for packages. The shelf would block the door so it was impossible to leave the stall and forget your packages. This one was apparently forgotten here. Transferring helm control shouldn't count as loss-of-control and when it IS transferred, the system should assume that lack of input = stay as you were. Dire consequences if you transfer control when you don't expect to so default to what you were doing - or at least require a confirmation on the new console as control is transferred (for each authority I'd say).3) Make the output immediately obvious from the input. You should never be in a position where you're pushing buttons, pulling lever, etc. that you don't know if you're doing anything. There should be immediate feedback that what you're doing is having an effect. In mechanical systems there was always an indicator next to a valve to show results. There was always the confirmation from the boiler room that the captain's engine setting had been acknowledged. In a situation where multiple consoles might be allowed to control multiple aspects of the system, it's got to be obvious that said console does or doesn't have authority.

I find the articles and forum discussions over at gCaptain, relating to the latest two US Navy, accidents more enlightening and perhaps closer to the truth. For tech news Ars is OK, for maritime analysis a more domain specific site is better imho.

As a former bridge watchstander, I'll try not to take offense and say GCaptain is a good place to look for discussion of these things. But it's also important to note that the report here is based on the Line of Duty report, which only accounts for the cause of death of sailors—it did not get into the legal fault involved in the collision, and did not discuss issues that could be used to find liability in maritime court.

I imagine it might also help if the controls were more physical. I see they have physical controls, but they appear to be mechanical and for emergencies only. I'm talking about something more like this:

That way, handing over throttle control could involve literally handing over the throttle control. It could be the default system when plugged in, and control could switch to the main helm station when unplugged.

That is a terrible idea, and does not address the confusion of who actually had control of what.

It's not removable (for all of the reasons removable hardware is a dangerous idea), but Beechcraft, for many years, handled this with the "throwover yoke", which is and operates exactly as you'd imagine.

Only one person can even be holding the controls at one time, but it can be "thrown over" to the other front seat occupant in flight.

I imagine it might also help if the controls were more physical. I see they have physical controls, but they appear to be mechanical and for emergencies only. I'm talking about something more like this:

That way, handing over throttle control could involve literally handing over the throttle control. It could be the default system when plugged in, and control could switch to the main helm station when unplugged.

Lots of boats have multiple consoles that can control the craft. The throttle levers on each station can be set to idle or they follow the motions of the other levers. That is, when I set my throttle body to idle, I pull out a spring-loaded pin and move all the levers to the top. To re-engage the levers I have to pull the pin again and slide them down until their detents match the current positions. Similarly the wheel can spin to match or be put to idle.

So if I'm on the deck and want to go up to the top of the tuna tower I can put my throttle on the deck in idle, climb up to the top of the tower and engage those levers and be in full control. Never at any point did my engine cut out because there was not input. Even when all the throttle levers were idled, the throttle position remained constant.