A structured HMI learning path in five stages. Each stage teaches a concept in plain language, then drops you straight into a browser HMI builder to build it against a real simulated PLC — from your first start/stop panel to gauges, trends, alarms and multi-screen lines. No install. No HMI license. No hardware. Stage 1 is free.
How the path works
You do not learn HMI design by reading the manual — you learn it by building a screen, binding it to a running machine, and operating it. This path follows the order that works. Every stage opens with a short, plain-language explainer of what it covers and why it matters, then links you straight into the HMI Builder exercises that practise it. Each exercise hands you a finished PLC program; you build the operator panel. The teaching below is open for everyone to read; the hands-on exercises from Stage 2 on are part of Pro, and clicking any Pro exercise takes you to the builder where access is handled.
What an operator panel really is — and how a screen widget connects to a running machine.
An HMI — Human-Machine Interface — is the operator's window into a running process. It is the screen on the cabinet door (or the panel on the line) that shows what the machine is doing and lets a person start it, stop it, and respond when something goes wrong. Before you design one, you need a clear mental model of the three things every HMI is built from: screens, widgets, and tags. This stage builds that model and then has you wire up your first real operator panel — a motor start/stop — so the ideas connect to live behaviour before anything gets complicated.
A PLC runs the logic that actually controls a machine, but a PLC has no face — it is a box of relays and timers executing a program. The HMI is the face. It does two jobs at once: it PRESENTS the state of the process to a human (is the motor running? is the tank full? is there a fault?), and it COLLECTS the human's intent and sends it back to the PLC (start this, stop that, change this setpoint). A good HMI lets an operator who has never seen the ladder logic run the machine safely and confidently. That is the whole point: the screen is the contract between the person and the process.
An HMI application is a set of SCREENS, and each screen is a canvas of WIDGETS. A widget is a single on-screen control or indicator: a pushbutton, a pilot lamp, a numeric readout, a gauge, an alarm banner. Widgets fall into two families. INPUT widgets let the operator act on the process — a pushbutton the operator presses, a slider they drag, a selector they turn. OUTPUT widgets reflect the process back — a lamp that lights, a bar that fills, a number that updates. The art of HMI design is choosing the right widget for each job and arranging them so the operator instantly understands what the machine is doing.
A widget on its own is just a picture. What makes it an HMI is the TAG it is BOUND to. A tag is a named value inside the running PLC — START_PB, MOTOR_CONTACTOR, RUN_LAMP. When you bind an output widget to a tag, the widget continuously reads that tag and redraws itself: bind a pilot lamp to RUN_LAMP and the lamp lights whenever the PLC sets RUN_LAMP true. When you bind an input widget to a tag, operating the widget WRITES that tag: bind a pushbutton to START_PB and pressing it drives START_PB true in the PLC, exactly as if a real wired button had closed. The tag is the wire. Bind the wrong tag and the button does nothing — or worse, the wrong thing.
You build a screen in EDIT mode — dragging widgets onto the canvas and binding each to a tag — and you operate it in RUN mode, where the screen is live against the simulated PLC and your buttons and lamps actually work. Switching between the two is how you test your panel like a real operator would. One distinction matters from the very first exercise: a MOMENTARY pushbutton is true only while held and springs back to false when released (like a doorbell), while a LATCHED button toggles and stays. Start and stop buttons are almost always momentary, because the PLC's seal-in logic remembers the run state — the operator just nudges it. Getting momentary-versus-latched right is the difference between a panel that behaves and one that fights the operator.
Key takeaways
Build it in the HMI builder
The button-and-lamp vocabulary every panel is built from — momentary, latched, setpoints and modes.
Almost every operator panel is assembled from a small, well-understood kit of discrete controls and indicators: pushbuttons, pilot lamps, numeric entry and display, sliders, and selector switches. This stage teaches that kit properly — not just what each widget looks like, but when to reach for it and how an operator expects it to behave. Get the controls right and the operator trusts the panel; get them wrong and they second-guess every press.
A momentary pushbutton drives its tag true only while pressed and releases to false; a latched (or maintained) button toggles and holds. The choice is not cosmetic — it must match the PLC logic behind it. A classic 3-wire start/stop circuit uses a seal-in: pressing START momentarily energises the motor and the rung "seals in" so it stays running after you let go; pressing STOP momentarily breaks the seal. If you made START a latched switch, the operator would have to hold a state that the PLC is already holding — and a STOP press would fight it. So start and stop are momentary, and the PLC owns the memory. Reserve latched buttons for things the operator genuinely toggles and the PLC reads directly, like a maintenance-mode enable.
A pilot lamp is the simplest output widget: bound to a boolean tag, it lights when the tag is true. Lamps are how the panel answers "what is the machine doing right now?" — RUN, READY, FAULT, a pump running, a diverter active. You can bind a lamp to ANY boolean tag, not just PLC outputs: a lamp on a physics input like a height photo-eye shows the operator a sensor firing. Use colour and grouping deliberately — green/running and red/fault are conventions operators read at a glance, and a row of step lamps where only one is lit tells a story (filling, then mixing, then draining) far faster than any number.
Lamps answer yes/no questions; numbers answer "how much?". A numeric DISPLAY is an output widget that shows a tag's exact value — a temperature, a count, a pressure — for when precision matters. A numeric ENTRY is an input widget that lets the operator type a value into a tag, typically a setpoint. The trade-off with free numeric entry is that an operator can fat-finger a dangerous value, which is exactly why the next control exists.
A slider is a bounded numeric input: the operator drags it between a MIN and a MAX you define, and the position writes a value to a tag. The min and max you set ARE the safety limits — a slider scaled 10–30 °C simply cannot command 900 °C, so the operator can nudge a setpoint without typing a catastrophe. Sliders are the right choice whenever the value lives in a known, safe range and the operator adjusts it by feel rather than by exact figure: a fermentation target, a conveyor speed, a fill level.
Real panels are full of selector switches — the rotary Hand/Off/Auto switch is iconic. A selector widget gives the operator a small set of named, mutually exclusive positions, and the SELECTED INDEX is written to a tag (position 0, 1, 2 …). This is how an HMI expresses discrete MODE: cooling on or off, manual or automatic, line A or line B. Modes are powerful because they are unambiguous — there is no in-between, the operator picks one position and the process reads it directly. Together, momentary buttons, lamps, numeric readouts, sliders and selectors are the complete grammar of a discrete operator panel.
Key takeaways
Build it in the HMI builder
Turning raw process numbers into something an operator reads at a glance — gauges, bars and trends.
Discrete controls handle on/off, but real plants run on ANALOG values — temperatures, pressures, flows, levels, speeds — that live on a continuous range. A bare number like "73.4" tells an operator almost nothing on its own: is that high? rising? near a limit? This stage teaches the widgets that turn raw analog values into instant understanding: gauges that show where a value SITS, level bars that give spatial intuition, and trends that show where a value is HEADING.
Analog tags are not booleans — they carry a REAL or INT value (a temperature in °C, a level in counts, a speed in RPM). You bind an analog widget to such a tag exactly as you bind a lamp to a boolean, but with one extra job: you set the widget's MIN and MAX so it knows the process range. A temperature gauge scaled 0–120 °C reading 90 looks very different from the same value on a 0–1000 scale. The scaling you choose is what makes the picture meaningful, so it should match the real operating range of the process variable.
A gauge (a dial) answers "roughly where are we?" at a single glance, without the operator ever reading a digit. Because the needle's position maps onto the min–max range you set, an operator learns the normal resting zone and instantly notices when the needle is parked somewhere it should not be. Gauges are ideal for a value with a comfortable middle and uncomfortable extremes — a pressure that should sit mid-scale, a temperature that should hold near setpoint. The shape itself carries the meaning.
A level (or bar) widget is a vertical or horizontal fill that rises and falls with the value. For anything that is literally a level — a tank, a hopper, a reservoir — the bar maps directly onto the physical thing, so the operator reads it the way they would read a sight glass. Even for non-level quantities a fill bar gives quick spatial intuition: more fill means more of the thing. Pairing a bar with a gauge gives two complementary instant reads of the same value.
A gauge and a bar tell you where a value is NOW; a TREND tells you where it has BEEN and, by extension, where it is going. A trend is a chart that plots the tag against time, drawing a live pen as the process runs. This is the single most powerful analog widget, because most process problems announce themselves as a TREND long before they hit an alarm limit: a temperature creeping up, a pressure drifting down, a level oscillating. An operator watching a trend catches a runaway while there is still time to act. A well-designed analog screen almost always pairs an instant-read indicator (gauge or bar) with a trend, so the operator sees both the current value and its direction at once.
Key takeaways
Build it in the HMI builder
How a plant tells an operator something is wrong — without burying them in noise.
When something goes wrong, the HMI has to get the operator's attention — but a panel that cries wolf is worse than useless. This stage teaches alarm management: what an alarm actually is, how urgency is ranked, how a single prioritised alarm summary beats a wall of flashing banners, and the acknowledge-and-shelve discipline that keeps a real plant manageable. It also covers clear status indication for multi-step processes, so the operator always knows which phase they are in.
An alarm is not just "a thing happened" — it is a condition that requires an OPERATOR RESPONSE. That distinction, drawn plainly in the ISA-18.2 standard, is the foundation of alarm management. If nobody needs to do anything about it, it is information or an event, not an alarm. Treating every status change as an alarm is the original sin of bad HMIs: it trains operators to ignore the very signals that matter. So the first design question for any candidate alarm is always: when this fires, what is the operator supposed to DO?
Not all alarms are equal. A tank overflowing is a different order of problem from a filter that needs changing this shift. Severity tiers — typically something like critical, high, medium, low — capture that, and severity is not decoration: it decides SORT ORDER. When ten things go wrong at once, severity is what puts the overflow at the top of the operator's list and the filter near the bottom. Assigning severity honestly (and sparingly using the top tier) is a core part of designing an alarm system people can trust.
Rather than scatter a banner per fault across the screen, a mature HMI funnels every active alarm into one ALARM SUMMARY: a single prioritised, time-stamped list. The summary flashes unacknowledged alarms; the operator ACKNOWLEDGES them, which silences the flash (and any horn) to confirm "I have seen this" — but crucially does NOT clear the alarm while the condition persists. An alarm only leaves the list once it has BOTH cleared AND been acknowledged. You cannot make an alarm disappear just by fixing the process; someone has to confirm they saw it. For a known nuisance an operator can SHELVE an alarm — temporarily remove it from the active view — but only deliberately and usually with a time limit.
The failure mode that wrecks real control rooms is the alarm FLOOD: a single upset trips fifty correlated alarms in ten seconds and the operator, drowning, misses the one that matters. (Alarm floods have been a contributing factor in major industrial incidents.) You design against floods by being ruthless about what is truly an alarm, by setting sensible hysteresis and deadbands so a value hovering at a limit does not chatter on and off, and by using severity so that even in a flood the worst alarm sorts to the top. Fewer, better alarms beat more alarms every time.
Alarms tell the operator what is WRONG; status tells them where the process IS. A batch or a multi-station line moves through phases — fill, mix, drain, ready — and the operator needs to see the current phase at a glance. A row of step lamps where exactly one is lit is the classic, instantly-readable way to show this: the lit lamp walks down the row as the sequence advances. Clear status indication turns a black-box sequence into something the operator can follow and, when it stalls, diagnose.
Key takeaways
Build it in the HMI builder
Structuring a whole HMI application — overview, detail and faceplates — then earning your certificate.
A single screen can run a single machine, but a real line does not fit on one screen. This final stage teaches how to structure a complete HMI APPLICATION the way professionals do: a top-level overview the operator lives on, detail screens they drill into, navigation that ties them together, and pop-up faceplates for a quick look without losing their place. You assemble the bottling-line capstone, then split it across screens — and completing the path earns the HMI Designer certificate.
The bottling-line exercise is where everything from the earlier stages comes together on a single panel: latched run/stop control, a row of status lamps (ready, running, fault), and an alarm banner for jams and a full reject bin — three stations' worth of behaviour driven from one operator screen. Building it proves you can integrate discrete controls, status indication and alarms into a coherent panel rather than a pile of widgets. It also reveals the problem the rest of this stage solves: one screen quickly runs out of room.
The professional pattern is a HIERARCHY of screens. The OVERVIEW (or home) screen is where the operator spends their day: the big picture — line running or stopped, overall status, the start/stop controls — kept deliberately uncluttered. DETAIL screens hold the messy, station-specific stuff: per-station interlocks, individual faults, fine adjustments. The operator runs the line from the overview and drills into a detail screen only when they need to. This keeps the most-used screen calm and legible while the depth is one click away — the opposite of cramming everything onto one cluttered page.
Screens are tied together with NAVIGATION. A nav-button is a widget whose job is to switch screens — from the overview to a detail page and back. A FACEPLATE is the same idea in pop-up form: a small window that opens OVER the current screen showing the controls and detail for one device (a valve, a motor, a station), then closes — so the operator gets a focused look without ever leaving the overview they were watching. Faceplates are how mature HMIs keep context: you check a device and you are still standing on the overview. Designing navigation that an operator can move through without getting lost is a real skill — keep it shallow, consistent, and always offer a way home.
Completing every exercise — fundamentals, the operator-control kit, analog visualisation and trends, alarms and status, and these multi-screen capstones — earns you the HMI Designer certificate. It marks that you can bind widgets to live tags, choose the right control and indicator for each job, visualise analog values with gauges and trends, build a disciplined alarm system, and structure a real multi-screen application with sensible navigation: the working foundation of an HMI / SCADA screen designer.
Key takeaways
Build it in the HMI builder
Completing every exercise across all five stages earns the HMI Designer certificate — a verifiable record that you can bind widgets to live tags, choose the right control and indicator for each job, visualise analog values with gauges and trends, build a disciplined alarm system, and structure a real multi-screen application. Learn more about the HMI Designer certificate.
Keep exploring
Learn HMI design step by step in your browser — concept first, then build the operator screen against a real simulated PLC. Stage 1 is free; go Pro for the full path and a certificate.