Design systems · Modern Health · 2022

One navigation system, globally adopted

Launching global navigation in the design system enabled faster time to live.

Before: every product had its own navigation

After: one system that adapts to every screen size

Challenge
Five products, seven different navigations.
My role
Staff Product Designer, leading design in partnership with engineering.
Scope
5 web properties, plus iOS and Android apps.
Team
1 designer, 1 engineer, 5 product teams.
The systemic move
One configurable system, not seven fixes.
Outcome
Reusable components across all 5 web properties and both native apps.

The problem

The request was local. The cause was systemic.

  • Customer-facing and provider-facing teams both asked for search.
  • Every product had its own header, so each change started from scratch.
  • The real question: how do we make any navigation change cheap, consistent, and accessible?

What the audit found

  1. Problems making changes to navigation
  2. Disconnect from information architecture
  3. Accessibility issues
  4. Design inconsistencies
  5. Lack of shared resources
  6. Brand inconsistencies
  7. No agreed usability best practices
The audit: every product had its own navigation.

The approach

Tie the design-system roadmap to the product roadmap.

I framed it as a business case tied to the product roadmap, so it became a roadmap initiative, not a “nice-to-have.”

  1. February

    Exploration

    Design audits and problem scoping.

  2. March

    Concepts

    Design specs, product use-cases, and product alignment.

  3. April

    Build

    Layout library, componentization, and integration.

  4. May

    v1

    The first production release, live to a subset of users: Search in Member web, using the new global navigation.

Success metrics:

  1. Global components available in v1 within 4 months.
  2. Product team A (Client Experience) launches Search within 1 sprint after v1.
  3. Product team B (Member Experience) launches Search within 2 sprints after v1.
  4. All teams adopt the new components within 1 quarter after v1.
The first use-case that drove the roadmap: Search as a slot in the navigation.

Competitive Analysis

I studied Blue Shield, Rippling, Airbnb, Kayak, Shopify, and Red Hat to learn the principles behind their patterns.

Our navigation, annotated next to how others solve it. Open to scroll the full audits.

Design decisions

Three decisions, and why I made each one.

Build one system instead of patching each header

Alternatives
Fix each navigation in place. The existing code was too tangled to build on.
Why this
The audit found the same root causes everywhere: no IA connection, uneven accessibility, no shared resources. Separate fixes would drift apart again.
Tradeoff
A slower first launch, and the question “why all surfaces?” We showed that one navigation serves many purposes, and teams backed it.
Header iterations across themes, states, and menus.

Treat Search as a navigation item that collapses by breakpoint

Alternatives
A bespoke Search bar per product, or a fixed search field that always takes the same space.
Why this
Search drove the work, but it won't be the last special case. As a slot, it shipped in 1–2 sprints, and future items can too.
Tradeoff
Each breakpoint is another state to specify, build, and QA.
Search collapses by breakpoint, ending in a “More” menu.

Let teams configure navigation as data, not redesign it

Alternatives
Hand-built variants for every product, or a single fixed navigation for everyone.
Why this
One shared structure (sections, headings, dividers, items), so teams can change navigation without a design ticket.
Tradeoff
Anything outside the structure goes through the design system.
Menu spec: properties, and the data that configures them. Open to scroll every state.

Working with engineering

Design and engineering owned the component together.

  • Figma and code share names, properties, and tokens, so decisions hold in both.
  • Feasibility was a design input from the first concept, not a late review.
  • Storybook is the source of truth for behavior. Figma is the reference for designers.
  • Accessibility was specified: tab to the trigger, arrows between items, Enter to activate.
Figma and code share styles and tokens. Both feed Storybook and product code.

Documentation shipped with the code

Usage guidance meant adoption didn't depend on us being in the room.

Usage guidance in Storybook. Open to scroll the full page.

Local fix, global impact

One launch became a platform capability.

Search was the first thing to ship on the system. It was never the only thing it was built for.

The local problem What changed systemically
Search needed a home in Member web. Any product can add search, or any other item. Two teams launched it.
Provider needed to add new EHR features. Integrated with shared components, not a one-off build.
Five web properties, five navigations. All five share one set of components, with better UX and brand alignment.
The iOS and Android apps had their own navigation. A new design on both matches the web.
Navigation changes were expensive and risky. Future navigation and IA changes happen in one place.
Native mobile, matching the web navigation.

Results

What shipped and what it enabled.

  • Reusable components, with “recipes” for common patterns.
  • Documented best practices for every new component.

Against the success targets

Target Outcome
Global components in v1 within 4 months. Delivered on time.
Client Experience launches Search within 1 sprint of v1. Shipped ahead of schedule.
Member Experience launches Search within 2 sprints of v1. Shipped ahead of schedule.
All teams adopt the components within 1 quarter of v1. Completed ahead of schedule.

What I learned

Align early, and match the feedback channel to the fidelity.

  • Align early. I talked with product, engineering, and design partners constantly from the start, so the teams already backed the plan by the time we reached product review.
  • Get focused feedback often. I used Slack for quick questions, the Design Systems Guild for demos, and design critique for specifics, so each round of feedback was about one thing.
  • Share progress with more people than you think need to know. Share early, share often. I still do this with my team today, and it held true here too.
A critique board from exploration.
Channel Use it for
SlackQuick polls and questions
Cross-team meetingsAlignment and decisions
Guild forum and office hoursDemos and technical refinement
Design critiqueSpecific design refinement
Product reviewBringing the team along, and strategic alignment

What I'd do differently

  1. I'd capture a findability baseline before launch. We tracked the improvement, but I don't have the before-and-after numbers I'd want today.
  2. If I had today's design and AI tools, I'd do discovery much faster, align to system and design principles earlier, and start building much sooner.