Intuitive HVAC management system for the cruise ship cabins

01 / THE CHALLENGE

Bad UI needs constant training with staff turnover

Datapan builds HVAC systems for cruise ships. UNIapp is the software layer for cabins, reachable from anywhere on board, installed on its first 170-cabin vessel by mid-2022.

The focus: maximum intuitiveness, so that reception needs as little training as possible when staff change.

02 / THE UMUX-LITE TEST

Status labels looked like buttons to users

It was quite obvious to me that users would have a hard time using the system with status labels and buttons looking the same. So we went straight into a redesign, then scheduled interviews and usability tests to check the improvement.

The usability test: 7 participants, thirty minutes each.

“Imagine you are a member of the hotel staff on a cruise ship. An older guest calls reception from cabin 237 and asks for help increasing the temperature in his room, because it is too cold.”

WHAT I WATCHED FOR

• Can they raise the temperature?
• Can they correctly read the states the interface is showing them?
• Can they tell which actions are available to them?
• Can they explain “Basic setpoint” and “Setpoint range +/−” in their own words?

WHAT THE EXISTING INTERFACE DID

• All six tried to click a status indicator as though it were a button — most often the “OFF” chip on the bathroom floor heater.
• One clicked every status square on the screen, because every one of them looked pressable.
• Editing was gated behind a toggle called Remote that two participants never found unaided.
• Five never realised that switching it on also locks the guest out of their own cabin panel.
• Nobody could reliably explain the difference between Actual, Local and Basic setpoint.

03 / THE FORK

UMUX-Lite score: lifted from 70.8 to 92.9

UMUX-Lite is a simplified scoring system to quantify and compare ease of use between two systems — here, the existing UI and the redesign.

Testers rate two statements from 1 (strongly disagree) to 7 (strongly agree): the system's capabilities meet my requirements, and the system is easy to use.

A 2.4-point gap between two prototypes across 7 people is a rounding error, so the choice between the two redesigns came down to preference.

On the redesigns every participant adjusted the temperature immediately, without any status-label clicks.

04 / THE OPERATOR VIEW

What a ventilation officer needs on one screen

1. Occupancy before temperature

   Booked, occupied, key-card and balcony-door state sit above everything — they explain why the cabin is behaving the way it is.

2. Automatic by default

   Modes switch themselves. The operator forces an override only when a guest calls, and the current mode is always named.

3. One number, two buttons

   The setpoint is the biggest thing on the card. Range and boost sit underneath as constraints, not controls to hunt for.

4. Engineering data, kept aside

   Actual vs. local vs. remote setpoints still matter for debugging — so they live in a panel, not in the primary flow.

5. Alarms are a count, not a feed

   Five active alarms is the fact an officer needs at 2am. The list is one tap away.

05 / THE CONTROL PANEL

One number, two buttons

1. The setpoint

   The largest object on the card, with the only two things you can do to it either side. Nothing to enable first.

2. Current state

   The header says what the system is doing right now — heating, cooling, or nothing — beside the actual temperature.

3. The allowed range

   A constraint set by the officer, not a control. How far a guest may move the temperature from their own cabin panel.

4. Boost

   The most confusing element in testing: it boosts heating or cooling depending on what the system is already doing. Two participants did not read it as pressable, so it gained a tooltip.

5. Guest control

   Renamed mid-study — participants read the original “Lock” as “reset the settings”. Everyone after the change read it correctly.

06 / THE AUTOMATION LOGIC

Even a new hire technician can jump right in

1. Documentation in the UI

   The officer would normally open a manual for these settings. The diagram explains middle setpoint, range and offset in place, so the reference lives where the decision is made.

2. One band, three modes

   Middle setpoint and setpoint range are single values shared by every mode — merged cells, not repeated rows. Comfort centres on the band; the saving modes derive from it.

3. Steppers, not text fields

   Every value moves in fixed steps with its unit attached. The hardware has limits, so the interface enforces them — a free-text field invites someone to type 220 instead of 22.

4. A ceiling on Boost

   The longest Boost will run if a cabin never reaches its target. A stuck valve or an open balcony door cannot heat a cabin all night.

5. Nothing auto-applies

   Dismiss and Save are equal width and equally reachable. Leaving the modal changes nothing until the officer says so.

07 / MANAGING THE WHOLE SHIP

One officer, up to 200 cabins, mid-sailing

1. Bulk action bar

   Selecting cabins turns the toolbar into the action — one parameter, one value, applied across everything selected. Apply and Cancel sit on the bar itself, so the scope of a change never leaves the screen.

2. Item selector

   A checkbox per row, and one in the header for the whole vessel. Nothing destructive appears until something is selected.

3. Column visibility

   The table carries more columns than any one shift needs. An eye icon opens the list, with starred columns as a shortcut back to a working set.

4. Search bar

   Cabins are found by name rather than scrolled to. A guest gives reception a cabin number, not a position in a list.

5. Column filters

   Every header sorts and filters in place — booked, occupied, operation mode, temperature out of range.

08 / STANDARDS

Following the OpenBridge standard

openbridge.no

Cruise ship bridges are starting to use OpenBridge, the maritime design standard shared across radar, alarm and machinery systems. Officers recognise the patterns from other bridge systems, and recognition is the cheapest route to confidence.

I used OpenBridge components or patterns where it was sensible.

09 / WHAT WAS NOT IDEAL

Only one true receptionist in the test group

Budget limits meant only one test user was an actual cruise-ship receptionist. We tested with six less tech-savvy Datapan employees who had not yet seen the existing UI or the redesigns.

The one participant with genuine shipboard experience flagged that locking a guest out of their own panel would draw complaints — “I paid to control my own cabin”.