Alarm UI design: separate severity, lifecycle and acknowledgment

Acknowledged does not mean recovered

Acknowledgment usually records that somebody has seen or accepted an event. It does not establish that the equipment has recovered. Turning the entire row green after acknowledgment may lead the next shift to assume the condition has cleared. Conversely, a recovered measurement does not necessarily mean that the required handling record has been completed. Show condition and handling progress separately instead of inferring a physical result from a button click.

Define severity, occurrence, recovery, acknowledgment and closure with the business owner, including which system supplies each fact. A designer should not reduce the displayed severity because the page looks too red. Professional threshold selection and operating procedures are outside a purely visual-design commission.

Use fields that can express combinations

• Severity: the agreed impact level, represented by a meaningful name together with a color or shape.
• Condition: active, recovered, or unknown because the available data cannot establish a result.
• Handling: unacknowledged, accepted, in progress or closed, using the organization’s actual workflow.
• Time and identity: occurrence, latest update and recovery times, plus an identifier that distinguishes similar equipment.

In a hypothetical case, a high-severity event has recovered but has not been acknowledged. The interface should be able to show “high severity / recovered / awaiting acknowledgment” rather than forcing everything into “normal.” This illustrates a design requirement; the available upstream event records must establish whether those states can actually be supplied.

Provide a way to understand the state without color

The WCAG 2.2 explanation of color use states that color must not be the only means of conveying information. A monitoring interface can combine level names, status text and shapes so that grayscale viewing or color-vision differences do not remove the meaning. That principle does not prescribe a particular industrial alarm palette. Applicable operating rules and established shift practices still need to be checked.

Continuous flashing is not a suitable treatment for every event. A newly important event may need attention, while its details need to remain stable enough to read. New-event feedback must not repeatedly interrupt somebody entering a handling record. Give icons understandable names rather than expecting operators to memorize unfamiliar symbols.

Order and actions influence interpretation

A list can prioritize severity and then time, provided the rule is stable and explainable. Rows that move on every refresh can cause an operator to act on the wrong event. Keep the identity of the record being handled clear. A batch acknowledgment must identify the selected events and any items that cannot be acknowledged. “All read” must not be presented as “all resolved.”

Insufficient permission, equipment offline and an unavailable interface need separate explanations. Using the same gray treatment for disabled equipment and missing data leaves users unable to decide what to do. A visible update time helps distinguish a genuine recovery from a state that simply has not been refreshed.

Accept combinations, not just a red-dot screenshot

1. Read combinations such as active high-severity events, unacknowledged low-severity events and recovered events awaiting acknowledgment.
2. Compare normal, grayscale and distant viewing under the intended display conditions.
3. Acknowledge an event and verify that its original level, time and object remain available.
4. Operate on a record while the list refreshes. Confirm that another event moving into the same position is not selected accidentally.
5. Simulate interface failure and insufficient permission. Neither should appear as a normal or closed condition.

If the source provides only one status flag, the design cannot invent a complete event lifecycle. Present the available state and its limitations, then scope additional fields and workflow logic separately. This allows the interface to communicate known information accurately without implying that the underlying system has established something it cannot prove.

Bring the available status fields and acknowledgment rules before choosing colors. Check viewing conditions with the display adaptation guide and existing operating constraints with the software and HMI redesign guide. A brief for UI design (Chinese) should include the event combinations people confuse, so acceptance can test their meaning instead of merely approving a red color.