An HMI is only as usable as its buttons. An operator navigating between displays, opening a faceplate, or acknowledging an alarm does it by pressing on-screen controls, and how those controls are designed and arranged decides whether the interface feels fast and predictable or slow and error-prone. A soft key is one of those on-screen buttons - a defined region of the screen that triggers a navigation move or an action when pressed. This guide explains what soft keys do, how a consistent navigation bar of them ties the display hierarchy together, how they should be sized for real operators, and why navigation must be kept separate from control actions.
Soft key in one line: A soft key is an on-screen button on an HMI that triggers a navigation move or an action when pressed - opening a display, calling up a faceplate, acknowledging an alarm, or paging through a hierarchy. Unlike a fixed physical key, a soft key is drawn in software and its function is defined by the display, and a consistent set of them forms the navigation framework that ties all the operator screens together.
A soft key is simply a button rendered on the screen with a defined action behind it, and its power comes from how flexible that pairing is. The most common action is navigation: pressing a soft key opens another display, jumps up to the home screen, drills down into a unit, or pages to a related view. Because the button is drawn in software rather than wired as a fixed physical key, the same region of the screen can mean different things on different displays, and its label tells the operator what it does right now.
Beyond navigation, soft keys trigger operator actions. A soft key might call up a faceplate to interact with a specific loop, acknowledge an alarm, silence an audible, or open a trend for the value under focus. These are the small, frequent interactions that make up most of an operator's work, and the soft key is the mechanism through which they happen. Grouping and labeling them clearly is what lets an operator work quickly, because the action they want is a single, obvious press away rather than buried in a menu.
The label and behavior of a soft key carry the whole meaning, so both must be unambiguous. A button whose label does not clearly say what it does, or whose function changes unpredictably from screen to screen, is a source of hesitation and error. Good soft key design makes the label match the action exactly and keeps the mapping consistent enough that an operator builds reliable muscle memory, pressing the right place without stopping to read every time.
Individual soft keys become far more powerful when they are organized into a consistent navigation structure, typically a fixed bar of buttons that appears in the same place on every display. When the home button, the alarm-summary button, the paging controls, and the links to the main areas always sit in the same spot with the same labels, the operator learns the layout once and applies it everywhere. Navigation stops being something to think about and becomes automatic, which is exactly what a stressed operator needs during an upset.
This consistent bar is what makes the layered display hierarchy navigable in practice. The hierarchy defines how screens relate - overview down to unit down to loop - but it is the navigation soft keys that let the operator actually move through those relationships: up to the overview, across to a related unit, down into a detail, and back. Without a dependable navigation framework, a well-structured hierarchy is just a set of disconnected screens; with it, the operator can travel the structure fluidly and always knows how to get home.
Consistency also reduces the mental cost of a large display set. A big application might have dozens or hundreds of screens, and no operator can memorize a unique navigation scheme for each. A single, uniform navigation bar collapses that complexity: however deep the operator has drilled, the way back and the way to the other main views is always the same handful of buttons in the same place. The navigation soft keys are, in effect, the connective tissue that turns many separate displays into one coherent interface.
Soft keys have to be usable by real operators in real conditions, which puts a hard floor under how small they can be. On a touchscreen, a button that a gloved operator cannot reliably hit is worse than useless, so navigation and action buttons are sized as generous touch targets with enough separation that an adjacent key is not pressed by mistake. The same logic applies to mouse-driven screens, where small, crowded buttons cause slow, error-prone clicking. Sizing and spacing are not cosmetic - they directly affect how often an operator selects the wrong thing.
The most important design principle around soft keys is separating navigation from control. Opening a display is a harmless, reversible act; issuing a control command - starting a pump, opening a valve, changing a setpoint - is not, and an operator must never trigger a real process action while they believe they are merely navigating. Good design keeps the two visually and behaviorally distinct, places control actions where they cannot be pressed by accident, and applies confirmation to consequential commands so that a genuine control action is deliberate. A layout that mixes an innocuous page button next to a live trip command invites exactly the accidental action that must not happen.
Cloud-based HMIs inherit all of these requirements and add the reality that the same interface may be used on different devices. On a cloud SCADA platform such as Merobix, where operators reach displays through a browser on a control-room screen, a tablet, or a phone, soft keys must remain reliably sized and consistently placed across those form factors so navigation feels the same everywhere and touch targets stay large enough to hit. The separation of navigation from control matters even more when access is remote and varied, so consequential commands are protected by confirmation and kept clearly distinct from the navigation buttons an operator taps constantly, ensuring that moving between displays can never be confused with acting on the process.
A physical key is a fixed button wired to a set function, while a soft key is drawn in software and its function is defined by the current display, so the same screen region can mean different things on different screens. This flexibility lets a soft key be labeled for exactly what it does at that moment, which is why modern touchscreen HMIs rely on soft keys for most navigation and actions.
Large enough to be reliably pressed by a gloved operator on a touchscreen, with enough spacing that an adjacent button is not hit by mistake. Buttons that are too small or too crowded lead to slow, error-prone operation and wrong selections. On cloud HMIs used across control-room screens, tablets, and phones, the buttons must stay adequately sized on every device.
Opening a display is harmless and reversible, but a control command such as starting a pump or opening a valve is not, and an operator must never trigger a real process action while they think they are just navigating. Keeping the two visually and behaviorally distinct, and confirming consequential commands, prevents an accidental press of a control button when the operator meant only to move between screens.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.