The riskiest screen in a plant-data product is the one where someone connects their first machine. Everything before it is a promise. That screen is where the promise turns into data or turns into a support ticket. So the goal I keep coming back to is boring on purpose. Make connecting a machine boring. Boring means predictable. Boring means the person doing it already knows what happens next.
The failure mode is a blank page that quietly assumes expertise. "Enter your connection parameters" is fine if you already know that Modbus TCP wants a unit ID and a register map, and that OPC UA wants an endpoint and a security policy. It is not fine if you do not. Worse is the version that lets you fill it all in, click save, and then tell you an hour later, on a device you cannot see, that it never worked. The distance between "I entered something" and "I found out it was wrong" is where onboarding falls apart.
So the shape was a protocol schema registry. Each protocol declares what it needs. Its parameters, their types, what is required, what has a sane default. The wizard builds the form from that declaration. The form is not hand-built per protocol and drifting out of sync. It is the protocol describing itself. Pick Modbus TCP and you get Modbus TCP's fields, checked against Modbus TCP's rules. Add a protocol later and the wizard already knows how to ask for it.
The second piece is a test connection before you commit anything. There is a button that reaches out, tries the parameters against the real machine, and tells you now. Not in an hour. Not on a device across the country. Then the config gets previewed and validated on every push. The thing that lands on the edge box is the thing you watched succeed. Enter, test, see it work, then commit. Feedback where the decision is, not where the consequence is.
The third piece is the blank page itself. Not everyone starts from nothing, and the ones who do should not have to. So there are machine templates that fill in the shape you would otherwise have to know. There is CSV tag import for the person who already has their tag list in a spreadsheet, because they usually do. And discovery, the auto-find on the network, is framed as an assist. It populates the form faster. It is not the source of truth. Discovery guesses. The human confirms.
What I would check, building an onboarding flow again: at every step, does the person know what is expected and whether they got it right, before it costs anything? If a field can be wrong, validate it against a schema. If a config can fail, fail it in front of the person who can fix it. If a starting point exists, offer it. But do not let a guess pretend to be a decision.
The surprise is that boring is expensive to build and cheap to use. That is the trade you want. The schema registry, the test path, the templates, the import, discovery as an assist. That is real work, and none of it shows up as a flashy feature. It shows up as a support call that never happens. The most sophisticated thing an onboarding flow can do is feel like nothing happened.
Notes for next time: build forms from the contract, not by hand, so the thing you validate and the thing you render are the same thing. Put the test button before the commit, always. Give people a way in that is not a blank page. Keep discovery honest about being a guess. Boring onboarding is not the low-effort version of the feature. It is the feature, done well enough that nobody notices.