Doctors and hospitals running clinical trials can wait up to six months to be paid, which puts real strain on sites. Platform Payments was a new product to fix that. Money moves through five steps:

1. Payees: the doctors and sites being paid, and how they want to be paid.
2. Clinical Trial Agreement: the contract setting who is paid, for what and how much. It needs approval.
3. Costs: created from the agreement as trial events happen, or added by hand. A share can be held back until the study is completed to standard.
4. Payment requests: approved costs grouped by study, site, payee and payment method, then approved again.
5. Disbursement: approved requests are sent to a payment provider.

Everything downstream depends on step two. If the agreement is wrong, every payment is wrong.

The payments flow, from payee to disbursement

An agreement is a dense contract in four parts: the details, the payees, a holdback percentage, and budget line items that set who is paid how much for each visit or activity. Different roles can do different things to it as it moves through approval.

It also changes. A study can run for ten years and collect as many as 12 amendments, each with its own status, dates and payees. The interface had to make all of that creatable, reviewable and auditable.

I joined straight out of university, as the first beta was being prepared. Within a couple of months I took over as the product's only designer.

The original 2019 agreement screen

The product was confidential for its first year, so we couldn't speak to the sponsors or sites who would use it. I found the closest legitimate proxy: a payment processing partner already working with our legacy product, whose team would be creating agreements on the new one. I ran six moderated usability tests with them.

• The payee selector couldn't tell people apart. In large trials, two doctors with the same name can work in the same city, and participants didn't know what the number under each name meant.
• Budget line items were the hardest part. The number and size of the cards was disorienting, the visit name wasn't obvious, and labels like "Card Type" meant nothing to participants.

Because the partner knew the legacy product well, I separated feedback about real needs from feedback about old habits before acting on it.

Usability findings

Reworking budget line items

• Language first. "Card Type" went. I tested alternatives against one question: would a non-expert read it the way we mean it?
• Progressive disclosure. Specifying individual visits is the less common case, so it became an optional step. One extra click for some, less noise for everyone.
• Standard components over custom ones. I moved from a checkbox dropdown that would have been built from scratch to a familiar multi-select that keeps the chosen visits visible.
• A calmer card, weighing a cleaner layout against the risk of the total amount being missed.

Budget line item card, before and after

Amendments keep a contract correct for the life of a study. They were the hardest design problem in the agreement: every version has its own status, dates and payees, and an approver needs to see exactly what changed.

Where can you start an amendment?

Letting people start from any version was flexible, but the warning that it would be based on the latest version only came after they'd committed. I restricted it to the latest version. It costs an extra step, but people are expected to review versions before amending anyway, and the starting point is never ambiguous.

Options for where to create an amendment

How do versions appear in the list?

Grouping amendments under the original kept the list tidy, but raised a question nobody could answer at a glance: whose status, dates and payees does the grouped row show? One row per amendment was clear but noisy, with up to 12 per contract. I explored status markers, a previous-versions treatment and expanding rows before recommending every version by default, with an option to group.

What happens with 12 tabs?

The design system put tab overflow at the very end, which would have buried the change log behind a dozen amendments. I proposed placing the overflow second to last so the change log stayed visible, a small and deliberate bend of the system.

How do you show what changed?

This is what the approver needs most. After exploring field highlights, highlighted containers, badges and dots, I settled on three explicit states for each budget line item: New, Amended and Removed, each labelled, with highlighting or greying to support the label. Underneath sat the rules that handled the edge cases:

• A field edited and then changed back is not highlighted.
• Indirect changes, such as a total recalculated from other edits, are highlighted.
• Changes are surfaced while the amendment is being drafted and reviewed, not once it's approved.

Change-highlighting options, and the final New, Amended and Removed cards

As the only designer across four engineering teams, I also had to make quality hold up without me in every conversation. I audited the built interface, then added a design review step to every front-end ticket. I built a Payments component library on the company design system, with table rows that pull realistic data from a spreadsheet, so edge cases were cheap to design for.

An agreement page before and after the review process

The agreement, including amendments and the reworked budget line items, shipped in the product's first production release. Findings from the usability tests were built into the payee selector and budget line items, and the design review step became a standard part of front-end work.

Development was later paused for a long period, and the product went live with customers in 2025.

What I'd do differently

• Close the loop. The reworked budget line items shipped without a second round of testing. I'd now validate the riskiest change with a quick test before it shipped.
• Define success upfront, such as time to create an agreement or errors caught at approval, so the story could end with what changed for users, not just what shipped.