Case study 01

Bringing a Veteran’s payments into one place

Overpayments, copays and travel pay each lived in a different part of VA.gov. I designed and built one place in My VA where Veterans can see what they owe, what they’ve been paid, and what to do next.

Situation: 3 systems, 4+ teams
My role: Primary designer for Payments + front end
Team: PM, research, content + 2 partner teams
Outcome: Launches Nov 11, 2026

The problem

Each payment type came from a different system, and overpayments alone had 13 statuses. Without shared rules, Veterans couldn’t tell what actually needed their attention.

What I did

Wrote the rules first

I mapped every status to Action required, Updates or hidden, each with a clear next step. Debts about to go to the U.S. Treasury always go on top, since that’s the worst outcome for a Veteran.

Planned for things breaking

I designed 8 data scenarios, from empty to timeout. If one system goes down, only its section shows an alert.

Tested with real data

Before launch, we ran a canary test with real data, and it caught a lot of travel pay bugs. For example, saved and incomplete claims were showing up as updates, so I pulled them out and gave each its own status tag.

Table mapping overpayment statuses to Action required, Updates, or hidden, and showing whether a due date appears. — Overpayment status routing

Payments empty state beside a partial-error state, where available items remain visible while travel pay data fails to load. — Empty and partial-error states

The result

One place for payments

Overpayments, copays and travel pay in one view, launching Nov 11, 2026.

Research built in

Study findings shaped the first release and the next phase.

Designed and coded by me

6 front-end releases, from the rules to the code.

What I learned

Pulling records from several systems into one view is mostly a rules problem. Getting everyone to agree on the rules was most of the work.