SmartFactory
Asset management at factory scale, and why designing for a single machine is a different problem than designing for two hundred of them.
manufacturing · asset-management · enterprise-ux · 2017–2020
Hexagon Manufacturing Intelligence needed to give factory operators visibility into hundreds of quality control machines simultaneously — coordinate measurement machines, laser scanners, portable gauges, all networked, all generating status data. The first instinct was the obvious one: show everything. What we built instead was a lesson in what happens when scale breaks the premise of the original design question.
The Brief
Manufacturing facilities are dense with measurement equipment. A single automotive plant might run hundreds of coordinate measurement machines alongside laser scanners, portable gauges, and optical systems, each contributing to a quality assurance workflow that keeps production moving. When one machine goes down, that workflow stalls.
Hexagon needed a web-based platform — Asset Manager — that would give shop floor managers and quality engineers a live view of machine health across an entire facility. Uptime, calibration status, error states, utilization rates. The kind of operational visibility that was previously only available by walking the floor.
The scope felt clear. The problem turned out to be harder than it looked.
// asset.manager · fleet-level dashboard · status visibility across networked manufacturing equipment
The Christmas Tree
The first design direction did what dashboards do: it showed everything. Machine 1, green. Machine 47, yellow. Machine 203, red. Status badges, utilization bars, alert counts for every asset in the fleet.
At ten machines, this worked. At fifty it was workable. At two hundred, it became what the client called the Christmas tree problem: a wall of color-coded indicators that technically contained all the information and practically communicated none of it. A factory manager scanning for problems had to look at two hundred entries to find the three that needed attention. Cognitive load scaled linearly with fleet size. That's not a dashboard, it's a burden.
The issue wasn't execution — the layout was clean, the color semantics were correct. The issue was the premise. We'd designed for the machine. We needed to design for the factory.
The Insight
The shift came from a domain knowledge question: what does a shop floor manager actually need from this system? Not a report on every machine. A signal about which machines require action.
Healthy machines don't need interface attention. Machines in normal operation are background noise. The only machines that should surface are the ones with issues, and among those, the ones with issues that actually matter. Which sensors indicate a problem worth investigating? What does "abnormal" mean in this specific domain — is a yellow status on a CMM during scheduled maintenance meaningful or irrelevant? How do you rank multiple simultaneous issues across a fleet?
These weren't design questions. They were domain questions. Answering them required time with Hexagon's metrology experts and the floor managers who used these systems daily. We needed to understand their mental model of a healthy factory before we could design something that matched it.
The principle that emerged: invert the problem. Don't show status and ask operators to find issues. Show issues and let everything else fade.
// field.use · tablet interface · machine-level detail accessible from the floor
The Solution: Intelligent Filtering
Asset Manager was rebuilt around exception-first logic. Machines operating normally receded. Machines with issues became visible, ranked by severity and actionability. The interface guided attention rather than demanding it.
This required building actual intelligence into the filtering layer: which alert types were meaningful, how to weight them, how to present multiple simultaneous issues without recreating the original noise problem at smaller scale. The visual design followed the logic, not the other way around.
We also had to design for the range of operator contexts. A quality engineer at a workstation had different needs than a floor manager doing rounds on a tablet. The information hierarchy had to hold across both contexts without branching into a separate product.
The Outcome
Asset Manager shipped to enterprise install at an automotive manufacturing client. It became the seed for a broader product suite within Hexagon's SmartFactory platform, and eventually the foundation for a spinoff company that is, nearly a decade later, still operating.
That outcome wasn't just about the interface. The client built an internal UX team, partly because of what they saw this project could produce. The capability proved more valuable than the product.
What I'm Proud Of
The inversion principle — showing exceptions, not status — is the obvious story. But that insight only became available after genuine domain immersion. The harder work was getting fluent enough in metrology and manufacturing operations to know which questions to ask.
Design in complex industrial domains isn't primarily a visual discipline. It's a systems discipline. Understanding the information hierarchy of a factory floor, what a floor manager actually looks for versus what an engineer cares about, how alert severity maps to operational urgency: that knowledge can't be assumed. It has to be built.
The fact that the client built an internal UX capability off the back of this project is, to me, the real outcome. We weren't just delivering a dashboard. We were demonstrating what design thinking could do in a domain that hadn't had much of it applied. That landed.