Interacción humano–máquina: controles, pantallas y automatización

Una persona pulsa «iniciar» en una pantalla. El sistema puede arrancar una bomba, programar una operación para más tarde o aceptar la orden sin ejecutarla porque está en modo mantenimiento. El dedo hizo el mismo movimiento; el efecto depende de la correspondencia entre control, estado, modo y resultado. Si la pantalla no muestra esa diferencia, la persona no dispone de una oportunidad razonable para anticipar la consecuencia.

La interacción humano–máquina no es el intercambio entre una mente y un objeto aislado. Es un acoplamiento: una persona persigue un objetivo, percibe un estado parcial, actúa mediante controles, y el sistema transforma esa acción con reglas, retardos, permisos y automatización. La interfaz —botón, palanca, señal, texto, mapa, sonido o combinación— hace visible una parte de esa relación y deja otras partes implícitas. Un fallo puede nacer de una mala acción, pero también de una acción razonable ante un estado mal mostrado, una correspondencia ambigua o un modo que cambió sin hacerse visible.

El capítulo 338 situó las capacidades dentro del sistema; el 339 trató cuerpo, herramienta y ambiente; el 340 examinó percepción, atención, memoria y carga. Aquí la pregunta dominante es: ¿cómo se diseñan y comprueban controles, pantallas, alarmas y automatismos para que la persona pueda entender qué ocurre, actuar con autoridad suficiente y recuperar el sistema cuando las condiciones dejan de ser normales? Evidencia nombra una observación, registro o resultado de prueba; inferencia, una explicación provisional que conecta evidencias; recomendación, una decisión de diseño u operación que debe justificarse y verificarse. Confundirlas produce pantallas seguras sólo en el papel.

341.1. Correspondencia entre controles, acciones y resultados#

Un control es una vía para cambiar algo: una perilla, un pedal, un deslizador, una orden de voz, un campo de formulario o una opción que autoriza a otro agente a actuar. Su calidad no depende de que sea familiar o elegante, sino de si la persona puede relacionarlo con el resultado que necesita. La correspondencia vincula intención, acción, transformación y consecuencia: «quiero aumentar la temperatura», «giro hacia la marca visible», «el sistema cambia la consigna», «la lectura confirma la nueva condición».

Una correspondencia directa permite actuar sobre el objeto o parámetro que se desea cambiar. Una correspondencia mediada añade menús, permisos, conversiones o cálculos. Ninguna es automáticamente superior. El menú puede evitar que una persona active una función peligrosa por accidente; también puede esconder qué valor está cambiando. La pregunta es qué relación debe poder reconstruir quien actúa, con qué tiempo y con qué posibilidad de deshacer.

El mapeo espacial suele ayudar cuando la disposición de controles conserva la relación espacial de sus efectos: el mando izquierdo cambia el elemento izquierdo y una flecha hacia arriba significa aumentar en el mismo contexto. Pero la semejanza visual no basta. Dos controles contiguos pueden producir resultados muy distintos, una dirección puede invertir su efecto al cambiar de eje y un mismo botón puede actuar sobre el objeto que tiene el foco, no sobre el que parece seleccionado. El foco debe ser visible y el alcance de una orden, explícito.

Escena construida. En una estación de tratamiento, una persona selecciona «válvula 2» en una lista y pulsa «abrir». La pantalla desplaza el foco al siguiente elemento mientras procesa la orden; el segundo toque abre la válvula 3. Si el nombre seleccionado desaparece, el error no es sólo una distracción: la secuencia permite que el control y el objeto de efecto se separen. Una confirmación que repita el objeto, un estado persistente y una orden reversible actúan sobre mecanismos distintos. Añadir una ventana de confirmación para cada operación, en cambio, puede ralentizar respuestas que antes eran seguras.

Un control también comunica posibilidades y límites. Un mando deshabilitado puede significar «no aplicable», «falta permiso», «modo incompatible» o «error de conexión». Un control que parece activo y rechaza la acción obliga a descubrir la regla por ensayo. El diseño debe explicar la causa en el momento en que importa, sin convertir cada excepción en un párrafo. La descripción de la acción, el estado del sistema y la autoridad disponible deben poder separarse: «puedo solicitar», «la máquina está preparada» y «la orden fue ejecutada» son afirmaciones diferentes.

Evidencia. En una prueba, registrar que una persona pulsó el control equivocado demuestra el gesto, no la causa. Hace falta observar qué control creyó haber elegido, qué estado veía, qué resultado esperaba y qué alternativa tenía. Un error repetido ante la misma ambigüedad es evidencia de una confusión previsible del diseño; no demuestra que toda la población actuará igual.

Inferencia. Si la mayoría de participantes interpreta una zona de arrastre como un botón y la respuesta del sistema no deja rastro, es razonable inferir un desajuste entre señal y efecto. Esa inferencia sigue siendo provisional hasta probarla con usuarios distintos, tareas equivalentes y condiciones de tiempo, tamaño y accesibilidad variadas.

Recomendación. Para cada control crítico, documentar el objeto afectado, el rango, la unidad, el modo en que aplica, el tiempo de efecto, la posibilidad de cancelar y la evidencia visible de ejecución. No significa mostrar todas las reglas siempre: significa que ninguna regla decisiva debe depender de adivinación.

341.2. Visibilidad del estado, retroalimentación y modelos mentales#

Una máquina siempre tiene estados aunque la persona no pueda verlos todos: conectada o aislada, lista o ocupada, manual o automática, autorizada o bloqueada, con datos frescos o retrasados. Una pantalla no es un espejo completo; selecciona variables, unidades, escala y momento de actualización. La visibilidad del estado consiste en mostrar lo necesario para que una persona pueda orientar la siguiente acción y detectar que la situación cambió.

La retroalimentación cumple funciones diferentes. Un cambio inmediato tras una acción confirma que el control fue recibido; una lectura estable confirma el nuevo estado; un registro temporal muestra que la transformación ocurrió; una explicación comunica por qué una orden no pudo ejecutarse. «La pantalla cambió» no es una descripción suficiente: el cambio puede ser animación, actualización de datos o indicación de resultado. Cuando el sistema tarda, debe mostrar si está procesando, esperando una dependencia, rechazando la operación o ya terminó.

El modelo mental es la explicación operativa que una persona construye sobre cómo funciona el sistema. No tiene que ser una réplica técnica completa. Debe ser suficientemente correcta para predecir qué efecto tendrá una acción, qué estados son posibles y cómo recuperar. La interfaz puede apoyar ese modelo con relaciones coherentes, nombres estables, unidades y ejemplos; no puede asumir que un icono ambiguo será interpretado de la misma forma por personas con experiencia distinta.

Los modelos se vuelven peligrosos cuando el sistema conserva la apariencia anterior después de un cambio importante. Una pantalla puede seguir mostrando el último valor recibido aunque la conexión se haya perdido; una luz puede quedar encendida porque indica «habilitado» y no «funcionando». El dato tiene entonces una edad y una condición que deben acompañarlo. Ocultar la frescura de una lectura convierte una observación verdadera del pasado en una inferencia falsa sobre el presente.

Escena construida. Un sistema de riego muestra «humedad 42 %» mientras el sensor no transmite desde hace veinte minutos. La cifra puede ser el último dato válido, pero la acción de regar necesita saber si es actual, estimada o desconocida. Una marca de tiempo y un estado de conexión no garantizan una decisión correcta; sí evitan presentar una cifra vieja como medición actual. La persona todavía necesita conocer umbrales, autoridad y consecuencias.

La retroalimentación también debe mostrar el resultado negativo. Un control que no produce efecto puede haber sido ignorado, bloqueado, superado por otra orden o ejecutado fuera de la pantalla. Un mensaje genérico como «error» deja intacta la pregunta operativa. La explicación no tiene que revelar información sensible ni saturar la pantalla; debe decir qué ocurrió, qué no ocurrió y qué acción segura está disponible.

Evidencia. Para evaluar visibilidad, no basta preguntar si la información estaba presente. Hay que registrar si fue encontrada, entendida, relacionada con el estado correcto y usada para anticipar el efecto. Tiempos, omisiones y recuperaciones son indicadores; las entrevistas ayudan a reconstruir el modelo que la persona estaba usando. Ninguno sustituye al otro.

Inferencia. Si una persona puede describir el estado pero no predecir el efecto de una acción, la interfaz quizá presenta datos sin ofrecer una relación causal utilizable. Si predice bien en condiciones normales y falla tras un cambio de modo, la hipótesis se desplaza hacia la visibilidad del modo o de la transición, no hacia una supuesta falta general de conocimiento.

Recomendación. Hacer visibles el estado operativo, la vigencia del dato, la operación en curso, el resultado de la última orden y la condición que limita una acción. Mantener los nombres y unidades estables, y comprobar con personas si pueden anticipar y explicar cambios, no sólo si localizan una etiqueta.

341.3. Señalización, códigos, compatibilidad y confusiones previsibles#

Señalizar es establecer diferencias que guíen percepción e interpretación: palabras, posición, tamaño, textura, forma, color, sonido, vibración o redundancia entre canales. Un código no es universal por naturaleza. Una convención aprendida puede ser muy eficaz dentro de un dominio y confusa para quien llega sin esa formación. La compatibilidad entre señal, acción y propósito importa más que decorar una interfaz con símbolos conocidos.

El color puede distinguir categorías, pero no debe ser el único portador de un estado crítico. Contraste, forma, texto, posición y patrón pueden ofrecer rutas redundantes. La accesibilidad no consiste en añadir una versión especial después: una señal que sólo funciona para una visión, audición, lengua o motricidad concreta distribuye el riesgo de manera desigual. WCAG 2.2 ofrece criterios para contenido web; no reemplaza pruebas con el dispositivo, la tarea y el ambiente reales.

Las etiquetas deben nombrar acción y objeto con precisión. «Aceptar» puede confirmar una selección, enviar datos, cerrar una incidencia o autorizar una compra. «Restablecer» puede borrar la vista, devolver un parámetro o iniciar una secuencia. Una etiqueta corta no es necesariamente clara. La compatibilidad con expectativas previas ayuda sólo si el contexto mantiene la misma regla; el diseño debe advertir cuando una convención deja de aplicar.

Las confusiones previsibles son relaciones entre estímulos, tareas y decisiones. Dos indicadores casi iguales pueden confundirse bajo presión; dos botones próximos pueden intercambiarse; una alarma sonora continua puede no distinguir si la condición persiste o si se repite; una flecha puede representar dirección física en una pantalla y tendencia estadística en otra. El objetivo no es eliminar toda posibilidad de error —imposible—, sino evitar que una confusión razonable produzca un efecto oculto o difícil de recuperar.

Un código también tiene una política de cambio. Si el diseño cambia el significado de un color, el tamaño de un control o la ubicación de una función, la formación no puede ser la única barrera. La transición debe mostrar la diferencia, conservar atajos seguros cuando sea posible y comprobar que la persona reconoce el nuevo código. La consistencia no significa congelar un diseño defectuoso; significa hacer explícito cuándo y por qué se modifica.

Evidencia. Un estudio de legibilidad o contraste demuestra una propiedad de presentación bajo sus condiciones, no que una señal sea comprendida en el trabajo real. Una simulación con participantes que no representan idiomas, edades, capacidades o experiencia puede subestimar la confusión. Conviene registrar interpretaciones, no sólo preferencias: «me gusta el icono» no equivale a «predije correctamente su efecto».

Inferencia. Cuando una señal funciona en una demostración aislada y falla durante una tarea con interrupciones, puede inferirse una interacción entre código, carga y contexto. No se sigue que haya que añadir más señales: la redundancia mal coordinada puede aumentar la competencia entre avisos.

Recomendación. Diseñar códigos con diferencias perceptibles y semánticas, indicar unidades y estados, no depender sólo del color o del sonido, y probar cambios de convención. Las señales críticas deben indicar qué pasó, qué está ocurriendo y qué respuesta es posible.

341.4. Prioridad, frecuencia y saturación de alarmas#

Una notificación informa de un evento; una alarma reclama atención porque una condición requiere evaluación o acción dentro de un contexto definido. No todo cambio debe alarmar. Si cada umbral, variación o fallo produce una señal urgente, el sistema convierte la atención en una cola indistinguible. Si pocas señales se reservan para condiciones accionables, cada una puede sostener una respuesta más clara. La prioridad debe expresar consecuencia y tiempo disponible, no sólo la gravedad imaginada por quien configuró el sistema.

La gestión de alarmas es un ciclo, no una paleta de colores. La serie ISA-18 describe actividades de filosofía, identificación, racionalización, diseño, implementación, operación, mantenimiento y gestión del cambio para sistemas de alarmas en industrias de proceso. Su alcance no convierte sus criterios en una receta para todo producto, pero sí muestra por qué una alarma necesita propietario, propósito, prioridad, respuesta esperada y revisión a lo largo de su vida.

Hay que distinguir reconocer, silenciar, resolver y cerrar. Un clic puede registrar que alguien vio el aviso sin corregir la condición. Si silenciar elimina también el estado persistente, la interfaz oculta una tarea pendiente. Si la alarma reaparece sin explicar por qué, puede producir ciclos de confirmación mecánica. Un historial que conserva hora, causa, cambios y respuesta ayuda a reconstruir qué se supo y cuándo, siempre que el registro sea legible y esté sincronizado.

La frecuencia cambia el significado. Una alarma rara puede requerir orientación y práctica; una alarma repetida puede ser una señal de proceso inestable, de umbral mal elegido o de un sensor defectuoso. Las alarmas molestas enseñan que responder no es necesario; las alarmas ocultas dejan a la persona sin oportunidad. Un aluvión de alarmas durante un incidente no demuestra por sí solo que el operador haya fallado: puede indicar causas comunes, prioridades mal diferenciadas o una interfaz que no ayuda a ordenar la secuencia.

Escena construida. En una planta, una pérdida de presión genera nueve mensajes derivados. Si todos parpadean con el mismo tono, la persona debe descubrir la causa primaria mientras atiende efectos. Agrupar eventos puede ayudar, pero agrupar no debe borrar señales independientes ni imponer una explicación no comprobada. La prueba debe preguntar si se identificó la causa, si se eligió una respuesta, qué se hizo con los avisos secundarios y cómo se supo que la condición estaba resuelta.

Evidencia. Contar alarmas por hora describe frecuencia, no eficacia. Conviene registrar proporción de avisos accionables, tiempo hasta la respuesta, omisiones, reconocimientos sin resolución, alarmas repetidas y comportamiento en estados normales y anormales. Los datos de uso permiten localizar saturación; no establecen por sí solos la prioridad adecuada ni la causa de una respuesta.

Inferencia. Un aumento de reconocimientos rápidos junto con respuestas tardías puede sugerir que el sistema permite acallar más fácilmente que comprender. Es una hipótesis para investigar con observación, entrevistas y trazas, no una prueba de indiferencia. Una disminución de alarmas después de elevar umbrales puede significar menos ruido o una condición peligrosa que dejó de anunciarse.

Recomendación. Definir para cada alarma la condición, el riesgo, la respuesta, el tiempo, la prioridad y el responsable de revisar su desempeño. Separar visualmente urgencia, estado y recomendación; conservar el aviso hasta que la condición se resuelva; y probar el sistema con múltiples eventos simultáneos, no sólo con alarmas aisladas.

341.5. Automatización, supervisión, confianza y conciencia situacional#

Automatizar es asignar a un sistema parte de la adquisición de información, análisis, decisión o acción. La taxonomía de Parasuraman, Sheridan y Wickens ayuda a separar esas funciones: una máquina puede filtrar datos, recomendar una opción, elegir por una regla o ejecutar una orden. Decir «está automatizado» oculta qué parte se delegó, qué información se conserva, cuándo puede intervenir una persona y qué ocurre si la automatización es incierta.

La supervisión no es mirar una pantalla esperando que la máquina falle. Para supervisar, la persona necesita conocer el objetivo, el estado, la base de la recomendación, los límites de validez y la forma de tomar el control. Automatizar tareas frecuentes puede liberar tiempo; también puede dejar a la persona sólo las excepciones raras, complejas y poco practicadas. Esa es una de las «ironías» descritas por Bainbridge: retirar la práctica rutinaria no elimina la responsabilidad humana cuando llega el caso anormal.

La confianza no es sinónimo de agrado ni de obediencia. Lee y See la relacionan con la dependencia apropiada de una automatización según su capacidad, contexto y señales de desempeño. La confianza excesiva produce aceptación sin comprobación; la insuficiente lleva a ignorar ayudas útiles. La interfaz debe sostener una confianza calibrada mostrando incertidumbre relevante, calidad de datos, cambios de modo, límites y resultados, sin fingir una precisión que el sistema no tiene.

La autoridad debe ser concreta. «Humano en el circuito» no dice quién puede detener, aprobar, modificar o revertir una acción, ni cuánto tiempo tiene para hacerlo. Una automatización que requiere confirmación puede desplazar la responsabilidad sin conceder información suficiente; una que actúa sin aviso puede convertir la intervención en una carrera imposible. La asignación adecuada depende de consecuencias, reversibilidad, velocidad del proceso, competencia disponible y posibilidad de relevo.

La conciencia situacional no es estar atento a todo. El modelo de Endsley distingue percibir elementos, comprender su significado y proyectar su evolución. Una automatización puede ayudar a integrar datos y a la vez ocultar señales que sostienen el modelo de la situación. Mostrar una recomendación final sin su estado de origen puede acelerar una operación normal y dificultar el diagnóstico cuando la recomendación cambia o falla.

Escena construida. Un sistema de clasificación marca automáticamente solicitudes como «urgentes». La persona revisa una muestra durante semanas sin ver falsos negativos y aprende a aceptar la etiqueta. Un cambio en los datos altera el patrón; la interfaz conserva el mismo aspecto y no informa del cambio de calidad. La solución no es exigir que se revise todo como si nada estuviera automatizado. Es hacer visible el alcance, ofrecer ejemplos de desacuerdo, registrar la intervención y definir cuándo la persona debe ampliar la revisión.

Evidencia. La tasa de aceptación de recomendaciones no mide por sí sola confianza adecuada. Hay que comparar decisiones con y sin automatización, calidad de las entradas, desacuerdos, detección de fallos, tiempo de intervención y recuperación. Una persona puede rechazar una recomendación correcta porque el sistema no explica su base; otra puede aceptar una incorrecta porque las señales de confianza están sobrerrepresentadas.

Inferencia. Si la detección de fallos empeora cuando la automatización funciona bien durante mucho tiempo, es razonable investigar pérdida de práctica, cambios en vigilancia y visibilidad de límites. No es prueba suficiente para retirar el automatismo: hay que comparar entrenamiento, frecuencia de excepciones y medios de apoyo.

Recomendación. Diseñar la automatización con función, nivel, autoridad, límites y transición explícitos. Mostrar qué hizo el sistema, con qué datos y qué puede hacer la persona; practicar desacuerdos y fallos; y medir dependencia apropiada, no sólo velocidad en el caso normal.

341.6. Modos degradados, intervención humana y recuperación manual#

Un modo es una configuración que cambia la interpretación de controles, datos o autoridad. Manual, automático, mantenimiento, entrenamiento, remoto y degradado no son sólo etiquetas de color: son conjuntos de reglas. El problema aparece cuando una acción válida en un modo produce otro efecto en el siguiente y la transición no se anuncia, cuando dos pantallas muestran el mismo control con alcances distintos o cuando el sistema entra en un modo degradado sin hacer visible qué funciones se perdieron.

El cambio de modo debe tener causa, alcance y confirmación. Una transición puede ser solicitada por una persona, iniciada por una regla, provocada por una pérdida de comunicación o realizada por otra instancia. La pantalla debe mostrar el modo actual, la razón o condición relevante, las funciones disponibles y las restricciones. Una alarma de «modo degradado» que no dice qué debe hacerse informa del problema pero no ayuda a gobernarlo.

La degradación no significa que todo se detenga. Un diseño tolerante puede conservar una función segura, limitar velocidad, aislar un componente o pasar a una operación manual con menos capacidad. Degradación segura no es una propiedad absoluta: depende del objetivo, de quién está presente, del tiempo y de las consecuencias. Un estado que protege el equipo puede dejar a una persona sin agua, movilidad, comunicación o información; el análisis debe incluir a quienes reciben el servicio y no sólo a quien opera.

La intervención manual requiere más que un botón de «override». Debe indicar qué control asume autoridad, qué acciones automáticas quedan canceladas, qué estado inicial encuentra la persona y cómo se evita una orden simultánea. Si el sistema conserva una cola o retoma el control al cabo de un tiempo, esa condición debe ser visible. La persona que interviene necesita práctica en la excepción, no sólo una instrucción de emergencia que nunca se ha ensayado.

La recuperación es una secuencia: reconocer la condición, estabilizar, diagnosticar con información disponible, elegir una acción, comprobar el efecto y devolver o no el sistema a un modo normal. Puede ser preferible mantener un modo degradado conocido a reiniciar sin saber qué estados persistieron. Un botón de reinicio no es una estrategia de recuperación si borra trazabilidad, repite una orden o deja un actuador en una posición inesperada.

Escena construida. Un ascensor pierde comunicación con el sistema central y permite operación local limitada. El panel muestra «modo local», pero no indica qué pisos están disponibles ni si una orden remota pendiente se ejecutará después. La intervención segura exige que el modo sea persistente, que la lista de funciones cambie explícitamente, que el usuario pueda pedir ayuda y que una prueba de retorno confirme el estado. El caso no se resuelve con una alarma sonora continua.

Evidencia. Un protocolo de recuperación describe pasos prescritos; una prueba representativa muestra si las personas pueden localizar el modo, entender la limitación y actuar con el tiempo disponible. Registrar sólo el tiempo hasta pulsar «reinicio» confunde velocidad con recuperación. Hay que anotar qué se entendió, qué estado se preservó, qué errores fueron reversibles y qué ayuda fue necesaria.

Inferencia. Si las personas buscan un control manual sólo después de varios intentos automáticos, puede inferirse que la autoridad y el umbral de intervención no son visibles. También puede intervenir una política que desalienta tomar el control. Para distinguir diseño, formación y organización hay que observar condiciones comparables y escuchar las razones de la demora.

Recomendación. Tratar cada modo como una configuración que merece nombre, límites, transición, autoridad y procedimiento de retorno. Proteger una base de operación segura, conservar registros, permitir una intervención comprensible y ensayar fallos combinados: pérdida de energía, datos atrasados, alarmas simultáneas y cambio de operador.

341.7. Pruebas con personas en condiciones representativas#

Probar una interfaz no es pedir a alguien que confirme si «se ve bien». Es observar si personas que realizarán la actividad pueden construir una interpretación suficiente, actuar sobre el estado correcto, reconocer límites, responder a alarmas, supervisar automatización y recuperar después de una perturbación. Una prueba de laboratorio controlada puede aislar un mecanismo; no sustituye la variación del trabajo real.

La muestra debe representar funciones, experiencia, idiomas, capacidades sensoriales y motoras, edad cuando sea pertinente, y exposición a los modos que se van a usar. No basta incluir usuarios finales en una demostración amable si quien opera en la práctica trabaja con ruido, guantes, interrupciones, baja conectividad, iluminación cambiante o presión temporal. Las condiciones no deben ponerse en riesgo: se pueden usar simulaciones, escenarios instrumentados y fallos controlados que preserven seguridad y consentimiento.

Un plan de prueba comienza con tareas y criterios, no con preferencias. Para el caso normal: ¿se identifica el objeto, se elige el control y se confirma el resultado? Para la excepción: ¿se distingue una alarma accionable de un estado informativo? Para la automatización: ¿se detecta un desacuerdo y se sabe cuándo intervenir? Para la recuperación: ¿se localiza el modo, se conserva el estado y se verifica el retorno? Los criterios pueden incluir aciertos, omisiones, falsas alarmas, tiempo, acciones innecesarias, comprensión explicada, carga, accesibilidad y capacidad de recuperación.

La prueba debe comparar condiciones. Una interfaz nueva frente a la anterior, una señal redundante frente a una única, una automatización visible frente a otra opaca, o un modo anunciado frente a uno no anunciado. La comparación no convierte un resultado en ley universal: ayuda a atribuir un cambio a una intervención. Conviene registrar también cuándo las personas piden ayuda, qué estrategia inventan y qué compensaciones hacen; una tarea que sólo sale adelante con atajos frágiles no está validada.

La evidencia cualitativa importa. Que una persona diga «creí que ya estaba guardado» revela una expectativa; que señale el valor correcto pero actúe sobre otro revela una separación entre percepción y control; que no pueda explicar por qué la automatización cambió indica un problema de modelo o de visibilidad. Estas frases son datos para generar hipótesis, no testimonios aislados que sustituyan medidas.

Evidencia. Un resultado de prueba es válido para las tareas, participantes y condiciones descritas. Debe documentar versión del sistema, configuración, fallos inyectados, entrenamiento, criterios, exclusiones y cambios realizados después. Una mejora posterior a la prueba no puede atribuirse a la primera versión sin conservar la comparación.

Inferencia. Si el desempeño empeora sólo cuando se combinan modo degradado y presión temporal, la causa puede estar en la interacción entre estado, carga y procedimiento. No es prudente atribuirlo a «usuarios poco cuidadosos» ni a «interfaz mala» sin variar una condición a la vez cuando sea posible y examinar qué representación faltó.

Recomendación. Integrar pruebas formativas desde las primeras versiones y evaluaciones de aceptación antes del despliegue; repetirlas tras cambios de código, modo, alarmas o automatización; incluir accesibilidad y recuperación; y publicar las limitaciones conocidas. Validar no significa obtener un sello final, sino mantener evidencia mientras cambian personas, tareas y dependencias.

Preguntas de transferencia#

El mismo botón cambia de efecto después de una actualización. ¿Es un error de la persona?#

Una sala recibe muchas alarmas y el equipo las reconoce casi todas. ¿El sistema funciona?#

Un clasificador automático acierta con frecuencia y el personal deja de revisar sus recomendaciones. ¿Hay que quitarlo?#

El sistema entra en modo degradado y una persona pulsa «reiniciar». ¿Se recuperó?#

Fuentes y lecturas del capítulo#

Las escenas de la estación de tratamiento, riego, planta, clasificación y ascensor son ejemplos construidos. Las fuentes sostienen conceptos y límites de diseño; ninguna referencia permite inferir por sí sola el desempeño de una interfaz concreta.

• International Organization for Standardization. ISO 9241-110:2020, Ergonomics of human-system interaction — Part 110: Interaction principles. Principios generales para analizar, diseñar y evaluar sistemas interactivos; su aplicación depende de propósito, usuarios, tareas, ambiente y consecuencias.
• International Organization for Standardization. ISO 9241-112:2025, Ergonomics of human-system interaction — Part 112: Principles for the presentation of information. Principios para presentar información, incluidos organización, significado y accesibilidad contextual; no sustituye pruebas con el sistema real.
• Parasuraman, Raja; Sheridan, Thomas B.; Wickens, Christopher D. “A model for types and levels of human interaction with automation”. IEEE Transactions on Systems, Man, and Cybernetics—Part A, 30(3), 286–297 (2000). DOI: 10.1109/3468.844354. Distingue funciones de automatización y niveles de interacción.
• Lee, John D.; See, Katrina A. “Trust in Automation: Designing for Appropriate Reliance”. Human Factors, 46(1), 50–80 (2004). DOI: 10.1518/hfes.46.1.50_30392. Marco para relacionar confianza, desempeño, contexto y dependencia apropiada.
• Endsley, Mica R. “Toward a Theory of Situation Awareness in Dynamic Systems”. Human Factors, 37(1), 32–64 (1995). Modelo de percepción, comprensión y proyección en sistemas dinámicos.
• Bainbridge, Lisanne. “Ironies of Automation”. Automatica, 19(6), 775–779 (1983). DOI: 10.1016/0005-1098(83)90046-8. Análisis clásico de la redistribución de trabajo y responsabilidad cuando se automatizan tareas rutinarias.
• International Society of Automation. ISA-18 Series of Standards. Serie sobre ciclo de vida, prioridad, diseño, operación y mantenimiento de sistemas de alarmas en industrias de proceso.
• Sarter, Nadine B.; Woods, David D. “Team Play with a Powerful and Independent Agent: Operational Experiences and Automation Surprises on the Airbus A-320”. Human Factors, 39(4), 553–569 (1997). DOI: 10.1518/001872097778667997. Análisis de conciencia de modo y sorpresas producidas por acciones o estados de automatización no anticipados.
• World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2. Criterios técnicos de accesibilidad para contenido web; se cita como referencia de principios, no como certificación de una máquina física.
• International Organization for Standardization. ISO 14971:2019, Medical devices — Application of risk management to medical devices. Gestión de riesgos para dispositivos médicos, incluida identificación de peligros, controles y evaluación a lo largo del ciclo de vida; su dominio no se generaliza sin análisis.

Bibliografía de la parte XXXI · Bibliografía general

Última revisión editorial

3 de octubre de 2026

Cierre de contenidos

3 de octubre de 2026