Making factory-machine data usable

Context

Niagara is a data platform for industrial hardware. It gives a no-code connection to legacy machines, and a place to transform that data and send it to the operational software that needs it. The hard part is the reality of a factory: the machines are often old, and all different from one another.

That variety created the central tension of this project. The feature I worked on lived in a gap between three roles: the IT managers who own the data infrastructure, the business users who actually analyze the data, and the automation engineers who program the machines. Depending on the company, I could be designing for any one of the three.

The problem

The data is siloed. Every use case rebuilds its own funnel, from the machine to the IT databases to the operational software. Niagara makes each of those funnels easier to build, but it doesn't stop them from multiplying: the same data gets pulled several times, and nothing is standardized along the way. IT ends up doing the same normalization work over and over, and ops end up with data they can't fully trust.

Inside Niagara, when a new data stream arrived, it technically worked, but:

• it kept the machine's raw variable names, so business users couldn't tell what they were looking at;
• and those names were different from one machine to the next, so the same physical value arrived under two shapes and nothing IT built for one machine worked for the next;
• fixing either was possible in Niagara, but machine by machine, so nobody did it at scale.

The question I framed: how do we get these different users to converge, and make factory data genuinely usable?

Research

I ran two tracks in parallel.

User feedback, over 50+ interviews, confirmed the pain and showed it had two levels:

• mature companies wanted standardization to use their data at scale;
• less mature ones simply wanted to organize their data enough to handle it at all.

What they couldn't tell me was who owned the problem.

Secondary research shaped the constraints:

• the Unified Namespace, a practice for centralizing information and redistributing it, became the backbone of my structure;
• cyber risk was a hard limit: in a factory, data can't move freely without opening security holes;
• mapping how standardization happened at the time was telling: siloed by department, case by case, no global view, and sometimes the same data pulled twice for two different uses.

The bet

A feature to create standard data models and apply them to data sources, to standardize them.

We chose a reusable model layer over simpler fixes like renaming variables one by one. Renaming would have stayed manual and machine-specific, exactly the repetition users were drowning in.

A model layer solved three things at once:

• it turned repetitive work into something reusable across machines,
• it gave the three roles a shared language to work from,
• and it made data manageable at scale, by keeping each kind of data cleanly structured and separated instead of letting everything pile up into one unusable mass.

That last point mattered most for growth: without a model, scaling just meant a bigger mess. With one, the more data came in, the more organized it got.

Design

I worked the structure out with the engineers on a whiteboard before touching Figma. Designing straight with the devs is how I usually work: fast, throwaway, and it surfaces the real constraints early. Based on the Unified Namespace, the structure came down to three levels, model, instance, asset, and I mapped which user could do what, and where.

From there I moved to hi-fi: a data-model library on one side, and the instance, the live twin of a real machine, on the other, with the mapping between them. I built it as an interactive prototype so users could react to something real rather than static screens.

Testing

I tested the prototype with users from our target audience, and also asked questions about their maturity on the topic: the state of the art on digital twins, then reactions to the prototype, and the use cases people saw for it. The mapping tested well. The users were excited about the idea of having a shared language to work from, and the interactive prototype was a success. But the users did not buy it: "it's too good to be true". That red flag taught us we had missed something. I had run out of options for further research, so the next step would have been to ship and learn.

What happened, and what I learned

Even if this feature never shipped, Niagara was acquired by Vitesse Automation, and this work was part of what was bought.

The lesson I carry: it took 50+ interviews to learn that interviews were the wrong instrument. You can't interview your way into a role that doesn't exist yet, because people can't describe a job they don't hold. You build it, you put it in their hands, and you let the role form around it. That is exactly the kind of problem I want to work on, designing the products that make emerging, technical work legible to the humans who do it.