Redesigning an industrial HMI around how operators work
A SCADA redesign that started from a very concrete mismatch: the software organized machines as technical entities, while operators remembered them by their position on the line.
- Role
- UX Designer & Qualitative Researcher
- Team
- 2-person design team
- Duration
- 4 months (Sept 2020 - Jan 2021)
- Client
- European Industrial Machinery Manufacturer (NDA)
The project in one minute
The Challenge
Monitoring, reporting, diagnostics and recipe management shared the same interface. Critical states competed with routine information, and patterns that differed across products made it harder to move from one machine to another.
My contribution
- Led the UX research, with 8 interviews across stakeholder groups
- Designed and ran the Duality Game exercise to surface implicit assumptions
- Performed heuristic evaluation and manual analysis of existing system
Results and scope
Specific metrics withheld due to NDA
The Challenge
What I was responsible for
- Led the UX research, with 8 interviews across stakeholder groups
- Designed and ran the Duality Game exercise to surface implicit assumptions
- Performed heuristic evaluation and manual analysis of existing system
- Designed the new information architecture around progressive disclosure
- Designed the recipe interface around the physical layout of the line
- Developed comprehensive design system and component library
- Created operational reference documentation and training materials
- Delivered 7 sprint presentations documenting design evolution
Monitoring, reporting, diagnostics and recipe management shared the same interface. Critical states competed with routine information, and patterns that differed across products made it harder to move from one machine to another.
In a two-person design team, I worked on the redesign of a SCADA system used to monitor and control industrial painting and coating lines. The interface had to serve operators, service technicians and software engineers, whose needs were very different.
An important difference surfaced early in the interviews: the software presented machines according to its own internal structure, while operators reasoned in physical terms, for example 'the third oven I walk past'. That mismatch explained several problems in recipe management and in reading the state of the line.
"An operator needs to understand quickly what's happening on the line; a technician needs to go into detail; an engineer needs to run diagnostics, remotely as well. The same screen can't show everything to everyone at once."
This distance between interface and plant increased the time needed to get oriented, exactly when it mattered most to understand the state, the alarm and the machine involved.
Operators mostly watched the physical line and checked the screen when something looked wrong. Recipe management, on the other hand, meant mentally translating a list of machines into their real position in the plant.
Research
Stakeholder interviews
"I mostly watch the real line. I glance at the screen when something seems wrong."
— Machine operator
Operators look for an operational answer first
The interface showed speed, production cadence, photocell status: dozens of data points. Operators could already see that everything was running by looking at the line; from the screen they needed to understand immediately what was wrong when there was a problem.
Recipes were hard to manage because the interface didn't follow the line
Machine configuration was difficult to learn because the interface showed an ordered list of machines while operators described the line spatially: 'the third oven I walk past.'
Duality Game
Developers and operators had different priorities
Differences emerged between what developers considered important and what operators actually used. In such a high-pressure setting, interviews alone weren't enough to bring them out.
Physical and digital controls didn't match
Operators reset alarms with the physical blue button, but the interface didn't clearly show what the button did, what state the system was in, or what would happen next.
Context-of-use analysis
Small and large plants use the system differently
In small plants operators used every feature in depth; in large ones they interacted little and mostly needed clarity. A single configuration didn't work for both.
Operators orient themselves by physical layout
Operators find their way by the physical layout of the plant more than by lists of machines. The interface had to follow the route they walk every day.
Key Insights
Monitoring and analyzing history are different activities
Real-time monitoring has to make a problem recognizable immediately; historical reporting is for detailed analysis. Keeping them in the same view created confusion.
Operators remember machines by position
Operators reason about the physical layout of the plant: to them a machine is 'the third oven I walk past', while the software called it Machine_ID_3.
Showing detail only when needed reduces overload
More than 40 data points visible at once overloaded the screen. With 12 essential indicators and details in progressive disclosure, the state of the line can be assessed quickly.
Consistency cuts the time needed to get oriented
Operators often work on several machines. Inconsistent interfaces lengthen training and raise the chance of error.
Goals & Principles
See at once where the problem is
Abnormal states were made immediately visible without requiring operators to interpret a dense set of indicators first.
Follow the operators' spatial model
Interface matches physical layout that operators walk through every day. Recipe management uses visual floor plan representation.
Different information for different roles
Different views for operators (monitoring focus) vs technicians (diagnostic depth) vs engineers (system configuration).
Consistent behavior across machines and screens
Uniform behavior across the whole product line reduces the training needed and operator confusion.
Guiding Principles
Clarity first, completeness second
Better to show less information clearly than everything ambiguously, especially when the operator is under pressure.
Follow the physical layout of the line
The interface follows how operators think about physical space, instead of database structures or technical hierarchies.
Show information in layers
Advanced options appear when they're needed, instead of all being visible from the start.
Solution Design
Interactive diagram
The right level of information
Change the view to see how the same system supports different tasks.
Monitor
The operator first needs to locate the exception. The overview shows system state without all the diagnostic detail.
Station 2 → attention required
Conceptual interface with a fictional system state. View switching only; no equipment controls or live process data.
A more readable synoptic view
Too much information on the main monitoring screen: more than 40 data points visible at once, no visual hierarchy, critical information hidden among the rest.
Alternatives considered
- Add filtering controls to hide/show sections
- Create multiple monitoring views for different scenarios
- Reduce to essential indicators with progressive disclosure
I reduced the view to 12 essential indicators, with details in progressive disclosure. I added color coding for system states and enlarged critical warnings.
Operators did not need a dashboard to confirm that normal production was normal: they could see the real line. The interface was therefore redesigned to make abnormal conditions and required actions immediately legible.
Trade-off: Some advanced users initially wanted more data visible. Solved with optional 'detailed mode' that maintained clarity while surfacing additional metrics for power users.
Recipes organized by physical layout
Recipe management was difficult to learn because abstract machine lists did not match the spatial model operators used on the factory floor.
Alternatives considered
- Better tutorials and training materials
- Simplified parameter entry with templates
- Visual floor plan matching physical layout
I created a visual floor plan to drag elements onto, with indicators for dependencies and a library of templates for common configurations.
The interface now follows the operators' spatial model of the plant ('the third oven I walk past' rather than Machine_ID_3), and dependencies between recipes and machines are easier to understand and to teach.
Trade-off: Each plant needs a custom layout configuration and initial setup is more complex. The clear gain in operator efficiency justified the cost.
Matching physical and digital controls
The unclear relationship between physical controls and digital states created dangerous ambiguity in critical moments.
Alternatives considered
- Add on-screen help documentation
- Create video training materials
- Visual diagram showing button-state relationships
I created a complete button-state schema: a diagram showing the physical buttons, the digital state for each position, the feedback for each action and documented recovery procedures.
The schema became the reference document between physical controls and the interface. Operators could read the system state at a glance and know what each action on the physical controls would do.
Trade-off: Every physical control in the product line has to be documented, and the schema updated when hardware changes. For safety and clarity it was worth it.
Outcomes & Impact
The redesign produced a navigable prototype, a shared design system and complete operational documentation. The main choices trace directly back to problems that surfaced in research: orientation on the line, alarm hierarchy, and the separation between daily use and diagnostics.
Specific metrics withheld due to NDA
100+ page style guide and documentation delivered
7 sprint presentations documenting evolution
Much simpler daily workflows for operators
Reduced cognitive load during critical moments
Faster alarm recognition and response time
Recipe management based on the physical layout of the line
Maintained diagnostic depth for technicians
Clearer troubleshooting pathways for service teams
Consistent experience across entire product family
A shared base for later development
What I delivered
- Navigable Figma prototype showing key workflows
- Comprehensive design system and component library
- Style guide documentation (100+ pages)
- Operational reference sheets for training
- Physical-digital button mapping documentation
- Spatial recipe interface specifications
- Responsive grid system and layout guidelines
- Accessibility standards and implementation notes
Reflections
Documentation and handoff are part of the solution when the product has to be maintained and configured by several technical roles.
What I would change
- Would have tested low-fidelity prototypes with operators sooner, to validate the spatial concepts earlier
- Would have pushed for more time on the factory floor, despite COVID constraints
- Would have created more comprehensive edge case documentation: QA found scenarios designed for but not fully specified
What worked and what was difficult
What Worked
The Duality Game surfaced misalignments
The Duality Game showed misalignments between stakeholders that the interviews hadn't brought out. Having developers and operators discuss priorities together made important differences explicit.
Progressive disclosure made the interface more manageable
Hiding complexity until it's needed made the interface more accessible without removing features. Operators appreciated an interface that opens up as their experience grows.
The design system made different products more consistent
Reusable components made the whole product family consistent and sped up later development.
Challenges
Aligning different needs took negotiation
User groups had conflicting needs: engineers wanted technical detail, operators wanted simplicity, service technicians needed both. It took careful negotiation and clear documentation of the trade-offs.
Technical constraints affected design choices
The legacy system's limits forced us to revise some design choices. I had to balance the ideal solution against technical feasibility and implementation cost.
Working remotely during COVID-19
Because of the pandemic, research and design happened remotely, and I adapted the methods accordingly. The project would have needed more on-site observation.