Production Dashboards That Operators Actually Use

Production dashboards work when they show a small number of live, trusted numbers that change someone's next decision: current machine state, count against target, and the reason for the last stop. They fail when they're built for managers, stuffed with charts, fed with stale data, or mounted where nobody looks. The design target is a screen an operator can read from thirty feet in three seconds, and everything else is negotiable.

Every plant has seen the corpse of a dashboard project: a TV on the wall showing last week's numbers, or a login-gated portal one manager checks monthly. The screen isn't the product. The glance is. Here's how to build production dashboards that survive contact with a real floor.

Why Most Production Dashboards Die in a Month

The autopsy usually finds one of four causes. The data was stale, so the screen showed 340 parts while the operator's counter said 384, and from that moment the screen was furniture; trust, once lost to a wrong number, does not come back at a discount. The audience was wrong, so a screen meant for the floor showed month-to-date OEE trends that no operator can act on at 9:40 on a Tuesday. The screen was overloaded, because dashboards accrete; every stakeholder adds a pet metric until the display is a spreadsheet in cosplay. Or nothing depended on it: no meeting opened with it, no decision cited it, and screens nobody depends on get quietly unplugged when the HDMI cable is needed elsewhere.

Notice that none of these are technology failures. The charting library never matters. The editorial decisions do.

What Should a Production Dashboard Actually Show?

For the operator-facing screen at the line, the defensible core is small: current state (running, idle, faulted, changeover) in unmistakable color; actual count versus target count for this shift, ideally as a pace ("+12" or "-31" against where you should be right now); and the current or last stop with its duration and reason. Some floors add cycle time versus standard, or time until the next changeover. That's roughly the ceiling. Five numbers, readable across an aisle.

The "versus target" part carries most of the value. A raw count of 512 means nothing without knowing whether the shift needs 480 or 700. Pace converts the number into a feeling: we're ahead, we're behind, something's wrong. Operators respond to pace the way drivers respond to a speedometer, instantly and without training. Getting the target right per product per line is unglamorous configuration work, and it's half the project.

What stays off the floor screen: anything historical, anything financial, anything comparative between operators (a reliable way to poison the whole effort), and anything requiring interpretation. Trends belong on other screens, which brings up the layering question.

One Dashboard Is Actually Three

The word "dashboard" hides the fact that three different audiences need three different screens fed by the same data.

The operator screen is the andon layer: now-facing, glanceable, zero interaction. Think of it as a stack light with vocabulary. The supervisor screen is shift-facing and interactive: all lines at once, stop reasons as they accumulate, the ability to tap into a machine's day and see that lane 3 has stopped nine times since lunch. This is the screen for downtime tracking triage while the shift can still be saved. The manager screen is trend-facing: OEE by machine by week, downtime Paretos, and the question "is the thing we changed working?" It can live in a browser and update hourly without anyone suffering.

Collapse the three into one screen and each audience gets a worse tool. The floor gets clutter it can't read at distance, and the manager gets live noise instead of trends. Build the operator layer first; it's the one that changes behavior the same week it goes up.

Design for a Glance From Thirty Feet

Floor screens are read at distance, at an angle, under sodium or LED glare, by someone mid-task. That imposes real rules.

Type must be enormous: shift counts in digits several inches tall on a 55-inch display, which in practice means font sizes that feel absurd on a desktop preview. State colors must match plant vocabulary exactly, and your plant already has one, defined by its tower lights: green running, amber idle or attention, red faulted. A dashboard that renders "idle" in blue because the designer liked blue is fighting thirty years of muscle memory. Use color as signal, not decoration, and remember roughly one in twelve men has deficient color vision, so pair every color with position or a word, exactly as stack lights pair color with position.

Motion draws the eye, so use it only for state changes; a flashing red panel when a machine faults is appropriate, while a permanently animated chart is noise that trains eyes to ignore the screen. Handle darkness honestly: dark backgrounds survive glare better on most floors and don't light up a night shift like a billboard. This is straightforward but genuinely disciplined software engineering; "big number on TV" prototypes are easy, and screens that stay legible, truthful, and running for two years are not the same artifact.

The Data Behind the Glass

A dashboard is only the visible end of a data pipeline, and the pipeline sets the ceiling on trust.

Latency should match the layer: a few seconds from machine event to operator screen, because a "live" screen that lags two minutes will be caught lying during every fault. The standard plumbing (sensor or PLC to edge device, MQTT to a broker, time-series database, then the display) handles this comfortably when nobody puts a nightly batch job in the middle. Everything on screen ultimately rides on collection quality, which is why the dashboard project is usually the second project, after machine monitoring basics are solid. A dashboard on top of bad collection is a rumor with typography.

Plan for gaps honestly. Networks drop and sensors fail, and the screen must say "no data since 10:14" rather than freezing on the last good number, because a frozen count that looks current is worse than a blank. Store-and-forward at the edge keeps history intact through outages; the display should still admit, in the moment, what it doesn't know.

Hardware and Rollout Notes From the Floor

Commercial displays beat consumer TVs for continuous duty, but plenty of plants run consumer TVs for years; the more important choices are a mounting height visible over racking, a fanless mini PC or a locked-down single-board computer behind the screen in kiosk mode, and Ethernet rather than Wi-Fi wherever a cable can reach. Budget typically lands at $600 to $1,500 per display point in hardware. Auto-recovery is the detail that separates toys from tools: after a power cut, every screen must return to its dashboard with no keyboard, no login, and no one climbing a ladder. Test this by pulling the plug, twice.

Roll out to one line first and let word of mouth do the marketing. When the second line's crew asks where their screen is, you've validated the design; when they don't, you've learned something cheaper than a plant-wide rollout.

FAQ

What's the difference between a production dashboard and an andon board?

An andon board is the minimal now-layer: state and maybe a count, designed purely for distance viewing, descended from the tower light. A production dashboard usually adds targets, pace, and stop reasons, and its supervisor and manager layers add interaction and history. The best floor dashboards are essentially andon boards with a little more vocabulary, not analytics portals on a TV.

How real-time does a production dashboard need to be?

For floor screens, seconds; operators compare the screen to the machine in front of them and notice every lag. For supervisor views, under a minute is comfortable. For trend views, hourly is fine. Match the refresh to the decision each screen serves rather than paying for uniform speed nobody needs.

Can we build production dashboards on top of our existing spreadsheet reporting?

Not for the floor layer; spreadsheets are batch artifacts and the operator screen needs live state from machine signals. But your spreadsheet-era definitions (targets, shift calendars, reason codes) are exactly the configuration a dashboard needs, so the reporting logic you've refined transfers even though the plumbing gets replaced.

Should operator dashboards show individual performance?

We'd advise against it. Publicly ranking operators reliably corrupts the data (miscounts, gamed reason codes) and poisons trust in the whole system for a marginal motivational effect. Show the line against its target instead; crews compete with the target naturally, and the data stays honest.

If your last dashboard project ended as a dark TV on a wall, the fix is editorial as much as technical, and it starts with trustworthy signals from the machines. Willowark builds the whole path, from sensor to screen, as part of our industrial automation practice. Talk to us about what your floor should see.