T-CETRA's First Card Sort
None of the business, tech, or project management team had used a card sort before.

It's always difficult to present UX research to business and to hammer home concepts like "you are not your users" when they don't have first-hand experience with the methods, so I roped a few business team leaders and customer service reps into participating in a card sort exercise over lunch.

Later I would present their results (and the current nav structure) side-by-side with what users chose themselves when given the opportunity. We ran two card sort studies externally with similar user groups, one open and one closed.

Findings
Our internal business participants identified something in their key practice area that could be improved. Usually that meant surfacing a specific link or feature more obviously, but left most of the other nav "as-is".

Our external users simplified the menu tree and forgot to place or skipped tools and features they didn't use frequently. Many put together a menu tree that looked more like a flat list of everything they recognized by name, but nothing else. Several indicated they normally just clicked on icons and barely remembered what the text read or what the tool was called. (We noted this for later - more images and bigger icons!)

It was tricky to take a clear-cut conclusion from the small samples and contradictory placements.
 Key takeaway: users tended to be laser-focused on things relevant to their specific needs. 
 If we could find a way to highlight key items on a contextual, per-user basis - the rest of the nav could be complex without hindering usability. 

Ideally, we would run this with bigger groups and start tree-testing some of our outputs to really put some quantitative groundwork underneath the decisions.
In practice, it was time to go visit the VP of Software Development and Lead Architect to see how viable dynamic information in menus would be.

Tuning and Testing
It was important to move into prototyping at this stage for a few reasons:

I planned to usability test the new menu concept to vet it's performance, but it would be difficult to get accurate user judgements on "feel" and "speed" without having all the interactions in place. Hover-expand, page-to-page transitions, possible target size or cursor movement issues - although we could show static screens or wires to get an initial opinion, it seemed prudent to test at a similar level of fidelity to the UI users would already know to prevent false negatives.

The more important piece was that ... I didn't know yet how those same interactions - hover animations, active and focused states, etc. - would behave, because we didn't have a precedent in the design system at this point for sub-menus. Prototyping at high-fidelity would be a good way to establish our animation for menus and wouldn't be overly taxing because of the limited scope of the menu.

Prototype Ready
Our test-ready design expanded the menu background container to full-width, re-stacked the mobile version's sub-sections, integrated more images and icons, and brought in more divider lines.

We prepared "widget" space in the layout to provide marketing or business a predicatable asset and to forestall big changes to the site nav itself later down the line to promote something.

I negotiated with the tech team to prepare step-by-step improvements to our data handling; we could start with static "top products" that would be the same for all users and expand to dynamic for all, dynamic for groups, and finally dynamic for each user.

The vertical columns of the mega-menu gave us good mobile wrap points and some potential for future product expansion, and the grid layout always saved room on the right margins for tags like "NEW".

Prototype Limitations
Our approach with XD components did lead to some sluggish response and issues with hover targets, but the prototype was smooth enough to test basic behavior on some users in controlled environments.