Designing marine display design for real vessels starts from the helm, not from a design tool. A planing boat at speed does not behave like a stable lab environment. At forty knots the hull slams, vibration makes fine control difficult and the operator braces with both feet. Gloved hands land less precisely on the screen and spray or rain often hits the glass.

Visibility is another constraint. Displays must remain readable in bright sun, in heavy overcast and in night conditions including military night vision modes. We worked with sunlight readable LCDs and considered brightness, contrast and colour use rather than relying on office screen assumptions.

Data arrives through NMEA 2000 and related engine protocols. Telemetry for each engine includes rpm, coolant temperature, oil pressure, fuel rate and trim, with update rates that vary by condition. At high load the frequency and importance of these values change. The interface must help operators notice what matters without scanning every number.

Throughout we used human factors principles such as generous touch targets informed by Fitts law, restrained choice complexity in line with Hick law and a constant focus on situational awareness in rough water.

Supporting from one to six engines on a single set of displays is a central challenge in boat interface design. A layout that works beautifully for a single engine can collapse into clutter when there are five more. We began by defining the core unit of information, the engine tile, which carries the key telemetry for a single engine.

For a single engine the main display can show one large tile with rich detail, surrounded by supporting data. For four or six engines the same tile concept repeats in a grid, but with secondary values simplified and alarms handled in a shared strip. A separate detail view provides depth when the operator needs it. This gives a consistent mental model through tension-driven reasoning. The operator always looks for the same patterns in the same places, regardless of configuration.

We checked every layout against real engine signals. For example, during a high speed run one view focuses on rpm, coolant temperature and oil pressure with clear alarm thresholds. During docking or low speed manoeuvres trim and gear state gain visual prominence. The architecture allowed these emphasis shifts without breaking the overall structure.

COX needed the system to work across three main display families, from a compact auxiliary screen to a large primary helm display with touch and physical controls. Instead of designing fixed pages, we defined a set of reusable modules. These included engine tiles, overall fuel blocks, alarm banners, status bars and context panels.

Each module had clear rules for content, minimal size and behaviour. On a small display some modules compress or rotate between overview and detail. On larger displays several modules combine into a more comprehensive view. Because the modules share proportions and behaviour, the family feels coherent even when installations differ.

This modular approach also created business value. Engineering can add a new engine variant or display size by reusing the same modules instead of commissioning a fresh interface. Distributors can configure views for different customer segments without breaking the design system. For COX this reduced long term maintenance effort and made future product planning more flexible. It is an example of rugged UI design that respects both hardware limits and product strategy.

Interface decisions for marine electronics UX must be tested in conditions that resemble real use. Together with COX we built a simulator environment that replayed representative engine data and vessel states. Experienced operators and internal experts walked through key scenarios such as start up checks, fast transit in chop, fault during high speed and return to harbour.

One scenario focused on a multi engine fault at speed. Early layouts made it too easy to see that something was wrong but not which engine needed attention first. In response we changed how engine tiles highlight alarm states and created a consistent area on the display where the most critical fault is always summarised. Another scenario revealed that some night colour choices interfered with night vision equipment, so we adjusted the palette and contrast.

These sessions did not produce dramatic stories, but they generated a steady stream of specific refinements through lateral exploration. The result was a set of layouts that we had seen perform under realistic attention pressure, not only in quiet meeting rooms.

Once the layout architecture and modules were stable we moved into formalising the design system for engineering. We documented each module, its interaction behaviour, admissible data ranges and appearance in different modes such as day, dusk and night. The system included component libraries, layout rules and colour and typography tokens that could be mapped into code.

Handover was not a single document transfer. We held joint sessions with software developers and hardware engineers to walk through the structure and answer detailed questions during Implementation Partnership. This reduced ambiguity and avoided later reinterpretation of design intent. The result was an implementable system rather than a beautiful but vague set of visuals.

For COX this fit the way their teams work. They retained a clear, shared reference for future development, and our role as an embedded system design firm was to leave behind a framework that engineering can extend confidently.