Users weren't searching for SEL products by name—they were searching by what they needed.
Customer feedback and surveys made this clear in 2024, prompting SEL's global sales team to rethink how products and services were positioned. The existing navigation was built around product names and types, but users wanted to browse by functional need or industry. The gap between how the site was organized and how users actually thought was the real problem this project set out to solve.
The Assumed Problem
The project brief framed the challenge as a navigation update to support a new content strategy — the sales team had developed a revised product taxonomy organized around industries and functional needs rather than product names, and the nav needed to reflect that.
What changed the framing
The real scope of the problem became clear during initial wireframing. When I began cross-referencing the new taxonomy against the existing site structure, it was immediately apparent that the nested hierarchy of the current navigation couldn't accommodate it. The content had changed too fundamentally — what looked like a UI update was actually an information architecture problem. The existing nav wasn't just visually outdated, it was structurally incompatible with how the business now needed to position its products and how users actually looked for them. That realization shifted the project from a reskin to a ground-up navigation redesign.

Design Decisions and Tradeoffs

Early competitive research and a UI audit surfaced the mega-menu as the strongest structural pattern for the volume and hierarchy of content SEL needed to surface. It could accommodate multiple content types — products, industries, services, forms — within a single interaction layer without burying users in sequential drill-downs. Several directions were explored in wireframing before the mega-menu emerged as the clear fit.
A significant constraint shaped the entire design process: the new taxonomy had been developed by a cross-functional group of program managers, product engineers, and sales and customer service teams — without design or web included. By the time we received it, the IA was fixed. This meant the navigation had to accommodate a taxonomy that hadn't been stress-tested against the realities of web UI patterns.
In practice this surfaced as subtle but meaningful inconsistencies — slight differences in nesting depth and hierarchy across different sections of the menu. Rather than forcing a single rigid template onto content that didn't quite fit it, I worked to establish the most consistent patterns possible across sections while handling edge cases individually.
The tradeoff was real: both design and development absorbed more custom work than a cleaner, more uniform taxonomy would have required. It also meant development had to build for a higher number of minor variations rather than one repeatable component pattern.
Designing in parallel for two content scenarios — Industries and Solutions — added another layer of complexity. The content team hadn't finalized which would launch first, so both needed to be fully resolved in the spec simultaneously. The goal was to ensure either could go live without requiring a design revision, which meant the underlying interaction model had to be flexible enough to support both without appearing like a workaround.


Once the direction was approved, I translated the design into detailed Figma specs and high-fidelity prototypes covering all interaction states, transitions, and responsive behavior across desktop, tablet, and mobile. Throughout development I worked closely with the engineering team to answer questions quickly and keep the spec updated as implementation decisions evolved — particularly important given the number of custom scenarios the taxonomy inconsistencies introduced.
The Lead Capture Forms
As part of a broader lead-gen initiative, the account management team requested embedded contact forms within the navigation. The design challenge was fitting a functional, conversion-focused form into the constrained space of a mega-menu panel without disrupting the navigation experience. The underlying hypothesis was straightforward: a form embedded within a contextually relevant section — Industries or Services — would outperform a generic contact form because the user's intent is already signaled by where they are in the nav. Someone browsing the Industries section isn't a general visitor, they're a potential customer with a specific application in mind.
Since launch, the navigation forms have generated 3,926 submissions associated with $2.65M in related opportunity value. The data validated the hypothesis: the Industries and Services forms showed significantly higher task creation rates — 75.8% and 60.7% respectively — and stronger new contact rates than the general support form. Users reaching contextually relevant entry points converted at meaningfully higher rates, reinforcing the case for organizing navigation around need rather than product name.

Reflection
Some design feedback received after the handoff to development highlighted opportunities for a more holistic approach earlier in the process. The original menu concept featured a panel that slid in from the left and spanned the full height of the viewport. Late feedback requested that the menu height instead hug its content—a change that initially appeared minor but ultimately required developers to restructure significant portions of the component mid‑build.
This change also surfaced a secondary issue: with the menu no longer anchored on three sides, sliding in from the left edge felt unnecessary. In hindsight, a dropdown transition—floating down from the navbar rather than animating from the viewport edge—would have been a more appropriate interaction model for the revised layout.
While the development team successfully executed the design, this experience reinforced the value of earlier collaboration. Developers were brought in once design directions had been narrowed, but involving them earlier—during wireframe and concept exploration—could have surfaced structural concerns sooner and reduced rework later in the process.