Optum runs 19 separate customer-facing properties across two audiences — personal and business. Each grew on its own timeline, with its own header, footer, sign-in, and information architecture. I led discovery and strategy to bring them under one consistent navigation shell, without forcing nineteen very different properties into an identical box.
The ask kept surfacing as “redesign the menu,” but the real issue was fragmentation. Product teams had solved navigation differently for years, so users were relearning it every time they moved between properties.
An audit of five properties found the same pattern everywhere: cross-property links buried three levels deep, sign-in scattered across five or more portals, and nobody owning the connective tissue between products.
Where we started: the existing Optum for Business homepage, three stacked bands deep before a user reaches any content.
I worked across product, design, and engineering to separate “we’ve always done it this way” from what users actually needed, then defined six guiding principles to settle the arguments before they started:
From there I tested how much a single navigation band could actually carry, iterating from a stripped-down logo-and-sign-in bar to a fully loaded single row. The pattern that worked split the ecosystem layer from the product layer: product navigation keeps the reading position and room to grow, while a lightweight global cluster — audience toggle, all sites, search, sign-in — floats above it, costing each property almost nothing.
I costed three directions for where cross-property movement should live, from a mega-nav extension to a full app switcher, and recommended the one that solved the sign-in fragmentation without over-engineering the rest.
Discovery
This was not a project where I could disappear into Figma for a week and come back with a clever solution.
There were too many products, teams, users, technical constraints, and legitimate exceptions.
So I started by listening.
I worked across product, design, engineering, and business teams to understand how navigation was being used today and what each product actually needed from a global system.
The interesting part was separating:
“We’ve always done it this way.”
from:
“Our users genuinely need this.”
Four phases, sequenced so each one earns the next
01
Convene the working group. One problem statement, one scope, agreed success criteria.
Where we were02
Current-state journeys across properties. Surface every continuity gap and every repeated pattern.
Next03
Directional concepts, IA rules, and the governance model.
Next04
Journey-driven requirements to Product and Engineering for design and build.
LaterWhat this work was
What it was not
Being explicit about the second column mattered as much as the first. On a project this visible, everyone arrives with something they hope you are also solving.
Principles
Not a values slide. Each one exists to settle an argument I knew was coming, so the argument could be settled once instead of nineteen times.
The global nav is a shared shell. Property teams own the content inside it, within the contract.
Personal and Business is the primary wayfinding signal, not the product name. It lives at the top level.
WCAG 2.2 AA minimum. No product exception overrides accessibility. Ever.
Every pattern has to be authorable in the CMS. If content authors cannot use it, we cannot govern it, so it will drift.
Audience, sign-in, and task state survive movement between properties. This is the whole point.
Cap primary navigation at five to seven items. Use depth for density, never breadth.
The fourth one saved the most time.
A pattern nobody can author is a pattern that quietly forks.
From requirements to a pattern
19 Optum properties
Patterns
Shared requirements
Global navigation system
My job wasn’t to make 19 properties identical.
It was to find the part they could share.
Precedent
Five multi-property companies solving audience-specific navigation at scale. I was looking for what to borrow and, more usefully, what it cost them.
| Company | Pattern | What it does | What it told us |
|---|---|---|---|
| Salesforce | App Launcher | A grid icon surfaces the seven most-used apps, with View All for the full catalogue. Visibility is permission-based, so users only see what their role unlocks. | Precedent for a launcher. Reduces load, allows user-controlled ordering. |
| Microsoft Dynamics | Persona-mapped nav | Role-to-persona mapping auto-configures the sidebar per user. Batch configurable for enterprise scale. | Validates an audience toggle. Assign the persona once, let nav adapt. |
| Cisco | Cross-platform navigator | One login across four products. Shared header, and feature navigation that compares across them. | Closest model to ours. Federated header plus single sign-on across all 19 properties. |
| AWS | Multi-account role switching | Up to five identities in one browser, with colour cues and history. Switcher lives top right. | Power-user pattern for people who genuinely need both Personal and Business at once. |
| Epic and Cerner | Role-segregated portals | Patient portal and provider portal are separate products. Different terminology, workflows, and navigation over the same data. | Healthcare precedent for splitting. Separate structures when audience goals differ fundamentally. |
The finding that argued against us
Segmenting a site’s navigation by audience often degrades usability, because users belong to more than one category, or cannot tell which one they are.
That is Nielsen Norman Group, and it points directly at the audience toggle sitting at the centre of our leading direction.
I put it in the deck rather than leaving it out. It reframed the toggle from a settled decision into a thing we had to earn: it only works if the two audiences have genuinely different goals, if the labels are unmistakable, and if choosing wrong is cheap to undo. Our audit supported the first. The other two became requirements.
Header studies
Before the three strategic models, a narrower question: how much can one header hold before it stops working? Rebuilt in HTML from my own exploration files. Same structure, same content, redrawn rather than screenshotted.
Where we started The existing Business header
Three stacked bands before a user reaches any content: an audience strip, a brand and utility row, then the product nav. Every band is defensible on its own. Together they take a fixed slice off the top of 130 properties.
01 Strip it to almost nothing
Borrowed from a pattern I had been studying. Brand, a switcher, and one action. It gives nearly all the vertical space back.
It also gives up wayfinding entirely. Users could no longer see where they were or what else existed.
02 Put the audience in a dropdown
One row. The audience becomes a control next to the logo, and the utility cluster carries location and language.
The audience switch is the highest-consequence choice on the page, and a dropdown is where people stop looking.
03 Two rows, tuned for Personal
Audience as underlined tabs with location and language beside them, then brand, then three service buckets.
It worked for Personal and fell apart for Business, which has more sections and a conversion action to carry.
04 One row, tuned for Business
Everything on a single line: audience selector, five sections, full utility, and the primary action.
It fits until a label gets longer or a section gets added. A pattern that only works at one content length is not a pattern.
05 · Selected Split the global layer off the product line
The move that resolved it: stop making the ecosystem and the product compete for the same horizontal band. Product navigation sits left, in the reading position, and can grow. The global layer becomes its own cluster: audience toggle, all sites, search, sign in, support, and the action. Two owners, two regions, one row of height.
One ecosystem on top. Product flexibility underneath.
The solution
The global navigation establishes the shared Optum layer. It gives users a consistent way to understand where they are, move across the ecosystem, and access common destinations without consuming the space individual products need for their own work.
Underneath that layer, products retain the flexibility to support their specific workflows.
That separation was the key. It gave us consistency without pretending every Optum product was the same.
Where it landed
The last mock I made. Three stacked bands became one floating shell that sits over the page rather than pushing it down. The audience toggle moved out of the permanent header and into the launcher, the utility row collapsed into a single Support link, and the primary action took the brand colour so it reads as the one thing to do. Everything a product team owns starts immediately underneath.
A fixed slice of every page came back to the property. On long enterprise pages that is the difference between content starting above the fold and below it.
Sitting over the hero rather than above it means the shell costs the page almost nothing, which is what made it acceptable to nineteen teams at once.
Previously there were five or more entry points competing in the header. Now there is one, and it is the only orange thing in the shell.
Discovery and strategy wrapped with a documented pattern, journey-based requirements, and a governance model — who owns what, and how changes ship — handed off to product and engineering for build. It wasn’t live when I left, so I don’t have adoption numbers to show. What I’d point to instead is the artifact: a shared foundation nineteen teams could build from instead of solving the same problem again from zero.
Those are usually the interesting ones.