Operator-Centered Design in Manufacturing
Most MES interfaces are designed by engineers, evaluated by IT, and handed to operators as a finished product. The operators reject them. The standard response is more training.
The Feedback Is Always Diplomatic
There is a moment in most MES implementations where the operator interface is shown to the people who will actually use it for the first time. It usually happens at a sprint review or user acceptance testing, months into the project, after the budget is largely committed and the scope is considered closed.
The feedback is never blunt. It arrives wrapped in diplomacy, delivered by someone who does not want to be unkind about work that clearly took effort.
The screens look a little dated.
The navigation is hard to follow.
They said something about the buttons.
What that feedback means is that the people who will use this system every day do not recognize it as something built for them. They are correct. It was not. The interface was built by engineers, for engineers, and evaluated by a committee whose members will never stand at that station for twelve hours.
You can train someone to use a bad interface. You cannot train away their awareness that it is bad.
Workarounds appear within weeks of go-live. Parallel spreadsheets. Manual logs. Informal systems that replicate exactly what the MES was supposed to replace. By the time the implementation team has moved on, the operation is running on the workarounds and the MES has become a compliance artifact.
What an Operator Actually Needs
An operator standing at a workcenter needs to answer one question before anything else: is everything fine, or does something need my attention?
That answer should be readable from across the floor. It should not require walking up to a screen, scanning a dashboard, or interpreting a chart. It should be immediate.
Everything else follows from the answer to that question. When conditions are normal, the operator needs the order details, the processing time, and the controls to run the job. When a condition is trending out of tolerance, they need to see what is happening, right now, along with the manuals, sensor data, and history that help them understand it. When a failure has occurred, they need to see the failure and the actions available to resolve it.
Information density should be inversely proportional to how well things are going.
A Working Example
Below is a production status monitor built on this principle for a U.S. steel manufacturer. Three buttons. Green, yellow, red. The status is legible from a distance. Everything else appears only when it is relevant.
Click through each state.
What each state does
Green shows the order, the grade, the chemistry, the target and current temperature, and the processing time. It includes the controls the operator needs to run the job. Start is disabled because the heat is already running. Emergency stop is the only solid-filled button on the screen, because it is the only action with irreversible consequences.
Yellow leads with live monitoring. Roll temperature and roll pressure appear first, with the current reading, the trend, and the distance from threshold. Order information moves below. Underneath, the operator can reach the equipment manual for that specific condition, the live sensor feed, the workcenter history for similar events, and any orders linked to the same heat batch. Those links are not a static menu. They are surfaced because they are relevant to this condition on this equipment right now.
Red leads with the failure. What happened, when it was detected, how long it has been active, and which sensor reported it. Below that, the order and the quantity at risk. Then the three actions available: dispose, scrap, notify supervisor. And below those, the same contextual resources, filtered to this specific failure type.
What the Operator Never Sees
The display above is driven by machine learning models running against live sensor streams, a semantic knowledge graph that links equipment to manuals to historical events to order genealogy, and a predictive model that identifies failure conditions before they become failures.
None of that appears on the screen.
The operator does not see the word “AI” anywhere. They do not see model confidence scores. They do not see which system generated the warning. They see green, yellow, or red, and the information relevant to that state.
This is deliberate. An operator does not need to know which technology produced a warning. They need to know that a warning exists, what it means, and what to do about it. Every piece of technical provenance you surface at the point of work is cognitive load that adds no decision value.
The technology should be invisible at the point of work. If the operator has to think about the system, the system has failed.
Why the Simplest Screen Is the Hardest to Build
A three-button interface looks like it should be easy. It is not.
Reducing a complex operational picture to three states requires the system to do the interpretive work that a traditional MES pushes onto the operator. Something has to decide what “yellow” means for this specific piece of equipment, running this specific grade, at this specific point in the heat. Something has to know that when roll temperature rises on HC-4, the relevant manual section is Section 7, the relevant history is similar temperature events on the same workcenter, and the relevant linked orders are the ones sharing the same heat batch.
A dashboard that shows everything is easy to build. It requires no judgment. It transfers the entire interpretive burden to the person standing in front of it, who is also operating a furnace.
Simplicity at the interface requires sophistication behind it. That is the trade, and most MES platforms have made it in the wrong direction.
How ForgeOS Approaches This
ForgeOS generates operator interfaces from a description of what the operator needs to do, not from a configuration of what the platform supports. The screen is built for the task, the environment, and the workflow. An operator in a steel mill has different requirements than an operator in a cleanroom medical device facility, and the interface reflects that.
Operator involvement is continuous, not final. In a ForgeOS deployment, operators are using the real system in production by week two, when feedback still costs hours to address rather than months.
ForgeOS deploys in 6 weeks. Timeline varies based on plant size and existing automation infrastructure.