The approach
Establish a baseline with usability testing.
Before any information architecture redesign work began, I ran usability testing on the existing navigation with participants representing the platform’s key user roles. Each role was given the tasks most critical to their work, so the baseline reflected real, high-stakes behavior rather than generic browsing.
This baseline study gave the team a measurable starting point, and it surfaced the specific pain points that would shape the redesign.
Inform the redesign.
Alongside the baseline findings, I reviewed competitor navigation patterns and functionality to identify conventions users would likely expect and opportunities to differentiate.
Redesign the IA and iteratively tree test.
As the new information architecture took shape, tree testing let us validate and refine the structure before it was built into a visual design, catching labeling and grouping problems early and cheaply.
Re-test with the same roles and tasks.
Once the redesigned navigation was ready, I repeated the usability study using the same user roles and the same critical tasks. Holding the study design constant meant any difference in performance could be attributed to the navigation itself, giving the team a direct, apples-to-apples comparison.
Usability testing was the linchpin methodology in this approach
Usability testing bookended this global navigation redesign. Because it pairs observable task performance with the reasons behind it, a usability study tells you both how well a design performs and why. This provides a solid grounding to both identify areas to treat differently in the redesign as well as to establish a baseline that you can measure against later. Repeating the testing after a redesign turns opinion (“the new nav feels better”) into evidence (“task success for [role] rose from X% to Y%”). And because it shows where the new design didn’t improve, it keeps teams honest about what still needs work.