AI · 9 July 2026 · 7 min
Designing a copilot engineers will actually use
What I learned designing AI copilots for Siemens and Nordex, where the real design problem is not the conversation, it is control.
I have designed two industrial AI copilots in the last two years: the Siemens Industrial Copilot for factory engineering, and a service-troubleshooting copilot for Nordex. Different companies, different domains, the same lesson.
The interesting design problem is not the conversation. It is control.
The user already knows the answer
Consumer AI assumes a user who does not know something. Industrial AI does not get that assumption. An automation engineer configuring a production line knows their domain deeply. A wind-turbine service technician has done this diagnosis before.
These users do not need an assistant that is capable. They need one that is faster than doing it themselves, and the moment it is not, they stop opening it. There is no loyalty and no learning curve budget. It works on the second try or it is dead software.
That reframes everything. You are not designing for discovery. You are designing for a specialist deciding, repeatedly, whether to delegate.
Delegation needs three things
Watch how anyone delegates to a junior colleague and you see the same three requirements. They apply directly.
They need to know what the other party knows. An engineer will not delegate to a copilot whose context is invisible. Which project is it looking at? Which plugin is active? Which agent is it about to invoke? If the answer is hidden, the honest response is to do it yourself.
So on both projects, context is a visible, first-class part of the interface: not a setting, not an inference. The user can see the copilot’s scope at all times, and change it deliberately.
They need to see the work before it lands. Nothing an AI generates should be applied silently. Every result is reviewable, and the review is the default path rather than an advanced option.
This is where a lot of AI product design goes wrong. Auto-applying results feels smoother in a demo and is unacceptable in production, because the cost of a wrong change in a factory is not a bad user experience. It is downtime.
They need to be able to say no cheaply. If rejecting a suggestion is more work than not asking, the user stops asking. Dismissal has to be one action, and it must not lose their place.
Capability should be an object, not a personality
The tempting model is an assistant with a personality, one entity that handles everything you ask.
For expert tools, the better model is the opposite. Agents and plugins are explicit objects the user selects and combines. The interface treats AI capability as tooling the engineer wields, not as an oracle they consult.
This is less magical. It is also the difference between a tool and a toy. Engineers are comfortable with tools that have visible parts. They are deeply uncomfortable with systems whose behaviour they cannot predict, and they should be.
Wireframes settle arguments that visuals cannot
On the Nordex project we worked wireframe-first, deliberately, for longer than felt comfortable.
The reason is specific to AI products. The hard questions are behavioural: what happens when the model is uncertain, what the user sees when a response is partially wrong, how a conversation recovers from a bad turn, what an edge case looks like. Those questions are answerable in grey boxes. They are almost impossible to discuss once the screens look finished, because everyone starts talking about the visual design instead.
Low fidelity kept the conversation on behaviour. By the time we moved to visual design, the genuinely difficult decisions were already made.
Do not build a destination
Both copilots live inside an existing workflow. Neither is a place you go.
This sounds obvious and is constantly violated, usually for organisational reasons: the AI is a new product, a new team owns it, and new products want their own surface. But the engineer’s workflow already exists, has existed for years, and is where their attention is. An assistant that requires leaving it has to be dramatically better to be worth the switch. One that lives inside it only has to be slightly better.
The uncomfortable part
Good AI UX often means making the AI look less impressive.
Showing the scope. Showing the uncertainty. Requiring review. Making the user pick the tool instead of guessing on their behalf. Every one of these makes for a worse demo and a better product.
In a domain where being wrong is expensive, trust is not built by appearing capable. It is built by being predictable. That is not a new principle; it is the same one behind every instrument cluster and every medical interface I have designed. AI has not changed it. It has just raised the stakes.
I design AI products for enterprise teams, and I ship my own: Wonfolio. If you’re building one, tell me what’s stuck.