Easily add and update who your business pays

I was also responsible for the recipient management experience, meaning adding, editing, and viewing who our users pay.

Reviewing payments through core user flows

Year

2025-

Team

3 product managers

3 designers (lead)

2 researchers

8 developers

Experience

user research

product design + implementation

Our team is launching a new bank by JPMorganChase for startups, aimed to scale with our clients as they grow in size. In 2025, I led various projects to review payments and payment details. This includes the landing page to view payment trends and to-do's; payment activity across statuses and series; and action items for payment approvals.

Your money, your dashboard

The dashboard should allow users to observe where their money is going to quickly understand the company’s financial health.

Other features should include customization to only see the financial trends and patterns relevant to a user's company role, and a focus on payments and transfers not yet completed to ensure activity is going as planned.

Below are closer looks at all of the widgets, including empty, one-to-few-item, multiple-item, and error states. The widgets include payments that require action, especially on payments that are time-sensitive; recently added or paid recipients; account details for easy sharing; payments by status; and recent payment activity.

We wanted to focus on what is either upcoming or completed for user's easy review.

The details that an approver needs to see

I was responsible for designing payment details, which gives users quick access to essential payment information, with status prioritized for at-a-glance review.

One product requiremen was that approvers could perform the following actions on a payment pending review: ‘Approve’, ‘Decline’, and ‘Send back for changes’

The design team questioned the need for both ‘Decline’ and ‘Send back for changes’. However, the benefit of ‘sending back’ a payment would be that users wouldn’t have to recreate a payment from scratch.

Ultimately, we agreed to take it to research to ground our perspective.

We conducted hour long interviews with six startup founders. Company sizes ranged from two to 50+ employees. Industries included AI, EV charging, news aggregation, financial services, robotics, and biotech.

“I don’t know what that is. Send back to who? The utility company? They are not going to permit you to argue with them...”

“I don’t know what that would do and I’d be nervous to press it. I want to know what’s going to happen when I press this - will it send out an email or something else?”

“Why does a send back option exist? Can’t it just be in the decline where you can add a comment?”

We took this feedback as an opportunity to revisit our design. As a compromise, we added the ability to edit and re-submit a declined payment so users could make changes within the payment and have the ‘Declined’ event in its tracking history.

We proposed this to our stakeholders and they agreed it made sense to remove it.

Urgent reviews where they matter

When approvers sit down to review a payment, they shouldn't have to hunt for the information that matters. Below, I designed various action items entry points.

The left-hand widget is for, the home page, and the right-hand widget is for either that or the money movement dashboard. Both are tailored for users to efficiently review and approve the most urgent payments.

Below is a dataview of payment approvals in the Action Items page. Across work streams, we aligned on tab order, column order, type treatment, button treatment, export flow, and more.

Where recurring payments should live

A key decision early on was whether recurring payments should be woven into the existing payment flow or broken out as a standalone experience.

Before proposing a direction, I looked at competitor experiences to ground the conversation in existing user expectations.

Since competitor research didn't point to a clear choice, I developed a few approaches

Then, I facilitated a discussion with product to weigh each against user needs and technical constraints, as we were building off of the rails of an existing platform.

After reviewing the options, product landed on a unified table that combined recurring and individual payments, prioritizing simplicity.

Outcomes and learnings

Our digital bank isn't launching until June 2026, but the design process has already delivered meaningful outcomes.

First, I invented formalized new patterns and guidelines absent in the growing design system, particularly for our dashboard, which other teams will later build off of.

Additionally, the back-and-forth on whether or not to include ‘Send back for changes’, and where recurring payments might sit, improved my stakeholder abilities. The stakeholder pushed to keep it, so we did, with the understanding that persistent negative feedback would give us grounds to revisit and refine.