El diseño de pantallas marinas para embarcaciones reales comienza en el puesto de mando, no en una herramienta de diseño. Una lancha en planeo a alta velocidad no se comporta como un entorno de laboratorio estable. A cuarenta nudos, el casco golpea con fuerza, las vibraciones dificultan el control preciso y el operador se apoya con ambos pies. Las manos con guantes tocan la pantalla con menos precisión, y las salpicaduras o la lluvia a menudo golpean el cristal.

La visibilidad es otra limitación. Las pantallas deben seguir siendo legibles a pleno sol, con nubosidad intensa y en condiciones nocturnas, incluidos los modos night vision militares. Trabajamos con pantallas LCD legibles a la luz del sol y tuvimos en cuenta el brillo, el contraste y el uso del color, en lugar de basarnos en suposiciones propias de pantallas de oficina.

Los datos llegan a través de NMEA 2000 y protocolos de motor relacionados. La telemetría de cada motor incluye rpm, temperatura del refrigerante, presión de aceite, consumo de combustible y trim, con frecuencias de actualización que varían según las condiciones. A alta carga, cambian tanto la frecuencia como la importancia de estos valores. La interfaz debe ayudar a los operadores a notar lo que importa sin tener que revisar cada número.

A lo largo de todo el proyecto aplicamos principios de human factors como touch targets generosos basados en la ley de Fitts, una complejidad de elección contenida conforme a la ley de Hick y un enfoque constante en la conciencia situacional en aguas agitadas.

Dar soporte de uno a seis motores en un mismo conjunto de pantallas es un desafío central en el diseño de interfaces para embarcaciones. Un diseño que funciona perfectamente para un solo motor puede volverse desordenado cuando se añaden cinco más. Comenzamos definiendo la unidad básica de información, el engine tile, que contiene la telemetría clave de un solo motor.

Para un solo motor, la pantalla principal puede mostrar una gran tile con mucho detalle, rodeada de datos de apoyo. Para cuatro o seis motores, el mismo concepto de tile se repite en una cuadrícula, con valores secundarios simplificados y las alarmas gestionadas en una franja compartida. Una vista de detalle independiente aporta mayor profundidad cuando el operador lo necesita. Esto crea un modelo mental coherente mediante tension-driven reasoning. El operador siempre busca los mismos patrones en los mismos lugares, independientemente de la configuración.

Comprobamos cada diseño con señales reales del motor. Por ejemplo, durante una navegación a alta velocidad, una vista se centra en las rpm, la temperatura del refrigerante y la presión de aceite con umbrales de alarma claros. Durante el atraque o las maniobras a baja velocidad, el trim y el estado de la marcha ganan protagonismo visual. La arquitectura permitió estos cambios de énfasis sin romper la estructura general.

COX necesitaba que el sistema funcionara en tres familias principales de pantallas, desde una pantalla auxiliar compacta hasta una gran pantalla principal de la consola con controles táctiles y físicos. En lugar de diseñar páginas fijas, definimos un conjunto de módulos reutilizables. Estos incluían engine tiles, bloques de combustible generales, banners de alarma, barras de estado y paneles de contexto.

Cada módulo tenía reglas claras sobre contenido, tamaño mínimo y comportamiento. En una pantalla pequeña, algunos módulos se comprimen o alternan entre vista general y detalle. En pantallas más grandes, varios módulos se combinan en una vista más completa. Como los módulos comparten proporciones y comportamientos, la familia completa se percibe coherente incluso cuando las instalaciones son diferentes.

Este enfoque modular también creó valor empresarial. El equipo de ingeniería puede añadir una nueva variante de motor o un nuevo tamaño de pantalla reutilizando los mismos módulos, en lugar de encargar una interfaz completamente nueva. Los distribuidores pueden configurar vistas para distintos segmentos de clientes sin romper el Design System. Para COX, esto redujo el esfuerzo de mantenimiento a largo plazo y hizo más flexible la planificación de futuros productos. Es un ejemplo de rugged UI design que respeta tanto las limitaciones de hardware como la estrategia de producto.

Las decisiones de interfaz para la UX de la electrónica marina deben probarse en condiciones que se asemejen al uso real. Junto con COX construimos un entorno de simulación que reproducía datos representativos del motor y estados de la embarcación. Operadores experimentados y expertos internos recorrieron escenarios clave como las comprobaciones de arranque, la navegación rápida en mar agitado, fallos a alta velocidad y el regreso a puerto.

Un escenario se centró en un fallo de varios motores a alta velocidad. Los primeros diseños facilitaban ver que algo iba mal, pero no qué motor necesitaba atención primero. Por ello, cambiamos la forma en que los engine tiles destacan los estados de alarma y creamos un área fija en la pantalla donde siempre se resume el fallo más crítico. Otro escenario reveló que algunas elecciones de color nocturno interferían con los equipos de visión nocturna, por lo que ajustamos la paleta y el contraste.

Estas sesiones no produjeron historias dramáticas, pero generaron un flujo constante de mejoras concretas mediante lateral exploration. El resultado fue un conjunto de diseños que habíamos visto rendir bajo presión de atención realista, no solo en tranquilas salas de reuniones.

Una vez que la arquitectura de diseño y los módulos fueron estables, pasamos a formalizar el Design System para el equipo de ingeniería. Documentamos cada módulo, su comportamiento de interacción, los rangos de datos permitidos y su apariencia en diferentes modos como día, crepúsculo y noche. El sistema incluía bibliotecas de componentes, reglas de diseño y tokens de color y tipografía que podían mapearse directamente en el código.

La entrega no fue una simple transferencia de documentos. Realizamos sesiones conjuntas con desarrolladores de software e ingenieros de hardware para revisar la estructura y responder a preguntas detalladas durante Implementation Partnership. Esto redujo la ambigüedad y evitó reinterpretaciones posteriores de la intención de diseño. El resultado fue un sistema implementable, no solo un conjunto de visuales atractivos pero imprecisos.

Para COX, esto encajaba con la forma de trabajar de sus equipos. Mantuvieron una referencia clara y compartida para el desarrollo futuro, y nuestro papel como empresa de diseño de sistemas embedded fue dejar un framework que el equipo de ingeniería pueda ampliar con confianza.