Background

Setting the stage for the redesign

Healthcare Navigation was already a functioning product. That made this project harder, not easier. Redesigning something that works — but not well enough — requires a more precise diagnosis than building from scratch. You have to understand what's worth keeping, what's creating friction, and what the system can actually support given its existing constraints. This section covers what the product was, why the moment demanded change, and what was driving urgency from the business side.

About the product

Healthcare Navigation is a core feature within the Alight benefits platform. It gives users access to self-service tools — provider search, a health library, symptom checkers — alongside human-led support through personally assigned Health Pros. The product's promise is meaningful: one place to manage your healthcare journey, with both digital tools and real guidance available when you need them. The execution hadn't kept pace with that promise.

Why this work mattered now

The experience had accumulated problems over time — overlapping features, inconsistent terminology, and a page structure that no longer reflected how users actually sought help. As the platform's user base grew and healthcare needs became more complex, the gap between what the product offered and what users could find became impossible to ignore. Engagement with self-service tools was low. Support volume was higher than it should have been. And the Health Pro model — one of Alight's core differentiators — wasn't landing the way it was meant to.

Drivers for redesign

Three forces made this work time-sensitive. First, user behavior: testing and support data consistently showed confusion at the navigation layer, with users misreading features, missing tools, and forming inaccurate expectations about communication. Second, business performance: low self-service engagement meant the platform wasn't demonstrating ROI on features that had already been built. Third, client commitments: contractual expectations tied to feature visibility and engagement created a hard deadline that compressed the entire design and testing cycle to under three months.

This wasn't a discretionary improvement. It was a business-critical intervention with a clock attached.

Problem

Defining What Wasn't Working

The value of Healthcare Navigation was clear in concept. In practice, the experience introduced friction at every decision point — and in a domain where users are already anxious, friction doesn't just slow things down. It breaks trust. To redesign effectively, we first had to be precise about where the experience was failing and what it was actually costing.

Key usability issues

The landing page had a structural problem at its core: it was organized around the product's features, not around how users think about getting help. The Health Pro — a premium, personalized service — dominated the visual hierarchy, while self-service tools were buried in a way that made them feel secondary or optional. Users arrived looking for direction and left without finding it.

What we saw in the evidence

Support tickets, stakeholder feedback, and early usability sessions told a consistent story. Users were misreading the messaging interface as a live chat — and when responses didn't come immediately, trust dropped. Self-service tools like the symptom checker and provider search went largely unused, not because users didn't want them, but because they never surfaced in a way that felt relevant. And the distinction between Health Pros and Medical Allies — two different roles with different functions — was invisible in the interface.

These weren't isolated complaints. Confusion at the navigation layer created downstream pressure on support teams, reduced engagement with features the business had invested in building, and created a perception that the platform was harder to navigate than going direct. For a product whose entire value proposition is making healthcare easier, that gap was existential.

What users were struggling with

Users arrived on the page without a clear mental model of what it was for. They didn't know whether they were in a place to find information, send a message, search for a doctor, or do all of the above. When everything appears equally weighted, nothing feels clearly actionable. Users defaulted to the most familiar option — calling support — rather than engaging with tools that could have resolved their need faster.

scope

What we aimed to solve — and what we had to work around

The scope of this project was defined as much by what we couldn't change as by what we could. Constraints in an enterprise environment aren't obstacles — they're the actual design problem. Understanding the hard edges of the system early is what makes it possible to find solutions that can actually ship.

User goals

Users needed to clearly understand the difference between Health Pros and Medical Allies, know what to expect when they sent a message and when they'd hear back, and be able to find and use self-service tools without hunting for them.

Business goals

The business needed the Health Pro model to feel valuable and prominent without overshadowing the self-service features that clients expected to see performing. Reducing confusion-related support inquiries and increasing self-service engagement were both tied to demonstrable platform ROI.

Design principles guiding decisions

Decisions were grouned in usability best practices including:

• Clarity through hierarchy
• Progressive disclosure to reduce cognitive load
• Consistency and recognition over recall
• Transparency in communication expectations

Technical limitations — and what they actually meant for design

The message center architecture couldn't be rebuilt. It was shared across multiple platform features and touching it would have cascaded into a scope far beyond this project. That constraint didn't limit the solution — it defined the design challenge. If we couldn't change the system, we had to redesign the communication around the system. The answer was to use visual patterns, microcopy, and information hierarchy to align user expectations with the actual experience before they ever sent a message.

Timeline constraints

Less than one week separated strategic planning from testing-ready prototypes. That compression forced prioritization discipline — every design decision had to be defensible immediately, not refined over multiple rounds of internal review.

Out-of-Scope areas

The core Health Pro assignment logic and backend messaging system were excluded due to system-wide dependencies. Working within those limitations meant every solution had to be structural and surface-level — which, as it turned out, was exactly where the real problems lived.

Approach

Designing for clarity and confidence

The instinct in a project like this is to start with the UI — refresh the layout, update the components, make it feel cleaner. I started instead with the information architecture, because the visual problems were symptoms of a structural one. Until the hierarchy was right, no amount of visual refinement would resolve what users were experiencing.

Decision 1: Separate two competing mental models before touching the interface

The landing page was simultaneously trying to be a hub for self-service tools and a personal gateway to an assigned health advisor. Those are different user intentions, and they need different visual and structural treatment. I restructured the page to give each a clear, distinct position — not by removing either, but by organizing them so users could immediately recognize what type of help they were looking at and choose accordingly.

Decision 2: Rebalance the hierarchy without diminishing the Health Pro

The business had a legitimate interest in keeping the Health Pro visible and prominent. Users had a legitimate need to find self-service tools without scrolling past a feature they weren't ready to engage with. The solution wasn't to choose one priority over the other — it was to redesign the hierarchy so that each element occupied the right position relative to how users naturally move through the page. The Health Pro shifted from dominant visual anchor to a clear, accessible entry point. Self-service tools moved into primary discoverability. Neither was buried. Both became more findable.

Decision 3: Design the expectation, not just the interface

The asynchronous messaging confusion was never going to be solved by a UI update alone. Users were forming expectations based on visual patterns that felt like live chat, and those expectations weren't matching the reality of the system. Since we couldn't change the underlying messaging architecture, we redesigned the communication layer around it — introducing email-inspired patterns, explicit timestamps, and clear status language that made asynchronous communication feel intentional and trustworthy rather than broken or unresponsive.

Decision 4: Test structure, not preference

Across four rounds of moderated usability testing, the research was focused on comprehension and decision-making — not aesthetic preference. Could users identify their options without prompting? Did they understand what would happen after they sent a message? Could they find a self-service tool relevant to their need? Each testing round validated a structural decision and informed the next iteration. By the time the design was final, every major choice had evidence behind it.

I partnered with the research team throughout, contributing to test planning, observing sessions, and translating findings directly into design iterations. The speed of the timeline made that partnership non-negotiable — there was no room for a handoff-and-wait cycle.