A Flexible Payment Feature for Unexpected Medical Bills

Overview

Unexpected medical bills often arrive all at once, and many members couldn’t pay them up front. I designed the mobile experience for Gravie Pay, a pay-over-time feature built with Paytient, then reworked repayment after launch to cut delinquency.

Company

Gravie, a health benefits company

Timeline

January 2023 to March 2024

Users

Members paying for unexpected medical bills

What I designed

The mobile pay-over-time experience: onboarding, balance and transactions, payment plans, and notifications

The Problem

A medical bill can be a few hundred or a few thousand dollars, due all at once. Members who couldn’t pay had few options besides a credit card or falling behind. Gravie partnered with Paytient so members could split these bills into payments inside the Gravie app.

My Role

I joined as the previous mobile designer was rolling off, and became the sole mobile designer, working with a PM, engineering, and a web designer in parallel so both platforms stayed consistent. I carried the feature through launch in about two months, iterated on it for the next year, mostly on notifications and member communications, and later took over web design as well.

Research

The feature was already in development when I joined, with no wireframes or early research. I worked from the business requirements document, the existing web screens, and the previous designer’s early work. The most important findings came after launch, from real usage.

After Launch

In the first month, payments started failing and accounts fell behind. Paytient, which manages the financing, found the cause: members were repaying with prepaid gift cards. The cards ran out, payments failed, and accounts went delinquent.

Onboarding at launch introduced Gravie Pay in three steps: get care now, repay over up to 12 months, and choose a payment method. After launch, repayment narrowed to bank accounts only.

Bank Account Repayment

I proposed limiting repayment to bank accounts, and designed how the change worked for members. New members could only link a bank account during onboarding. Existing members saw an in-app message explaining they couldn’t continue using the service until they added bank account details. The change addressed failed payments at the source instead of chasing members after they missed one.

Existing members were prompted to add a bank account before they could keep using Gravie Pay, and Payment Methods offered a bank account as the only repayment option. Delinquency fell 15% within three months of the change.

Notifications

Members could have several things to act on at once. I ranked them so a missed payment always appeared first, followed by setup steps in the order members could complete them.

New Member Setup

A new member has two tasks before they can use Gravie Pay. They appear in the order they need to be done: verify identity first, then add a bank account.

Members were prompted on Overview to choose a standard payment schedule for new transactions.

Set the Schedule

Existing Member With a Missed Payment

When a member has several tasks at once, the missed payment appears first because it’s the most urgent. Lower-priority tasks, like reviewing updated agreements, appear below it.

Payment Plans

Members chose how many payments to split a balance into, and the flow showed how many months that would take before they committed, so they could pick a schedule they could keep up with.

Each option shows how long payoff will take, so members can pick a schedule they can keep up with.

See the Commitment

Members were prompted on Overview to choose a standard payment schedule for new transactions.

Schedule Saved

Results

  • 15% lower delinquency: Delinquency fell within three months of the bank-account-only change.

  • Shipped in about two months: The feature launched after I joined mid-development.

  • Expanded scope: My role grew from mobile to owning web design for the feature.

Reflection

Joining mid-development without research meant learning from real usage instead of up front. Working with Paytient after launch showed how much payment data can reveal about member behavior that design reviews can’t.

The gift card issue only surfaced once payments started failing, and the fix I proposed, bank-account-only repayment, cut delinquency by 15%. Next time, I’d push to validate payment methods before launch, so a risk like this is caught in design rather than in delinquency reports.

The delinquency drop was measurable because Paytient tracked repayment closely. Going forward, I’d set baselines for adoption and engagement during discovery too, so the impact of every part of the feature can be measured, not only the parts a partner tracks.