A good HMI screen quickly answers the operator's questions: “What is happening, why is it happening, and what should I do?” Attractive colours or three-dimensional machine drawings can help towards this goal, but they do not provide usability on their own. Particularly during shift changes, faults and product changeovers, the screen's information layout directly affects the quality of the operator's decisions.
011. Structure the screen around the process's decision flow
The main screen's job is not to display every variable. The line status, its bottleneck, the active product and the points requiring operator intervention should be given prominence. On a filling machine, what the operator most often needs to know is the production mode, the target and actual quantities, the product infeed and any condition preventing the cycle.
Details can be moved to a second level, such as a station view, an equipment faceplate and a maintenance page. This hierarchy reduces unnecessary page navigation while making it possible to drill down during a fault. An “everything on one screen” approach should not produce a control room that cannot be read on a small panel.
022. Use colour to show status, not for decoration
If the normal state is very bright, it becomes harder to distinguish an abnormal state. Choose a limited and consistent palette. The same colour should not mean different things on different pages. A motor running should be recognisable not only by the colour green but also by status text or a suitable symbol.
Alarm priorities are also part of this visual language. An information message, a process warning and a fault that stops production should not use the same emphasis. With colour blindness, glare and a dirty screen in mind, cues other than colour are retained. Where possible, the design is tested on the actual panel.
033. Separate commands from feedback
Pressing the “Start” button does not show that the machine has actually started. The command issued on the screen, the PLC's acceptance status and the actual state of the equipment are separate concepts. If a cycle does not start, the operator should be able to see which condition is missing, rather than searching for the cause by repeatedly pressing the button.
| Item | Weak wording | More useful wording |
|---|---|---|
| Status | System not ready | Automatic cycle waiting: no product infeed |
| Alarm | Error 17 | Filling valve position confirmation not received in time |
| Value | Temperature 80 | Zone 2: 80 °C; target 85 °C |
| Connection | Values frozen | PLC connection lost; last data 14:32:10 |
044. An alarm message should explain the next step
An alarm should include the equipment name, the meaning of the event and the condition to be checked. At the same time, the message must not steer the user towards a hazardous intervention. Suggestions that defeat a safety function, such as “bypass the door switch”, must not appear in alarm text.
If a single root cause generates dozens of secondary alarms, improving the wording alone is not enough. The alarm chain, the record of the first event and unnecessary repetitions during normal operation must also be examined. Acknowledging an alarm and clearing the fault are different things; the acknowledge button does not correct the process condition by itself.
055. Numbers, units and trends must speak the same language
The number of decimal places should match the meaningful precision of the measurement. Showing five decimal places in a process controlled to a tenth of a degree creates a perception of precision that does not actually exist. Input fields should show the unit, the permitted range and when the change will take effect.
A trend is not used only to plot history. For example, when investigating a temperature problem, viewing the setpoint, the actual value and the output percentage on the same time axis is far more revealing. The axis range and time window are saved, preventing small fluctuations from looking like major faults because of differing scales.
066. Design permissions and hazardous commands according to context
An operator changing a production parameter and maintenance personnel setting an axis direction are not the same level of authority. For critical settings, roles, limits and an audit trail should be considered. However, adding a confirmation dialog to every touch also leads users to close every dialog without thinking.
Confirmation makes sense for commands with a high impact that are difficult to reverse. On-screen authorisation does not replace the machine's actual safety architecture. Start permissives and safety conditions must not be checked only in the visual interface.
077. Base acceptance testing on the operator's actual tasks
Give an operator tasks such as “change the product, set the filling target, find out why a station is waiting”. Record the completion time, visits to the wrong page and the need for help. A designer using a familiar page quickly does not mean the shift team will use it just as quickly.
In addition to normal production, the tests should include connection loss, unauthorised parameter changes and sensor failure scenarios. The screen fulfils its purpose only if it remains understandable under these conditions. The colour/status glossary and screen architecture are delivered together with the final version, keeping later additions consistent.
08Example verification scenario
For a fault test, the operator can be given the task of finding, from the screen, why the cycle will not start. In a sound design, the expected condition, the actual condition and the relevant station are clearly visible. The number of help windows the operator opens and any incorrect intervention attempts are recorded. The same task is then repeated with a less experienced user. The result is assessed not on the intuition of the person who built the interface, but on how accurately the tasks are completed by the team in the field.
Technical references and further reading
For product- and version-specific values, the relevant manufacturer's current documentation should be taken as the reference. The calculations and scenarios above are engineering examples for illustrative purposes.
