When complexity hurts people: redesigning recovery

Kick Off

Leading a new team

Our internal teams run a decentralized team formation to product development. I work as an embedded consultant, leading multiple product teams simultaneously to lead their design initiatives.

Defining the Approach

Building a foundation before anyone writes a line of code

Before the work could begin, the team needed a shared foundation. I introduced three frameworks to shape how we’d operate — Agile product design, Lean thinking, and a clear understanding of the end-to-end design process.

Gathering Team Alignment

The conversation that unblocks everything

Every new product team starts with the same problem: team chaos. Where should we start? Who is doing what? What are we even building?

I facilitate a Product Canvas exercise as a method of gathering team alignment. This exercise allows the team to form a shared basis of understanding.

Moving forward, we can build momentum knowing we all agree on where we currently are and the fundamental problems we’re trying to solve.

The Problem

Parking Lot

Business Goals

Users

User Needs

“It takes two to four months to process recoveries in our current environment.”

— Product Owner

“Every claim is overpaid by design. That's just how the current system works.”

— Business Analyst

“We heavily rely on 3rd party vendors to manage this process for us.”

— Senior Manager

Strategic Focus

Better quickly instead of perfect later

Fixing the insurance claim process could go many directions. Some of those directions are good, some not so good, and some completely unobtainable. It’s more important to be better quickly than perfect later.

Introducing Dual-Track Agile

How we stopped waiting on each other

To maximize momentum in an Agile framework, I introduced the team to Dual-Track Agile. This cadence enables the product team to know their involvement with the design process and when those involvements will occur.

This cadence cycles with each iteration, enabling the design momentum to stay ahead of development.

Prioritizing Effort

The fastest path to something that matters

With an agile mindset and an objective of publishing quickly, the goal is to determine where we can provide the most value with the least amount of effort.

The Hypothesis Prioritization process from Lean UX builds team alignment while prioritizing momentum. We can use the data collected from our Product Canvas to quickly build hypotheses.

Hypotheses were presented to the greater team for prioritization. Product Owners can evaluate the value of each outcome while developers and analysts can evaluate the effort involved with building the feature.

Choosing a Design System

Why we started with a system

The team chose PrimeReact, an open-sourced, federated design system to meet our constraints with tech stack, legal, and maintenance requirements. This system excels at presenting and manipulating data — a mechanic paramount to our users’ workflows.

High-Fidelity Agile Iteration

Skipping the sketches, shipping the vision

Based on our two-week sprint cycles and values of a lean, agile workflow, value of effort was spent on quick, high-fidelity mockups over wireframes.

To communicate iterations and effort, we use a process called Slicing.

Test & Measure

What the users had to say

To validate the momentum of this iteration, I demo with various stakeholders and users to challenge if the output drives toward the intended outcome. Feedback was gathered enabling us to build new hypotheses as we begin tackling the next iteration of outcomes.

“I need to see the history behind the claim, the story it has gone through, and the decision-making that has been made along the way.”

— Business Analyst

“Would love to not have to open Amysis, Excellis, or other applications. It would be great to be able to see everything in one place.”

— Business Analyst

“I hate emails. We get far too many of them and things are getting lost.”

— Business Analyst

“A big part of this process is vendor management — who gets what and how much. Looking at trend data has helped in the past but we could use deeper analytics.”

— Product Owner

Prioritizing Outcomes

Making the roadmap make sense

To maintain communication with the broader stakeholder team, momentum is captured through Outcome Prioritization and Feature Rollouts.

Design

Bringing it all together

What started as a replacement for Palantir became a full-scale recovery platform handling everything from claim validation to vendor management.

Below: a short tour through four notable views, pulled directly from the working Figma file and annotated using the documentation that shipped with each slice. Together they trace how the analyst’s view evolved across 31 tested iterations.

1. 1Sidebar — Service Lines, Post Pay DRG Selection, Post Pay Audit Results, Rules Management, Direct Bill Claims, and Value Simulator. The platform grew well beyond a single dashboard; the sidebar is how analysts pivot between surfaces without losing place.
2. 2Claims toolbar — Batch Actions for multi-row workflows, Filter for narrowing the queue, Settings for column visibility, and Search for jumping straight to a known claim. Always-visible above the table so the workflow doesn't dead-end.
3. 3Sortable claims table — Claim Number, Vendor, Business Line, Adjustment Amount, Program, Recovery Sent, Provider, HP Deadline, TIN, and Status. Every column carries a sort affordance; the column set grew well beyond Slice 1's four as analyst hypotheses shipped.
4. 4Status — one of four states (Approved, Denied, On Hold, Pending). Non-approved tags hover-reveal which exclusion stage caught them (Master Exclusions, PI Lookback, or Exclusion Set) plus any analyst comments, using the Disclosure component.
5. 5User profile + feedback — surfaced at the bottom of the sidebar so analysts always know whose context they're in, with a one-click feedback link out to the team.

1. 1Header section — Provider, Claim Number with status tag, plus the at-a-glance metadata: Submitted On, Lookback Period (with a warning icon when the deadline is tight), Adjustment Product, and Adjustment Amount. The Audit Log button opens the full action history over the page (next screen).
2. 2Health Plan Review — the Healthplan Manager's verdict on the claim. When approved, the card collapses to a header plus the date. When denied (as here), it expands to surface the analyst, the reason, and the full comment. Change Status triggers a confirmation modal.
3. 3Adjustment Comment — surfaces any prior comments left on the claim so context isn't lost between handoffs, with the vendor reference inline.
4. 4Properties — the full structured data table about the claim itself: claim metadata, provider details, adjustment modifiers, and Medicare / OIC fields. "No Value" placeholders keep the rhythm scannable when fields are unset.

1. 1Audit Log table — every item is organized in a table with three columns. Item Number simply numbers each edit so analysts can reference a single line even when dates or notes look similar. Date is when the action occurred. Notes describes the action in plain language.
2. 2Bolded items — anything tied to passing or failing an exclusions step renders bold so the eye lands on what changed.
3. 3Modal scrim — the table is scrollable so history can grow without bounding the page; the scrim keeps the underlying claim view in soft focus.

1. 1Default Setup — always present in the Setups list, can't be edited or removed, and reloads the original pre-customization filter. The escape hatch when a saved setup goes sideways.
2. 2Save as New — names and saves the current setup without overriding existing ones. Switches the user to the Setups tab on save so they can confirm the new entry landed.
3. 3Save (existing) — overwrites the currently loaded setup with the new field selection. Disabled when the loaded setup is the Default, forcing Save as New for any modification.
4. 4Setup management — the kebab menu offers Rename or Delete on any user-created setup. Delete loads an inline confirm so it can't fire on a misclick.

Component details

The small craft — modals, controls, and brand moments that make the platform feel like a single, considered system.

Team Health

Measuring the team, not just the product

While not as paramount as measuring impact, these softer metrics assist in validating application and process momentum. Less about user outcomes and more about team health.

Complete Business Goals

149

Outcomes Delivered

53

Hypotheses Tested

182

Hypotheses Developed

125

Developed Iterations

31

Usability Tests

64

Unique Personas

17

Completed User Needs

207