Korean Air en la decada de los 90 tuvo un altísimo número de accidentes aéreos si la comparamos con el resto de compañías de la época. Podrías pensar que su aviones eran viejos, que sus pilotos estaban mal preparados. No. Su problema era su jerárquica cultura milenaria. En ella estás obligado a ser educado y respetuoso hacia tus mayores y superiores. Es lo que se conoce como The Ethnic Theory.

El 6 de agosto de 1997 el vuelo 801 de la Korean Air se estaba aproximando al “Guam International Airport” a través de lluvia y nubes que amenazaba tormenta. El capitán ordenó al copiloto un aterrizaje en modo “Visual approach“, esto significa que para hacer las maniobras de aterrizaje la pista ha de estar visible a la tripulación. Esta fue la conversación registrada en cabina:

First officer: Do you think it rains more in this area?

Captain: (silence)

Flight engineer: Captain, the weather radar has helped us a lot

Captain: Yes. They are very useful

En esta breve conversación el primer oficial estaba intentando advertir al capitán que no era segura la aproximación visual sin un plan alternativo al aeropuerto. El ingeniero de vuelo estaba intentando comunicar lo mismo a su capitán, pero su cultura de respeto a la autoridad y miedo a disgustar a un superior les impidió enfrentarse a él y contribuyó al desastre que terminó con 254 vidas.

Boeing y Airbus crean modernos y complejos aviones diseñados para ser pilotados por iguales jerárquicos. Esto funciona perfectamente bien en “low-power-distance” culturas como la americana, pero en culturas con una “high-power-distance” en las que un piloto comete un error y su copiloto no se atreve a corregirle, es un problema.

Esta historia, escrita por Malcolm Gladwell aparece en su FANTÁSTICO libro “Outliers: The Story of Success“. Hoy quiero hablarte del diseño de interfaz en sistemas críticos al fallo. Estos sistemas son los que te puedes encontrar en una central nuclear, una sala de operaciones de un hospital o en la cabina de un avión. En sistemas críticos al fallo un error en los mismos supone la diferencia entre la vida y la muerte.

El factor humano

Nuestro lenguaje es un interfaz, lo usamos para comunicarnos con otras máquinas iguales a la nuestra, es decir, otros humanos. En la mayoría de las comunicaciones este interfaz nos es útil y funciona correctamente, pero existen sistemas complejos en las que nuestro lenguaje opera en condiciones de vida o muerte. En nuestro ejemplo, el sistema (tripulación) lanza un mensaje de error y este no es percibido como tal por el responsable de evitar la catástrofe.

La mayoría de accidentes de avión se producen durante las maniobras de despegue o aterrizaje. En la mayoría de casos estos accidentes no se pueden atribuir a una sola causa y suelen ser una combinación de pequeños pero acumulativos errores. En muchas de estas ocasiones los fallos son humanos. Incluso los pilotos mejor entrenados son propensos al aburrimiento cuando están haciendo tareas rutinarias o en situaciones de emergencia sus niveles de estrés les conduce al pánico y a tomar malas decisiones.

Los sistemas automatizados, como los ordenadores, son extremadamente competentes a la hora de hacer tareas repetitivas, pero cuando una situación imprevista ocurre y son necesarias medidas correctoras estos sistemas no reaccionan bien. Los humanos no somos buenos haciendo tareas repetitivas, pero somos buenos analizando situaciones imprevistas y tomando medidas correctoras, es por ello, que somos piezas imprescindibles en sistemas críticos al fallo.

Aún siendo piezas imprescindibles somos los elementos más débiles en la cadena. En sistemas críticos al fallo los componentes de hardware son considerados seguros si sus márgenes de fallo se mueven magnitudes de 10 ^-6 o inferiores. El límite de éxito de un operador humano trabajando en condiciones ideales es de 10 ^-4. En la siguiente tabla tienes “General Human-Error Probability Data in Various Operating Conditions“, sacada del libro A Guide To Practical Human Reliability Assessment

Las principales causas de fallos en los operadores son el estrés y las acciones repetitivas y rutinarias (DOC). Pero un buen diseño de interfaz puede mejorar la correcta intervención de un operador y salvar unos cuantos centenares de vidas.

Usabilidad Vs Seguridad

La seguridad en sistemas críticos al fallo es el objetivo principal de la interfaz, proteger al usuario de errores. La usabilidad es un objetivo complementario, pero no principal, la usabilidad reducirá la ansiedad del operador y hará que este se siente más confortable, pero debe existir un compromiso entre las características que hagan la interfaz más segura y las que hagan la interfaz más usable.

Imagina un sistema en el que se permita realizar una operación importante simplemente presionando un número determinado de veces la tecla “Enter”. Este sería un sistema muy usable, pero en sistemas de seguridad crítica permite al operador saltar pasos en los que realizar comprobaciones de seguridad importantes. Este sistema se llamaba Therac-25 y carecería de importancia si no fuera porque este Therac-25 era una máquina de radioterapia y sus operadores, médicos que administraban dosis de radiación letales a sus pacientes. Citando a la Wikipedia:

These accidents highlighted the dangers of software control of safety-critical systems, and they have become a standard case study in health informatics and software engineering.

Wikipedia

Usuarios no expertos

En la aviación o en los hospitales las interfaces de esos sistemas críticos están pensados para usuarios expertos, pero qué ocurre cuando usuarios no expertos se ven forzados a usar ese tipo de sistemas. ¿No se te ocurre ninguno? Qué tal un desfibrilador portátil de esos que ahora se están poniendo tan de moda en oficinas y sitios públicos.

En estos casos la simplificación de la interfaz es extremadamente importante, la concreción en un diseño simple y efectivo. Tom Kelley CEO de Ideo comentaba como en una de sus primeras versiones de desfibriladores portátiles estos parecían un ladrillo “brick” y se abrían como si fuera un portátil y esto no era obvio para los usuarios:

“We’re in a situation where seconds make the difference between life and death. If it takes and extra 10 seconds to open the latch, that’s a terrible design”

Tom Kelley

Los desfibriladores son usados por cardiólogos que están formados para manejar el aparato. Más importante aún, determinan si la víctima está sufriendo un ataque cardíaco o no antes de administrar una descarga eléctrica. Este uso y comprobaciones deben de trasladarse a una interfaz en la que un usuario no experto haga un correcto uso del mismo. Los creadores del desfibrilador portátil se fijaron unas premisas básicas para el diseño del dispositivo:

“The device must communicate immediately what it is, exactly what to do, and help users do it quickly, confidently, and accurately in socially and emotionally charged circumstances”

globaltechnoscan.com

Y de un formato ladrillo (brick) se paso a un simple proceso 1-2-3

Otras decisiones de diseño fueron que debido a la caótica situación en la que se encontraba el operador, no se podía confiar en su criterio para determinar si la víctima sufría o no un ataque cardíaco, por lo que el dispositivo incorpora una funcionalidad en la que se obtiene información de los electrodos situados sobre víctima y si efectivamente sufre una parada cardíaca la descarga se realiza. También en los últimos diseños se incorpora instrucciones sonoras que indican al operador cómo debe de actuar, como dato curioso la voz seleccionada es la de Peter Thomas presentador Británico de las series NOVA que es conocido por su voz calmada.

Los sistemas críticos al fallo constituyen un importante campo de estudio para el HCI y lo que es más importante estos estudios repercutirán sin ninguna duda en reducir los fallos humanos en sistemas no críticos.