Bringing structure to fragmented workflows

What was breaking down

This project started with a gap that wasn’t immediately obvious—but became critical once we looked beyond individual features.

Users were triggering important actions in the system—but they couldn’t always see what had been done, when it happened, or what to do next.

On the surface, it looked like a feature problem. But the more we dug in, the clearer it became that the issue was deeper than that.

The workflow didn’t hold together.

Actions were happening across different points in the experience, some visible, some not, and the system wasn’t giving users a clear understanding of what was going on.

What made this complex

The complexity wasn’t just in the interface—it was in how the system actually worked.

Some actions were triggered directly by users, while others happened behind the scenes. Some were tied to member care, while others supported operational or business goals. Many of these actions extended beyond the product itself, involving external systems and third-party vendors.

From a system standpoint, there wasn’t a single model that connected all of this. And without that structure, it became difficult for the product to provide a reliable experience to the people using it.

In a healthcare context, those gaps don’t just create friction—they increase the risk of things falling through the cracks.

To understand what was happening, we mapped how these actions played out across five key workflows—things like sending letters, ordering meals, arranging transportation, and coordinating care equipment.

What stood out quickly was how fragmented the experience had become. Each workflow made sense in isolation, but there wasn’t a consistent way to understand how actions were triggered or tracked across the system.

My role in this

My role was to step back and help the team make sense of what was happening.

That meant understanding how different types of actions were triggered across the workflow, where the breakdowns were occurring, and how those gaps affected both users and the business.

I worked closely with Product and Engineering to build a shared understanding of the system—what needed to be visible, what needed to be trackable, and where more structure was needed to make the experience reliable.

How we approached it

Making sense of a system that didn’t hold together

Once we stepped back from individual features and looked at how actions moved through the system, it became clear that the problem wasn’t isolated. Different types of interventions—sending letters, ordering meals, arranging transportation—were all handled in slightly different ways. Each workflow made sense in isolation, but there wasn’t a consistent way to understand how actions were triggered, handed off, or completed.

Identifying patterns across otherwise disconnected workflows

Looking across these workflows side by side, a pattern started to emerge.

Regardless of how an action began, it tended to move through a similar lifecycle:

• Something was triggered
• Information was gathered or confirmed
• An order or request was initiated
• The order was fulfilled

But those patterns weren’t consistent in how they were represented or tracked. In some cases, actions were visible early on but disappeared after being handed off. In others, the system continued processing work behind the scenes without giving users a clear sense of what had happened or what was still in progress.

The issue wasn’t that the system lacked functionality—it was that it lacked a coherent model.

Without that structure, it became difficult for users to rely on the experience or build confidence in what the system was doing.

Creating alignment around what needed to be visible

From there, the focus shifted from mapping what existed to aligning on what should exist. Working with Product and Engineering, we defined what it meant for an action to be:

• Triggered
• In progress
• Completed
• Visible

That meant deciding not just where actions would appear, but what information needed to be consistently available across workflows so users could understand what had happened and what to do next.

Instead of treating each workflow as a one-off case, we began to frame actions as part of a broader, shared model—something that could be applied consistently regardless of the specific task. That alignment created the foundation for the concept that followed.

What changed

Making actions visible and understandable

Before this work, actions were being triggered across the system—but they didn’t consistently show up in a way users could understand. Members often had no clarity into what had been ordered on their behalf, whether something was in progress, or what to expect next. When information did surface, it was fragmented across different parts of the experience and lacked a consistent structure. The result wasn’t just inefficiency—it was uncertainty. This work focused on changing that: making actions visible, understandable, and reliable from the moment they were triggered through completion.

Bringing consistency to a fragmented experience

Once actions were structured into a shared model, it became possible to represent them consistently—regardless of how or where they were initiated. Instead of each workflow behaving differently, actions could now:

• Appear in a single, predictable location
• Carry consistent information about status, timing, and ownership
• Be tracked as they moved through the system
• Provide clear next steps

What had previously felt like a set of disconnected processes started to function as a cohesive experience. That consistency reduced the need for users to interpret or second-guess what was happening behind the scenes.

Making internal work visible to the member

One of the most meaningful changes was connecting internal workflows directly to the member experience. Actions initiated by care managers—ordering meals, sending equipment, arranging transportation—were no longer hidden or abstract. They translated into a visible, trackable experience within the member app. This concept explored what it would look like to expose that work directly to the member.

Members could now:

• Receive notifications when actions were taken
• View all current and past orders in one place
• Access detailed information about each item
• Know exactly who to contact if something needed attention

This created a clear line between the work happening behind the scenes and what the member could understand and act on.

Reinforcing trust through clarity

With clarity into what had happened, what was in progress, and what to expect next, the system became easier to rely on. Users no longer had to follow up manually to confirm whether something had been completed or assume ownership of next steps that were unclear. The experience provided a stronger sense of progress and accountability. In a healthcare context, that clarity doesn’t just improve usability—it directly supports confidence in the system and the ability to act on behalf of a member. This shifted the experience from something users had to manage manually to something they could rely on.

What this reinforced

The connection between workflows was the real design problem

This work reinforced that the real challenge wasn’t designing individual workflows—it was designing the system that connects them. Each workflow could be improved in isolation, but without a shared structure, those improvements wouldn’t scale. The value came from identifying patterns across workflows and creating a model that could be applied consistently, rather than solving each case individually.

Visibility is as critical as functionality

It also highlighted how often systems technically “work,” but fail to provide enough visibility for users to trust them. In this case, actions were being triggered and fulfilled, but because they weren’t consistently surfaced or tracked, users were left to fill in the gaps. Making those actions visible—clearly and consistently—had a direct impact on how reliable the system felt.

A shared view made better decisions possible

Finally, this work reinforced the importance of creating alignment early, especially in complex, cross-functional environments. The journey mapping wasn’t just about understanding the system—it created a shared view that Product, UX, and Engineering could use to make decisions. That alignment made it easier to move forward with a consistent approach, instead of revisiting the same questions across different workflows.

Small structural decisions have outsized impact

Small structural decisions—how an action is represented, where it appears, and what information is included—can fundamentally change how a system is experienced. By introducing a consistent model for actions, the experience became easier to navigate, easier to trust, and easier to extend.