From proposed navigation to migration confidence

We were comparing two models, not designing navigation from scratch

An existing network services product IA had accumulated over time.

It reflected several things at once:

UX had developed a proposed update with input from Product to make that structure more coherent before the move into the enterprise platform.

The research question was therefore not simply:

“How should we reorganize the menu?”

It was:

“Does the proposed model actually help users understand and navigate the product better than the model they already have?”

Users already struggled with closely related concepts.

Those problems could appear to be navigation issues, but the research suggested that several of them went deeper.

A wrong first click might mean two labels were too similar.

It might mean internal terminology had leaked into the interface.

It might mean two legitimate mental models were competing.

Or it might mean the product itself contained concepts whose ownership or relationship was unclear.

The migration created a useful decision point because it forced us to ask which of those problems we were comfortable carrying into a broader platform.

The comparison needed to tell us more than which tree performed better

I combined stakeholder interviews, tree testing, behavioral metrics, and iterative IA prototypes.

Each method answered a different part of the question.

Stakeholder conversations helped me understand what the proposed structure was trying to represent: architecture, ownership, terminology, expected migration behavior, existing workflows, and technical relationships.

Tree testing let me compare the existing and proposed models directly rather than evaluating the proposed IA in isolation. It helped me see where users hesitated, backtracked, selected the wrong destination, or used language that revealed a different mental model from the one represented in the navigation.

I tracked task success, completion time, first-click accuracy, and backtracking because I wanted to understand not only whether someone eventually arrived at the right place, but how predictable that destination felt.

That distinction became important.

A successful task completed after hesitation and recovery did not tell the same story as a confident first click.

The proposed IA was better in some places, not across the board

The comparison did not produce one clear winner.

Some tasks in the proposed IA showed stronger navigation efficiency and first-click performance.

Other parts of the model continued to create uncertainty.

An improvement in one section did not prove that the entire proposed structure was ready to become the new platform model.

The research instead revealed different levels of confidence across the IA.

Some sections were understandable enough to move.

Others still contained terminology, grouping, or conceptual problems that needed more work.

That made the proposed IA less useful as a single pass/fail artifact and more useful as a way to identify where the product was stable and where ambiguity remained.

Some navigation problems were really product-model problems

A technically precise label could still fail if users did not recognize the concept behind it.

A familiar label could create the opposite problem if it hid an important distinction in the system.

That meant the work could not be reduced to finding better words.

The navigation needed to help users predict where an object, action, or task belonged.

When it could not do that reliably, I treated that as a signal to investigate the underlying concept rather than immediately trying another label.

The research changed how we thought about migration readiness

The migration timeline created pressure to finish the navigation and move the entire experience into the enterprise platform.

Research suggested that would create false certainty.

The proposed structure was more stable in some areas than others.

With a short research window, a small participant sample, and limited time for additional validation, I did not think the responsible recommendation was to keep iterating until every section appeared finished.

Instead, I separated the navigation between enough confidence to move forward versus more discovery needed.

That was a tradeoff between migration completeness and migration confidence.

Completing the full IA might have created a cleaner delivery story.

It also would have asked the organization to commit to decisions that the research had not fully supported.

Holding work back was part of the design decision

The research changed the migration roadmap.

That meant UX influenced:

For me, that was an important part of the work.

Design does not always create value by resolving everything before a deadline.

Sometimes the more useful contribution is identifying where the team understands the problem well enough to act and where it does not.

That gave the team a clearer basis for deciding what it could responsibly scale.