From fragmented onboarding to a scalable network-device framework

The interface was exposing a systems problem

The original experience made users think in terms of tools.

Their actual job was much broader.

A user might need to collect device information from a customer, confirm prerequisites, prepare hundreds or thousands of records, validate the file, determine which systems each device belonged in, submit the batch, monitor progress, isolate failures, correct the data, resubmit only what was needed, and return later without losing context.

The existing experience fragmented that work, users could not confidently answer basic questions:

The UXI journey evaluation showed unclear guidance, weak feedback, hidden system state, confusing actions, and declining usability as stored inventories accumulated. Interviews added the operational reality behind those interface problems.

The platform was also expanding beyond one system.

Each additional destination introduced different APIs, identifiers, prerequisite data, and validation logic.

The opportunity was larger than improving one interface.

It was to create a stable user-facing model that could absorb changing technical complexity underneath it.

The real workflow crossed tools

Research showed one continuous job:

Internally, onboarding was often discussed as separate implementations. Users did not experience those as separate product problems. They experienced a single job whose state happened to span multiple systems.

The core question became: How should onboarding behave as one coherent service when the destinations, validation rules, and technical dependencies can change underneath it?

Research had to work at two levels: the user journey and the architecture

I could not define the interface responsibly without understanding the service behind it.

Architecture and engineering were simultaneously working through the technical and operational constraints required to support a scalable service.

I used service blueprints, story maps, journey artifacts, and research synthesis as working tools in those conversations.

They gave us a way to look at system behavior and the user's JTBD in the same frame.

That mattered because the architecture was still taking shape. Rather than add the user perspective after technical decisions had already been made, I could bring it into the discussions while those decisions were still open.

What the evidence changed

The research validate the direction and changed specific assumptions.

One of the clearest examples involved system state.

Users could not reliably distinguish between uploading information, validating it, and actually onboarding the devices.

That meant these could not behave like one generic “submitted” state.

The experience needed to show where the batch was in the process and what had or had not happened yet.

Partial failure changed the model in another way.

At enterprise scale, a batch containing hundreds or thousands of devices would not always succeed as one unit. Some devices might pass while others failed because of missing prerequisites, invalid values, duplicates, or destination-specific rules.

Failure recovery was therefore not an edge case.

It was part of the primary workflow.

That made failed-device counts, tool-level errors, actionable recovery, and safe retry behavior core parts of the framework.

An assumption in the early framework was wrong

Early concepts assumed that devices would generally be onboarded to all supported systems.

Research showed that real-world environments varied: devices might already exist in one destination and only need to be added to another.

Research did not only help me refine the original model. It showed where the original model was wrong.

I created a phased strategy instead of designing an idealized future state

We could not jump directly from the existing experience to fully automated orchestration.

The technology and workflows were still evolving. I needed to create a direction that could improve the experience now.

I organized the work into three horizons.

Phase 1 — Improve the existing experience

Address immediate high-level usability problems in the current flow.

Phase 2 — Create a guided onboarding experience

Establish a more predictable “happy path”. Make prerequisites explicit, surface validation results, provide clearer actions when something fails, and strengthen notifications and system feedback.

Phase 3 — Build the scalable framework

Move from onboarding into one tool toward a reusable multi-tool service.

The phased strategy gave the team somewhere practical to start while preserving the direction of the larger service.

Building the framework meant deciding where complexity belonged

The most consequential design decisions were not about putting more capabilities into the platform.

They were about deciding which complexity the product should own, which complexity the system should absorb, and which work users were already better equipped to do elsewhere.

That distinction became especially important around bulk data.

Stakeholders wanted to move users away from Excel. I chose to work with it instead.

There was understandable pressure to keep more of the workflow inside the platform.

The thinking was that if users needed to manipulate onboarding data, the application should provide those capabilities rather than send them back into Excel.

But users were already highly practiced in Excel.

They knew how to manipulate large datasets quickly. Trying to force that behavior into the platform meant asking them to abandon a mature workflow for a less capable one, while the product began competing with software specifically designed for that kind of work.

That was already contributing to unnecessary friction and errors.

I did not think the right answer was to retrain a deeply established user habit simply so the entire workflow could live inside our product.

I conducted a deep study of advanced table patterns and the capabilities users needed while reviewing onboarding data.

The platform needed enough table functionality for users to understand the state of their onboarding work without constantly leaving the experience.

That led me to support things such as inspecting complete row values in a side drawer without losing table context, adding or removing columns, sorting, and showing status directly in the table.

Additional capabilities surfaced through research were documented for future iterations.

I drew the boundary at complex bulk manipulation.

When users needed sophisticated data editing, Excel was already the better tool.

So instead of trying to replace it, I designed the workflow around it: export validation results, make complex corrections in the familiar spreadsheet workflow, and reimport the updated information.

The application could focus on the onboarding workflow. This gave us a clearer product boundary and avoided forcing users through a weaker editing experience.

Automation could not become a black box

Users wanted less manual work, but simplicity could not come at the cost of trust.

They still needed to know what the system was doing, where their devices were going, what stage they had reached, what failed, and what they were expected to do next.

So I designed automation together with explicit system states, destination-level status, notifications, and recovery actions.

The goal was to reduce effort without reducing confidence.

We standardized the mental model, not every implementation detail

The destination systems did not behave identically.

They had different APIs, identifiers, validation rules, prerequisites, and failure modes.

Trying to hide every difference behind identical system behavior would have created another kind of abstraction problem.

Instead, we created a common user-facing lifecycle while allowing tool-specific validation, errors, and service behavior underneath it.

The consistent part was the user's understanding of the journey:

Where am I? What happened? What failed? Where did it fail? What can I do next?

For this workflow, a clickable prototype was not enough

As the framework became more sophisticated, a click-through prototype was not enough.

Using my development background, I built coded prototypes for usability testing and cross-functional collaboration.

Participants could interact with more realistic behavior which helped expose assumptions and edge cases earlier. It gave product, architecture, and engineering something more concrete to react to when discussing how the framework should behave.