La progettazione dei display marini per imbarcazioni reali parte dalla plancia, non da uno strumento di design. Una barca in planata ad alta velocità non si comporta come un ambiente di laboratorio stabile. A quaranta nodi lo scafo impatta duramente sulle onde, le vibrazioni rendono difficile il controllo fine e l’operatore si sostiene con entrambi i piedi. Le mani con i guanti colpiscono lo schermo con meno precisione e spruzzi o pioggia colpiscono spesso il vetro.

La visibilità è un altro vincolo. I display devono rimanere leggibili sotto il sole intenso, con forte copertura nuvolosa e in condizioni notturne, inclusi i modi night vision militari. Abbiamo lavorato con LCD leggibili alla luce del sole e considerato luminosità, contrasto e uso del colore, invece di basarci su presupposti tipici degli schermi da ufficio.

I dati arrivano tramite NMEA 2000 e protocolli motore correlati. La telemetria di ciascun motore include giri, temperatura del liquido di raffreddamento, pressione dell’olio, consumo di carburante e trim, con frequenze di aggiornamento che variano in base alle condizioni. Ad alto carico cambiano sia la frequenza sia l’importanza di questi valori. L’interfaccia deve aiutare gli operatori a individuare ciò che conta senza dover controllare ogni singolo numero.

Durante tutto il progetto abbiamo applicato principi di human factors come touch target generosi basati sulla legge di Fitts, una complessità delle scelte contenuta in linea con la legge di Hick e una costante attenzione alla consapevolezza situazionale in mare mosso.

Supportare da uno a sei motori su un unico insieme di display è una sfida centrale nel design delle interfacce per imbarcazioni. Un layout che funziona perfettamente per un solo motore può diventare caotico quando se ne aggiungono altri cinque. Abbiamo iniziato definendo l’unità informativa di base, l’engine tile, che contiene la telemetria principale di un singolo motore.

Per un singolo motore, il display principale può mostrare una grande tile ricca di dettagli, circondata da dati di supporto. Per quattro o sei motori, lo stesso concetto di tile si ripete in una griglia, con valori secondari semplificati e allarmi gestiti in una barra condivisa. Una vista di dettaglio separata offre maggiore profondità quando l’operatore ne ha bisogno. Questo crea un modello mentale coerente attraverso tension-driven reasoning. L’operatore cerca sempre gli stessi schemi negli stessi punti, indipendentemente dalla configurazione.

Abbiamo verificato ogni layout rispetto ai segnali reali del motore. Ad esempio, durante una corsa ad alta velocità una vista si concentra su giri, temperatura del liquido di raffreddamento e pressione dell’olio con soglie di allarme chiare. Durante l’attracco o le manovre a bassa velocità, trim e stato della marcia acquisiscono maggiore rilevanza visiva. L’architettura ha permesso questi cambi di enfasi senza compromettere la struttura complessiva.

COX aveva bisogno che il sistema funzionasse su tre principali famiglie di display, da uno schermo ausiliario compatto a un grande display di plancia principale con controlli touch e fisici. Invece di progettare pagine fisse, abbiamo definito un insieme di moduli riutilizzabili. Questi includevano engine tile, blocchi carburante complessivi, banner di allarme, barre di stato e pannelli di contesto.

Ogni modulo aveva regole chiare per contenuto, dimensione minima e comportamento. Su uno schermo piccolo alcuni moduli si comprimono o alternano tra panoramica e dettaglio. Su schermi più grandi, più moduli si combinano in una vista più completa. Poiché i moduli condividono proporzioni e comportamenti, l’intera famiglia risulta coerente anche quando le installazioni sono diverse.

Questo approccio modulare ha creato anche valore di business. L’ingegneria può aggiungere una nuova variante di motore o una diversa dimensione di display riutilizzando gli stessi moduli, invece di commissionare un’interfaccia completamente nuova. I distributori possono configurare le viste per diversi segmenti di clienti senza compromettere il Design System. Per COX questo ha ridotto l’impegno di manutenzione a lungo termine e reso più flessibile la pianificazione dei prodotti futuri. È un esempio di rugged UI design che rispetta sia i limiti hardware sia la strategia di prodotto.

Le decisioni di interfaccia per l’UX dell’elettronica marina devono essere testate in condizioni che rispecchino l’uso reale. Insieme a COX abbiamo costruito un ambiente di simulazione che riproduceva dati motore rappresentativi e stati dell’imbarcazione. Operatori esperti ed esperti interni hanno affrontato scenari chiave come i controlli di avviamento, la navigazione veloce in mare mosso, i guasti ad alta velocità e il rientro in porto.

Uno scenario si concentrava su un guasto multi-motore ad alta velocità. I layout iniziali rendevano facile vedere che c’era un problema, ma non quale motore richiedesse attenzione per primo. Abbiamo quindi modificato il modo in cui gli engine tile evidenziano gli stati di allarme e creato un’area fissa sul display in cui il guasto più critico viene sempre riassunto. Un altro scenario ha rivelato che alcune scelte cromatiche notturne interferivano con le apparecchiature di visione notturna, quindi abbiamo regolato la palette e il contrasto.

Queste sessioni non hanno prodotto storie drammatiche, ma hanno generato un flusso costante di perfezionamenti specifici attraverso la lateral exploration. Il risultato è stato un insieme di layout che avevamo visto funzionare sotto una pressione di attenzione realistica, non solo in tranquille sale riunioni.

Una volta stabilizzate l’architettura dei layout e i moduli, siamo passati alla formalizzazione del Design System per l’ingegneria. Abbiamo documentato ogni modulo, il suo comportamento di interazione, gli intervalli di dati ammessi e l’aspetto nei diversi modi come giorno, crepuscolo e notte. Il sistema includeva librerie di componenti, regole di layout e token di colore e tipografia mappabili direttamente nel codice.

La consegna non è stata un semplice trasferimento di documenti. Abbiamo tenuto sessioni congiunte con sviluppatori software e ingegneri hardware per esaminare la struttura e rispondere a domande dettagliate durante Implementation Partnership. Questo ha ridotto le ambiguità ed evitato reinterpretazioni successive dell’intento di design. Il risultato è stato un sistema realmente implementabile, non solo un insieme di visual accattivanti ma vaghi.

Per COX questo si adattava al modo di lavorare dei loro team. Hanno mantenuto un riferimento chiaro e condiviso per lo sviluppo futuro, e il nostro ruolo come società di design per sistemi embedded è stato quello di lasciare un framework che l’ingegneria potesse estendere con sicurezza.