Industrial Dashboard Design: 12 Principles for SCADA Screens, Mobile Views and Kiosk Consoles

By Dzulfikar Ats Tsauri, founder of Voltrus / JoyoDigitama. He builds the protocol tools covered in these posts. Updated October 28, 2026.

The short version: a good factory or SCADA dashboard shows what is wrong first, answers one question per screen, reserves color for status, shows trends next to current values, groups by physical location, works on a phone, and hides everything the operator does not act on. The 12 principles below expand each of these, followed by how to deploy the screen as a locked-down kiosk console. For the KPI itself, see the OEE formula explained.

Walk into a control room and count how many screens show live data that someone is acting on, and how many have not been looked at in weeks. Most industrial dashboards are designed by engineers who understand process control but have not studied how people read visual information. The result looks impressive in the commissioning demo and becomes invisible within a week of daily operation. Operators stop looking because the screens do not help them do their jobs.

This is a design problem, not a technology problem. A good industrial dashboard is the one that tells you something is wrong before you knew to look. The 12 principles below come from real SCADA deployments across manufacturing, utilities and process industries. After them: mobile access, kiosk-mode operator consoles, and the anti-patterns to stop.

The Problem: Engineers Are Not UX Designers

System integrators configure SCADA dashboards as part of the commissioning process. They know the process. They know the instrumentation. They know what data is available. What they do not know is cognitive load theory, preattentive processing, or the Gestalt principles of visual perception. These are the tools that UX designers use to create interfaces that communicate information efficiently.

The typical commissioning process goes like this: the integrator asks the plant manager what they want to see on the screen. The plant manager says "everything." The integrator puts everything on the screen. The plant manager approves it because it looks comprehensive. Three months later, nobody is looking at the screen because it has 47 gauges, 12 trend charts, and a color scheme that looks like a unicorn exploded on a spreadsheet.

The cost of a bad dashboard is not aesthetic. It is operational. When operators stop trusting the dashboard, they stop using it. They go back to walking the plant floor, reading local instruments, and relying on their experience instead of the monitoring system that cost $50,000 to install. The SCADA system becomes expensive wallpaper.

Principle 1: Lead with the Exception

Principle 01

The default state of an industrial dashboard should communicate: everything is normal, and here is the one thing that is not.

Most dashboards do the opposite. They show every measurement at all times, with all values displayed at equal visual weight. The operator has to scan the entire screen to determine if anything is wrong. This works during commissioning when everyone is excited about the new system. It fails after six months when the operator has seen the same normal screen two thousand times and their eyes have stopped processing it.

The correct approach: design the screen so that normal operation is visually quiet. When a value goes out of range, it should be the most visually prominent thing on the screen. Not by adding a red blinking border to every widget, but by making normal values visually recede and abnormal values visually pop. The alarm condition should be impossible to ignore without being so aggressive that operators develop alarm fatigue.

Practical implementation: display only out-of-range values in color. Everything else is monochrome. When the screen is monochrome, the operator knows everything is normal. When a single value appears in color, the operator's attention is drawn to it immediately. No scanning required.

Principle 2: One Screen, One Question

Principle 02

Each dashboard view should answer exactly one question. If you cannot state the question in one sentence, the view is doing too much.

Examples of good questions:

• "Is the boiler operating within safe parameters?"
• "Which tanks are above 80% capacity?"
• "What is the current production rate compared to the target?"
• "Are there any active alarms on Line 3?"

Examples of bad questions (that real dashboards try to answer simultaneously):

• "What is the status of the entire plant?"
• "Show me everything about the water treatment system, the boiler, and the packaging line."

The "show me everything" dashboard is the most common mistake in industrial design. It stems from a fear that operators will miss something if it is not on the current screen. This fear is backwards. When everything is on one screen, the operator misses things because the signal-to-noise ratio is too low. The solution is navigation, not density. Create focused views and make it easy to switch between them.

Principle 3: Color Means Status

Principle 03

In an industrial dashboard, color has exactly one job: communicating status. Green means normal. Red means alarm. Yellow means warning. Period.

Every other use of color is a distraction. Using blue for water lines, orange for steam, and purple for compressed air on a process schematic is a convention that engineers understand. But on a monitoring dashboard where the operator needs to detect abnormalities at a glance, decorative color is noise. The blue of a water line and the blue of an informational label become visually indistinguishable. The operator's brain has to sort through multiple color meanings simultaneously.

The rule: if a color is not communicating status, remove it. Use position, labels, and grouping to distinguish between measurement types. Reserve color exclusively for "this needs attention." When the operator sees color on the screen, they should not have to think about what the color means. Color equals attention required. No color equals no attention required. This binary is the most powerful communication tool you have.

Principle 4: Numbers Beat Gauges

Principle 04

Analog-style gauges are the most overused widget in industrial dashboards. They look like the real instruments that used to sit on control panels, so engineers love them. But gauges are objectively worse than digital readouts for communicating precise information.

A gauge showing a needle pointing to roughly 73% requires the operator to estimate the exact value. A digital readout showing 73.4% communicates the exact value with zero ambiguity. When the boiler pressure is 14.7 bar and the safe limit is 15.0 bar, the operator needs to see 14.7, not a needle that is "near the red zone."

Gauges also consume disproportionate screen real estate. A single gauge that displays one value takes up the same space as four to six digital readouts. On a monitoring screen where every pixel matters, gauges are an inefficient use of space.

When to use gauges: never, unless the operator specifically needs to see rate-of-change by watching a needle move. For 99% of industrial monitoring, digital readouts are superior.

Principle 5: Trends Beat Snapshots

Principle 05

A single number without context is almost meaningless. "Tank level: 72%." Is that normal? Is it rising or falling? Has it been at 72% for three hours or did it just jump from 40%? Without trend context, the operator has to remember what the value was last time they looked and mentally compute the trajectory.

A sparkline, which is a small inline chart showing the last N hours of data, provides context that a single number cannot. The operator sees not just the current value but the trajectory. A value of 72% with a flat trend line means something completely different from 72% with a steep upward trend line. The trend tells the operator whether action is needed now, soon, or not at all.

Every numeric value on a monitoring dashboard should have a companion trend visualization. This does not mean every widget needs a full chart. A sparkline 100 pixels wide and 30 pixels tall provides sufficient trend context. The combination of a precise digital readout and a sparkline is the most information-dense, decision-supportive widget available for industrial monitoring.

Principle 6: Group by Physical Location

Principle 06

When a dashboard shows measurements from across a facility, the spatial arrangement of widgets should mirror the physical layout of the plant floor. This is not a metaphor. It is a direct mapping.

Operators navigate their facility physically. They walk from the pump room to the tank farm to the processing building. When the dashboard layout matches this spatial relationship, the operator can locate a problem on the screen in the same way they locate it on the plant floor. "The third tank from the left" on the screen corresponds to "the third tank from the left" in the physical yard.

The alternative, grouping measurements by type (all temperatures together, all pressures together, all flow rates together), is the engineering-centric approach. It makes logical sense from a data taxonomy perspective. It fails in practice because operators do not think in terms of measurement types. They think in terms of equipment and locations. When the temperature alarm fires for "TT-3047," the operator has to mentally translate that tag name into a physical location. When the alarm fires for a widget positioned on the screen where the actual equipment sits in the plant, the translation is instant.

Principle 7: Hide the Noise

Principle 07

Principle 1 says abnormal values should stand out. Principle 7 is how you build it: a visual gradient that matches the alarm thresholds. A pump that has run at 1,450 RPM for three years should look different from one that just started vibrating at 1,620 RPM, and a tank that has sat at 50% all day should look different from one that just spiked to 95%.

Set the display style from the same thresholds as the alarms. In the normal range, show small, muted, neutral text. In the warning range, increase prominence slightly. In the alarm range, make it the most prominent thing on screen with status color, larger text and a border or background. The operator's peripheral vision picks up pattern breaks, so one loud value on a quiet screen draws attention without any scanning.

Principle 10: Mobile Is Not Optional

Principle 10

The maintenance supervisor gets a call at 2 AM that compressor discharge temperature is trending high. If the dashboard is not readable on a phone, they have to drive to the office and log into a computer before deciding whether to dispatch a technician. That is a ten-minute delay on a decision a phone could have made.

Dashboards are used in three places: the control room (large screen), the plant floor (tablet), and off site (phone). The phone is the most time-sensitive, because whoever opens it is responding to an alarm. Other users benefit too: a manager checking last night's downtime, a technician verifying a repair while standing at the machine, an operator watching dozens of lift stations from one device.

Designing for the phone

• Status first. Active alarms with severity, equipment state (running, stopped, faulted) and the few key process values, all visible without scrolling. Setpoints and diagnostics go below the fold.
• Single-column layout that stacks vertically, with trend charts readable at phone width (no multi-series overlays on a 390-pixel screen).
• Touch targets of at least 44 by 44 pixels (iOS) or 48 by 48 (Android), with enough spacing that a glove or a cold finger does not hit the wrong control.
• Flat navigation. An all-sites overview, a site screen, a trend viewer and an alarm list with acknowledgement. Every extra tap is friction during an incident.
• Tolerance for weak cellular coverage. Load critical values first, show last known values with a "connection lost" marker, reconnect without a manual refresh, and keep JavaScript and assets small.
• High contrast. Screens get read in sunlight and in dark control rooms. Use text with real contrast, and distinct status colors rather than subtle shades. Many operators are over 40, so size text accordingly.

Reaching it securely

Never expose the SCADA server directly to the public internet. Open ports are found by scanners within hours, login pages get brute-forced, and any vulnerability in the software becomes an internet-wide attack surface. Keep the server behind the firewall and put an authenticated layer in front: a VPN, or zero trust access such as Cloudflare Access or Tailscale, which gives per-user, per-resource logging without a VPN client. On top of that, require multi-factor authentication, make mobile sessions read-only by default, time out idle sessions after 15 to 30 minutes, and log who connected, from where, and what they changed. Voltrus Remote is built for this; see Voltrus Remote and the guide to secure remote access to PLC networks.

Responsive web or native app

For most SCADA work a responsive web dashboard is the better choice: no installation, no app store review, server-side updates, one codebase for iOS, Android and desktop. A native app is worth the cost only when you need offline access or native push notifications for alarms. If the existing HMI is a desktop-only Windows client, a remote desktop gateway (Apache Guacamole, Parsec, Windows RD Gateway) is a stopgap that is sluggish on mobile networks. Migrating to a platform with a web HMI (Ignition Perspective, Voltrus, VTScada) is the real fix, and usually worth it if the system has five or more years of life left.

Principle 11: Test with the Night Shift

Principle 11

The most important test of an industrial dashboard is not the demo to the plant manager on a Tuesday afternoon. It is whether the night shift operator can understand the screen at 3 AM when they are tired, the control room is quiet, and their attention is divided between the dashboard and three other tasks.

Cognitive load capacity drops significantly with fatigue. A dashboard that is clear at 2 PM may be incomprehensible at 3 AM. Small text becomes unreadable. Subtle color differences become invisible. Complex navigation sequences become disorienting. The only way to know if your dashboard works under fatigue conditions is to test it under fatigue conditions.

Practical approach: deploy the dashboard to a test environment and have the night shift operators use it for a week. Watch them use it. Note when they hesitate, when they navigate to the wrong screen, when they ask a colleague for help. These friction points are the design failures that a daytime demo will never reveal. Fix them before the dashboard goes live.

Principle 12: Delete Until It Hurts, Then Delete One More Thing

Principle 12

The most powerful design tool in industrial dashboards is the delete key. Every element on the screen should justify its existence. If you cannot explain why a widget is there in one sentence, remove it.

Industrial operators are not data analysts. They do not need to see every measurement the system collects. They need to see the measurements that inform decisions. The difference is enormous. A dashboard showing 30 carefully chosen measurements that each support a specific decision is more useful than a dashboard showing 200 measurements that "might be useful someday."

The deletion process:

1. List every element on the current dashboard.
2. For each element, ask: "What decision does this measurement support?"
3. If the answer is "none, but it is nice to have," delete it.
4. If the answer is "someone might need it eventually," delete it.
5. If the answer is "it supports a real decision that operators make regularly," keep it.
6. Apply this test again. The second pass will find more deletions.

The result should feel uncomfortable. If the dashboard still feels comprehensive, you have not deleted enough. The goal is a screen where every element earns its place and the absence of any element would be noticed. This is the difference between a useful monitoring tool and decorative data visualization.

Putting the Screen on the Wall: Kiosk Mode Operator Consoles

A dedicated operator console should do one thing: show the dashboard. No web browsing, no other apps, automatic recovery after a power cut. You do not need Tauri or Electron for that. A browser in kiosk mode gives you fullscreen with no address bar or tabs, and the web UI your SCADA already serves is the console UI. A native wrapper only earns its place when the console itself needs serial port access (a USB-to-RS485 adapter), raw TCP or UDP straight to PLCs, a system tray process, or seamless self-update.

Chromium kiosk flags

chromium-browser \
  --kiosk \
  --no-first-run \
  --disable-translate \
  --disable-infobars \
  --disable-session-crashed-bubble \
  --incognito \
  http://localhost:3000

--kiosk gives fullscreen with no chrome. --no-first-run skips the welcome wizard, --disable-session-crashed-bubble stops the "Restore session?" dialog after a reboot, --disable-infobars and --disable-translate remove popups, and --incognito avoids cached state between sessions. On macOS the same flags work through open -a "Google Chrome" --args --kiosk URL.

Auto-start on Linux

Use two systemd services, so the server starts first and either process is restarted if it dies:

# /etc/systemd/system/voltrus.service
[Unit]
Description=Voltrus SCADA Server
After=network.target

[Service]
ExecStart=/usr/local/bin/voltrus
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/voltrus-kiosk.service
[Unit]
Description=Voltrus Kiosk Browser
After=voltrus.service graphical.target
Wants=voltrus.service

[Service]
User=operator
Environment=DISPLAY=:0
ExecStart=/usr/bin/chromium-browser --kiosk --no-first-run --disable-translate --disable-infobars --disable-session-crashed-bubble --incognito http://localhost:3000
Restart=always
RestartSec=10

[Install]
WantedBy=graphical.target

sudo systemctl enable voltrus voltrus-kiosk
sudo systemctl start voltrus

On macOS, add the server binary (or a launchd plist) and a Chrome kiosk launcher to Login Items. On Windows, put a shortcut running chrome.exe --kiosk --no-first-run --disable-infobars http://localhost:3000 in shell:startup and run the server as a service through nssm or Task Scheduler.

Lock down the rest

Kiosk flags remove the browser chrome, but not every escape route. Page-level JavaScript can block the context menu and common shortcuts (Ctrl+W, Ctrl+T, Ctrl+L, DevTools), and Voltrus ships this as a kiosk-mode option. JavaScript cannot stop OS-level switching such as Alt-Tab, so that has to come from the window manager or a dedicated kiosk session, plus physical measures:

• Touchscreen only. No keyboard means no shortcut to escape.
• Locked enclosure. The PC lives in a cabinet and operators only touch the display.
• Network isolation. The kiosk PC talks only to the SCADA server, enforced at the switch or router.
• UPS. The console rides through brief power dips without rebooting.

Restart=always covers process crashes. To catch a blank page or a hung app, run a health check, for example a cron entry that runs curl -sf http://localhost:3000/health every minute and mails an alert on failure. Any machine that runs Chromium works as hardware: a Raspberry Pi 4 with a touchscreen for a wall display, or a mini PC (Intel NUC, Lenovo Tiny) for a console.

Anti-Patterns: What to Stop Doing Immediately

These show up in almost every SCADA deployment, and each one is a principle above being broken. Fifteen analog gauges on one screen is a digital museum of obsolete instrument design. A rainbow of colors for measurement types leaves no color free for status. Five levels of nested navigation between an alarm notification and the screen that explains it is too slow for an incident. And 200+ data points on one view is what you get when you answer "what do you want to see?" with "everything." Give the client a hierarchy instead: the overview shows the critical few, and detail views hold everything available for each area.

How Voltrus Helps You Build Better Dashboards

Voltrus includes a dashboard builder designed around these principles. Not because we read a design book, but because we watched operators ignore SCADA screens for years and decided to build something they would actually use.

Grid and canvas layouts. The dashboard builder supports both grid-based layouts (snap-to-grid for fast, consistent arrangement) and freeform canvas layouts (for process schematics that need to match the physical plant floor layout described in Principle 6). Switch between them depending on the view.

Responsive by default. Every dashboard built in Voltrus renders correctly on phones, tablets, and large screens. The layout engine handles the responsive breakpoints. You do not need to design separate mobile views. The same dashboard that looks good on the control room monitor is readable on the night supervisor's phone at 2 AM.

Trend widgets. Every numeric widget can include an inline sparkline showing configurable time ranges. This is not an add-on or a separate chart component. It is a built-in option on every data widget. The combination of digital readout and trend context described in Principle 5 is the default, not something you have to configure from scratch.

Alarm-first design. The default dashboard template starts with an alarm summary at the top. This is not accidental. It reflects Principle 1 (lead with the exception) and Principle 8 (zero clicks for status). The operator loads the dashboard and immediately sees whether anything needs attention. Drill-down into specific equipment is one click away.

Status-based color theming. Voltrus uses a constrained color palette by default: neutral for normal, amber for warning, red for alarm. No rainbow options. No custom color pickers that let you make every widget a different shade of teal. The color system enforces Principle 3 at the platform level. You would have to work against the tool to violate it.

Further Reading

• SCADA OEE and Downtime Tracking: What to Measure and Why
• SCADA Alarm Management
• Secure Remote Access to PLC Networks
• SCADA Architecture: From Sensors to Dashboards in Plain English