Restructuring Navigation for a Wealth Advisory Platform

What problem existed?

The platform’s navigation was straining as new integrations landed. A single left rail held three different kinds of things at once: places to view, actions to take, and multi-step workflows. It auto-collapsed without giving the advisor a way to keep it open, and treating actions as navigation items meant the rail grew longer with every feature that shipped.

The structure also did not match how advisors think. Advisors picture an account as belonging to a client, but the system treated clients and accounts as separate entities, so reaching an account often meant leaving the client you were already looking at.

Why did it matter?

Navigation is the surface every task runs through. When places, actions, and workflows share one list, an advisor scans the whole rail to find anything, and the structure gets harder to read with each integration. Several large integrations were already scheduled, so a model that strained at the current size was not going to hold.

The mismatch with how advisors group clients and accounts added friction to the most common path in the product. Getting the structure right decided whether the platform scaled or needed rework with every release.

What constraints existed?

• Several large integrations were already scheduled, so the model had to absorb new surfaces without restructuring each time.
• The platform was white-labeled. Heavy dark theming caused problems for firms that wanted a clean light presentation, and combining a dark nav with light page bodies created technical friction.
• Advisors work on desktops and large monitors, which shaped how much navigation could stay persistent.
• The actions and workflows already existed. This changed where they lived and how they read, not what they did.

What role did I play?

I led the project as the platform’s lead product designer, and I opened it collaboratively. I ran a design-thinking workshop with two design directors, the head of design, and the research, content, and design-system teams to set direction before committing to a structure.

The workshop produced the strategy; I owned the execution. I worked through the information architecture, the interaction patterns, and the high-fidelity design as the individual contributor, and took the design into the frontend so the developers could review feasibility and cost in parallel.

What options were explored?

The workshop converged on three moves:

• Separate navigation from action. The rail holds navigable places; contextual actions move out of it, so the structure stops growing every time a new action ships.
• Nest accounts in the client context. Accounts load inside the client they belong to, with a fixed header showing the relationship. Most North American advisory clients hold only a few accounts, typically two to four, so an account menu can give advisors a quick snapshot and a direct jump to the right one, matching how they reason about a book of business.
• Give the advisor control of the rail. Keep it open by default, with a deliberate collapse, rather than collapsing on its own.

The most involved exploration was a smart action panel: a searchable command surface that adapts to the current page, the advisor’s permissions, and frequent actions, with keyboard shortcuts for advisors who move fast.

What tradeoffs were considered?

The central tradeoff was persistence versus space. A rail that stays open is always available but costs screen width on dense advisor pages. Because research showed advisors work on large monitors, I kept the rail open by default and moved sub-items like documents and holdings into in-page navigation, which freed the rail to carry only top-level places.

Moving actions into a panel asks an advisor to learn one new surface. In exchange, the rail stays stable as the product grows, and frequent actions become faster through search and shortcuts than hunting a menu allowed.

How did UX, engineering feasibility, and business strategy intersect?

The redesign reused existing actions and components in a new structure, so it changed how the platform felt without a heavy build, and I shared the high-fidelity design with engineering as I worked so feasibility, cost, and timing were judged in parallel rather than after the fact.

The dashboard showed the same intersection. It is the advisor’s first screen and a business surface. The redesign turned an evenly weighted set of color-coded alerts into a prioritized task list that combines alerts, workflows, and insights, and added configurable visualizations like firm health and peer comparison for advisors in management roles.

How was the design researched and validated?

Research ran alongside the design rather than before it. I worked with the research team on a mixed-method study, pairing discovery interviews with co-creation sessions to understand how advisors picture clients, accounts, and their daily work. Those sessions surfaced the account-in-client model clearly enough to commit to it.

For the alerts specifically, I directed studio designers to build an interactive prototype and worked with research on the script and the assumptions to test. Advisors told us they wanted simple, prioritized alerts with aggregation where it helped, which is what the dashboard became. The high-fidelity navigation tested well in the same sessions.

What was learned?

The useful question was what each item in the rail actually is: a place, an action, or a workflow. Once they were sorted, the structure followed, and the rail stopped being the thing that broke with every integration.

Research changed the work rather than only confirming it. Co-creation made the account-in-client mental model concrete enough to design around, and the alerts testing turned a hunch that they overwhelmed advisors into a specific direction: prioritize, then aggregate.

What was the outcome?

The navigation moved from one mixed rail to a structure built to scale:

• A places-only rail, user-controlled, with sub-items moved into in-page navigation.
• Accounts nested in the client context, with a fixed header showing the relationship and a streamlined set of items.
• A smart action panel with search, page-aware suggestions, and keyboard shortcuts, in place of actions embedded in the nav.
• A prioritized dashboard that aggregates alerts and surfaces insights tied to the advisor’s book of business.

The navigation and dashboard work went to the development and product teams for review, with a roadmap to move from the current platform to the new structure in step with business priorities.