La conception d’écrans marins pour de véritables navires commence au poste de pilotage, pas dans un outil de design. Un bateau en déjaugeage à grande vitesse ne se comporte pas comme un environnement de laboratoire stable. À quarante nœuds, la coque frappe violemment, les vibrations rendent les gestes fins difficiles, et l’opérateur se cale sur ses deux jambes. Des mains gantées touchent l’écran avec moins de précision, et les embruns ou la pluie atteignent souvent la surface vitrée.

La visibilité est une autre contrainte. Les écrans doivent rester lisibles en plein soleil, sous une forte couverture nuageuse et dans des conditions nocturnes, y compris avec des modes night vision militaires. Nous avons travaillé avec des écrans LCD lisibles en plein soleil et pris en compte la luminosité, le contraste et l’usage des couleurs, plutôt que de nous appuyer sur des hypothèses issues des écrans de bureau.

Les données arrivent via NMEA 2000 et des protocoles moteur associés. La télémétrie de chaque moteur inclut le régime, la température du liquide de refroidissement, la pression d’huile, la consommation de carburant et le trim, avec des fréquences de mise à jour qui varient selon les conditions. À forte charge, la fréquence et l’importance de ces valeurs changent. L’interface doit aider les opérateurs à repérer ce qui compte sans devoir examiner chaque chiffre.

Tout au long du projet, nous avons appliqué des principes de facteurs humains tels que des zones tactiles généreuses basées sur la loi de Fitts, une complexité de choix maîtrisée conformément à la loi de Hick, et une attention constante portée à la conscience situationnelle en mer agitée.

Prendre en charge de un à six moteurs sur un même ensemble d’écrans constitue un défi central dans la conception d’interfaces pour bateaux. Une mise en page qui fonctionne parfaitement pour un seul moteur peut devenir encombrée lorsqu’on en ajoute cinq de plus. Nous avons commencé par définir l’unité d’information de base, le engine tile, qui regroupe la télémétrie essentielle d’un moteur.

Pour un seul moteur, l’écran principal peut afficher une grande tile riche en détails, entourée de données de soutien. Pour quatre ou six moteurs, le même concept de tile se répète dans une grille, avec des valeurs secondaires simplifiées et des alarmes regroupées dans une bande commune. Une vue de détail séparée apporte de la profondeur lorsque l’opérateur en a besoin. Cela crée un modèle mental cohérent grâce à tension-driven reasoning. L’opérateur recherche toujours les mêmes motifs aux mêmes endroits, quelle que soit la configuration.

Nous avons vérifié chaque mise en page par rapport aux signaux moteur réels. Par exemple, lors d’une navigation à grande vitesse, une vue se concentre sur le régime, la température du liquide de refroidissement et la pression d’huile avec des seuils d’alarme clairs. Lors des manœuvres d’accostage ou à basse vitesse, le trim et l’état de la boîte de vitesses gagnent en importance visuelle. L’architecture permettait ces changements de priorité sans compromettre la structure globale.

COX avait besoin que le système fonctionne sur trois grandes familles d’écrans, d’un écran auxiliaire compact à un grand écran principal de poste de pilotage avec commandes tactiles et physiques. Plutôt que de concevoir des pages fixes, nous avons défini un ensemble de modules réutilisables. Ceux-ci incluaient des engine tiles, des blocs de carburant globaux, des bannières d’alarme, des barres d’état et des panneaux contextuels.

Chaque module disposait de règles claires concernant le contenu, la taille minimale et le comportement. Sur un petit écran, certains modules se compressent ou alternent entre vue d’ensemble et détail. Sur des écrans plus grands, plusieurs modules se combinent pour former une vue plus complète. Comme les modules partagent les mêmes proportions et comportements, l’ensemble reste cohérent, même lorsque les installations diffèrent.

Cette approche modulaire a également créé de la valeur métier. L’ingénierie peut ajouter une nouvelle variante de moteur ou une nouvelle taille d’écran en réutilisant les mêmes modules, au lieu de commander une interface entièrement nouvelle. Les distributeurs peuvent configurer des vues pour différents segments de clients sans compromettre le design system. Pour COX, cela a réduit les efforts de maintenance à long terme et rendu la planification des produits futurs plus flexible. C’est un exemple de rugged UI design qui respecte à la fois les contraintes matérielles et la stratégie produit.

Les décisions d’interface pour l’UX de l’électronique marine doivent être testées dans des conditions proches de l’usage réel. Avec COX, nous avons construit un environnement de simulation rejouant des données moteur représentatives et des états de navigation. Des opérateurs expérimentés et des experts internes ont parcouru des scénarios clés tels que les vérifications de démarrage, la navigation rapide dans la houle, une panne à grande vitesse et le retour au port.

Un scénario portait sur une panne multi-moteurs à grande vitesse. Les premières mises en page permettaient de voir facilement qu’il y avait un problème, mais pas quel moteur devait être traité en priorité. Nous avons donc modifié la façon dont les engine tiles mettent en évidence les états d’alarme et créé une zone dédiée sur l’écran où la panne la plus critique est toujours résumée. Un autre scénario a montré que certains choix de couleurs nocturnes interféraient avec les équipements de vision nocturne, nous avons donc ajusté la palette et le contraste.

Ces sessions n’ont pas produit d’histoires spectaculaires, mais elles ont généré un flux constant d’améliorations concrètes grâce à la lateral exploration. Le résultat a été un ensemble de mises en page que nous avions vues fonctionner sous une pression d’attention réaliste, et pas seulement dans des salles de réunion calmes.

Une fois l’architecture de mise en page et les modules stabilisés, nous sommes passés à la formalisation du design system pour l’ingénierie. Nous avons documenté chaque module, son comportement d’interaction, les plages de données admissibles et son apparence dans différents modes comme le jour, le crépuscule et la nuit. Le système comprenait des bibliothèques de composants, des règles de mise en page ainsi que des tokens de couleur et de typographie pouvant être intégrés dans le code.

La passation n’a pas consisté en un simple transfert de documents. Nous avons organisé des sessions conjointes avec les développeurs logiciels et les ingénieurs matériels pour parcourir la structure et répondre à des questions détaillées pendant Implementation Partnership. Cela a réduit les ambiguïtés et évité toute réinterprétation ultérieure de l’intention de design. Le résultat a été un système réellement implémentable, et non un ensemble de visuels esthétiques mais vagues.

Pour COX, cela correspondait à la façon dont leurs équipes travaillent. Ils ont conservé une référence claire et partagée pour les développements futurs, et notre rôle en tant qu’agence de design pour systèmes embarqués a été de laisser un framework que l’ingénierie peut faire évoluer en toute confiance.