Optum runs 19 separate customer-facing properties across two audiences. Each grew on its own timeline, with its own header, footer, sign-in, and information architecture. Meanwhile four initiatives (mega-nav updates, the AI Marketplace, Optum AI, and a platform migration) were all touching navigation at once, without a shared model between them.
What sounded like a navigation redesign was really a much bigger systems problem.
How do you create one shared experience without forcing nineteen very different properties into the exact same box?
01 The real problem
Different product teams had solved navigation in different ways.
Some products had multiple rows of navigation. Others had deeply nested menus. Some needed access to several Optum products, while others had highly specialized workflows.
Individually, many of those decisions made sense. Together, they created a fragmented ecosystem.
Users had to relearn navigation as they moved between products. Teams were solving the same problems repeatedly. Valuable screen space was disappearing under layers of navigation. And there was no shared pattern that could scale across the portfolio.
What the audit actually found
16/103
Optum for Business nav links pointing to a different domain. Twelve of the sixteen sat three levels deep.
10/27
On Optum Personal. Half of them at the top level, half buried two levels down.
5/200
AI Marketplace. Two hundred nav links, and only five of them leave the property.
5+
Separate sign-in portals scattered across the Business navigation. Users re-authenticated two or three times inside a single task.
Five properties audited link by link. The counts mattered less than the shape they revealed: cross-property movement existed everywhere, was inconsistently placed, and nobody owned it.
The sign-in fragmentation was the finding that changed the conversation.
On the Business side, login was spread across five or more portals reached from different points in the nav. On the Personal side, the sign-in dropdown offered four audience buckets (individuals and families, providers and organizations, employers, brokers) which directly contradicted the Personal and Business split sitting one level above it.
So the same user was being asked to declare who they were twice, in two different vocabularies, and the answers did not match.
We didn’t need a prettier menu.
We needed a system.
02 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.
03 The uncomfortable question
How much flexibility can you allow before a standard stops being a standard?
Make the system too rigid and products with complex requirements can’t use it.
Make it too flexible and every team customizes it until you’re right back where you started.
So instead of trying to design a navigation that handled every possible scenario, I focused on defining a stable global layer with intentional flexibility underneath it.
We weren’t designing one giant navigation to contain everything. We were defining what belonged to the Optum ecosystem and what belonged to the individual product.
04 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.
05 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.
06 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.
07 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.
08 Three directions
Not three visual treatments of one idea. Three different answers to where cross-property movement should live, each with a different governance bill attached. Rebuilt here in HTML from the wireframes.
Option A Personal and Business mega nav
Leads with the audience split that already exists. The mega menu swaps entirely on toggle.
Lowest change cost, because it extends what teams already understand. Also the least ambitious, and it inherits the audience-segmentation risk the research warns about.
Option B Cross-site app switcher
Treats the properties as an ecosystem of applications, with a launcher to move between them.
Switch to another Optum experience
Peach: Personal sites. White: Business and professional sites. All 19 destinations in one launcher.
The cleanest separation of concerns, and the biggest bet on discoverability. Strong for signed-in users, weak for first visits.
Option C Hybrid with contextual sticky nav
Audience toggle, launcher, and a page-scoped sticky bar for long pages. Most flexible, most to govern.
Home › Health care made easy
The most capable and the most expensive to police. Recommended as a scoped addition to A or B, never as the default.
Every option was buildable.
They just cost different amounts to keep honest.
09 Gaps
Each of these left discovery as a written requirement handed to Product and Engineering, not as an observation in a deck.
G1
The Personal sign-in offers four sub-audiences, which contradicts the Personal and Business toggle one level above it.
G2
Login is scattered across five or more Business portals. Users re-authenticate two or three times inside a single task.
G3
Business has 16 of 103 links pointing off-domain, Personal has 10 of 27, and the same utility items live in different places on each property.
G4
It forces users off-site to find their next destination. Flagged as the primary context break on every property audited.
G5
The legal row is consistent. Everything above it has no shared taxonomy.
G6
Is search site-only or ecosystem-wide? There is no signal to the user either way.
G7
The Personal dropdown links to Business sign-in paths, mixing audiences inside one property.
G8
The audience toggle moves, or is missing entirely. One property has no toggle at all.
G9
Cross-property paths are untrackable, so nobody could prove how often this was actually happening.
G9 is the one I would fight for first.
Without cross-property analytics, every conversation about this work runs on conviction. You cannot show how many people are making these journeys, so you cannot price the fix, and a project with no price is a project that gets deferred.
10 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
Healthcare solutions to support a more modern, connected system
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.
And on a phone, where there is no room to negotiate
Health caremade easy
The collapse rule: the global layer folds into the drawer in a fixed order, identically on every property, so no product team has to decide what to sacrifice first. Cross-ecosystem movement (Optum Personal, All sites) sits at the top of the drawer rather than being dropped, because that is the one thing a product cannot provide for itself.
Resting state. The nav takes a thin band and hands the page back.
A separate component I designed: an in-page audience switcher that lets one page serve six buyer types. It does the segment work locally, so none of it has to be duplicated in the global layer.
11 Governance
Designing the shell was the smaller half of the job.
The moment a component is used by nineteen properties, it stops being a design and becomes infrastructure. Every team that adopts it inherits your decisions, and every team that needs an exception is asking you to change something eighteen others already depend on.
So the real deliverable was a set of rules, and a speed. Teams will route around governance that is slower than shipping. The tiers exist so that a label change does not wait on a design council, and a new top-level pattern cannot skip one.
Change classification
| Tier | What changes | Who approves | Turnaround |
|---|---|---|---|
| T1 · Content | Label copy, a URL swap, reordering inside an existing column | Property team plus a UX review | 3 days |
| T2 · Structural | A new top-level slot, a new utility item, a footer column change | Working group plus the product lead | 10 days |
| T3 · Ecosystem | A new top-level pattern, a new component, or any change to the audience model | Steering plus the design council | 4 to 6 weeks |
Who owns what
| Global nav pattern | UX, with design leads. Accessibility consulted. |
| The component itself | Design systems engineering. Web engineering accountable. |
| Content inside the shell | The property product team. |
| Cross-property registry | Programme office. |
| Footer legal row | Legal and compliance. Not negotiable. |
| Analytics taxonomy | Digital analytics lead. |
Cadence
| Weekly | Working group: UX, engineering, product reps, accessibility, analytics. |
| Monthly | Steering: product leadership, design, brand. |
| Quarterly | Metrics review and a pattern library refresh. |
| As needed | Design council sign-off before any tier three ships. |
Lightweight during discovery and designed to scale up as the work moves into build. Governance that arrives at full weight on day one gets ignored on day two.
Without this, a shared pattern quietly forks. One team needs an extra link, another needs a different label, and in eighteen months you have nineteen variations again, except now they all look similar enough that nobody notices.
The pattern was the easy artifact.
The rules and the SLA were the deliverable.
12 Pressure test
A system can look beautifully consistent when you test it against three carefully selected examples.
Thirty products are much less polite.
We pressure-tested the pattern against different product structures, navigation depths, user needs, and edge cases.
Every exception forced the same question:
Is this exposing a flaw in the system, or is this truly a product-specific need?
That helped refine the pattern without designing around every exception.
The goal wasn’t to create the perfect Figma file. The goal was to create something teams could actually build from.
13 Outcome
The work progressed from a fragmented current state into three costed directional options, a documented set of journey-driven requirements, and a governance model, all handed to Product and Engineering for the build phase.
It was not live when I left, so I have no adoption numbers to show you, and I would rather say that than dress up a chart. What I can point to is the artifact: a pattern, a set of rules, and documentation that survived every review it went through.
The outcome I care about most isn’t the number of sites.
It’s that teams no longer have to approach the same problem as if they’re starting from zero. We created a foundation they can build from.
14 Reflection
Large systems rarely become complicated because someone made one terrible decision.
They become complicated because hundreds of reasonable decisions accumulate over time.
That means simplifying them isn’t about walking in and deleting things. You have to understand why the complexity exists first. Then you can decide what deserves to stay.
And yes, sometimes the answer really is one less navigation bar. :)
What I’d do differently
I would bring more representative product teams into structured validation earlier.
We gathered a lot of input throughout discovery, but with a system this large, I learned how valuable it is to test emerging rules against the strangest edge cases sooner.
The weird cases are often the ones that tell you whether you’ve actually designed a system.
15 My contribution
Helped frame the problem beyond a visual navigation redesign.
Worked across teams and stakeholders to understand requirements, workflows, constraints, and existing patterns.
Separated global ecosystem needs from product-specific needs and helped define the rules connecting them.
Explored how global and local navigation could coexist without creating additional complexity.
Turned concepts into experiences teams could react to, test, and pressure-test.
Worked closely with product, design, business, and engineering to move from competing requirements toward a shared direction.
Audited five properties link by link, counting cross-domain paths by navigation level, and traced sign-in fragmentation across the portfolio.
Studied how five other multi-property companies solve audience navigation, including the research that argued against our leading direction.
Wrote the change classification, approval routes, service levels, and ownership model for a component consumed across the portfolio.
Stayed close to implementation so the final direction wasn’t just theoretically scalable. It had to work in the real product ecosystem.
Those are usually the interesting ones.