Redesigning Claims: From a Confusing To-Do Tab to a Clear Status System
One tab was doing two jobs badly, so I split it into two: one that disappears when there's nothing to do, and one you can't miss when there is.
Recreated example, not the actual product.
Role
Senior Product Designer: designed the claims review and resolution experience. The submission form itself came from the platform we adopted when it was rebuilt.
Scope
Redesigned how users track and resolve claims across mobile and desktop, grounded in real usage and feedback from the earlier version.
Summary
- The original claims experience lived on our older platform and had been in use for several years. We interviewed the internal audit team directly, and got additional feedback relayed through the client.
- The clearest problem: users couldn't easily tell a claim's status, or what to do next
- One "to do" tab was a big part of the problem. It was the first thing anyone saw, and it combined claims still in draft with claims an auditor had sent back for fixes.
- When the platform was rebuilt, I redesigned the claims experience mobile-first, focusing on what users needed to do next.
The Process
Learning From What Shipped
- Interviewed the internal audit team about where claims got stuck and why
- Gathered user feedback secondhand, through the client, since I didn't have direct access to end users
- Found that the "to do" tab — the default view — quietly combined drafts and action-needed claims into one bucket
Rethinking Status and Priority
- Reordered the experience to lead with Approved, since that's what most users were checking for
- Split "action needed" into its own section: gone when there's nothing to do, hard to miss when there is
- Cut the draft state entirely — it slowed the build and didn't seem to help anyone
Designing Mobile-First
- Designed the review and resolution flow mobile-first, then scaled it up for desktop
- The old version was web-only. The new platform also has a native mobile app, so I had to design for that too.
← scroll to compare before and after →
Before: one ambiguous to-do tab. After: approved-first, action-needed only when present.
The Solution
One Card, Every Status
- A single card carries approved, in review, and needs-action states, instead of three separate layouts
- Consistent status placement and color, so a claim can be scanned and understood without opening it
- Same card scales from a compact list row to a full detail view without changing structure
Same claim card shown across three statuses: approved, in review, and needs action.
Designed mobile-first. It's a clean, simple design that works well at any size.
The Impact
- Users can tell what's approved, pending, or needs attention without opening every claim
- Removing the draft/action-needed conflation fixed the single most confusing part of the old experience
- Designing mobile-first meant the tool finally matched how it's actually used