Reframing a Point Solution Into a Systemic Claims Operations Capability

The ask: design a retro term solution

The organization had begun a workflow discovery effort to map the end-to-end retroactive termination process. I was brought in by my manager, given my five years as the sole designer for plans and claims at Collective Health, to translate that discovery into a design direction.

The initial brief was scoped around retroactive termination claims specifically. I was not starting from zero on this problem. I had deep familiarity with how ops teams worked, what leadership had been asking for, and where the existing product architecture had gaps.

Observing the workflow, questioning the brief

A service design partner led the intensive process mapping sessions, where claims stakeholders and subject matter experts detailed every step of the retroactive claims lifecycle. I observed these sessions to deepen my operational understanding while managing other ongoing projects in parallel.

Rather than designing directly to the retro term workflow once I understood it, I stepped back and asked what category of problem this actually was.

Retro claims made that gap impossible to ignore, because they arrived in batches and required coordinated assignment and multi-week tracking across networks. But the underlying visibility and assignment gap existed across the organization. I had been hearing about it for years.

A hub, not a point solution

I proposed a claims operations hub rather than a retro term specific tool. The hub would surface retro term claims as a structured workflow within a broader claims management layer, alongside functionality ops had been requesting for years, including the ability to see all claims assigned to a specific MCA and reassign them when needed.

A retro term only tool would have been faster to define and easier to scope for engineering. I made the tradeoff deliberately. A point solution would have sat awkwardly in the existing product architecture and would have duplicated infrastructure we would eventually need to build anyway.

I built the concept prototype entirely in Figma Make, using AI tooling to move quickly from concept to something interactive without waiting on a full design system implementation.

The decisions that shaped the prototype

The Assignment Hub was designed for managers, not MCAs. That distinction drove every layout decision. Managers needed a fast read on team health, not claim-level detail. The four summary stats at the top, total team members, unassigned claims, assigned claims, and total teams, were chosen because a manager who knows each MCA should carry roughly 120 claims per day can do capacity math in seconds without drilling into anything. The view was designed to answer one question immediately: are we on track?

One significant decision was cross-team visibility. An earlier consideration was restricting each manager's view to their own team only. I rejected that based on what I had observed over years of working with the ops team. Managers planned claim assignments using Looker data that could become outdated overnight. When Looker refreshed in the morning, as many as 20,000 new claims could appear, instantly invalidating the plan they had built. They spent their mornings reacting and reshuffling instead of managing. A view that showed the full picture across all teams in real time meant managers could see where capacity existed and shift resources before the situation became a crisis.

For the Claims Queue, sub-batches are organized by network rather than by member or date. The reasoning was operational. Different networks follow different recoupment workflows. Grouping by network means an MCA can work through an entire Cigna queue without switching mental models mid-task. The organization of the information reflects how the work actually gets done.

The eligibility issue column was designed with future use cases in mind. Retro termination was the trigger for this project, but discovery conversations surfaced other eligibility events that could cause similar downstream claim impacts. Categorizing claims by eligibility issue type rather than retro term only meant the architecture could accommodate those future cases without a redesign.

For the overall interface, I chose a table layout over more novel approaches. The users are operations specialists who work in data-heavy tools every day. A familiar table structure means they can read and act immediately without learning a new mental model at the same time as adopting a new tool. For an MVP concept, reducing cognitive load at the interface level was the right call.

Presented to director-level stakeholders

I presented the concept to director-level stakeholders across product, operations, and engineering. The prototype demonstrated both the retro term batch workflow and the broader assignment hub functionality so stakeholders could see the concept operating at both levels simultaneously.